Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 4 123 ... LastLast
Results 1 to 15 of 59
  1. #1
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts

    How to never set a cookie??

    I'm sorry if this is a common question, but I've searched all over and can't find it.

    How do I establish and use a session, and NOT set a cookie at all? I know that using cookies is the default storage system, and that a line in (I believe) php.ini or some such file, can control this. But I'm on a shared hosting system, 1&1, and so don't have control of that file.

    I have an "Initial Contact" form that people can fill out and email to me, and if they choose to include an email address I can reply to them. I generate a short, random password each time the form is used, and I need to save that value to compare to the one they entered after they submit. I also store the rest of what they entered, so if they blow the password they don't have to re-type everything all over again. When they are done with the form, I have no further desire to store anything, and so each of my other pages begins with ...

    PHP Code:
     <?php session_destroy(); >?
    ... just to make sure no data has been inadvertently stored in some way.

    It's working fine, but I do NOT want to use cookies, and so far I've been unable to avoid having one set.

    Any clues would be greatly appreciated!

    Thanks,
    Bob
    Last edited by RTrev; 03-16-2007 at 02:12 AM.
    Think slow, type fats

  • #2
    Super Moderator Inigoesdr's Avatar
    Join Date
    Mar 2007
    Location
    Florida, USA
    Posts
    3,647
    Thanks
    2
    Thanked 406 Times in 398 Posts
    You can set "session.use_trans_sid" to true in .htaccess, and by using ini_set() iirc. The SID is passed in the URL.

  • #3
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Inigoesdr View Post
    You can set "session.use_trans_sid" to true in .htaccess, and by using ini_set() iirc. The SID is passed in the URL.
    Hmm. Thanks.. that gives me a place to start!

    Putting

    Code:
    session.use_trans_sid true
    in my .htaccess with or without the prefix of php_ gives me a 500 server error. Putting

    PHP Code:
    <?php
    ini_set
    (’session.use_trans_sid’,  true);
    session_start();
    ?>
    at the top of my php file doesn't seem to do anything.. and I still get a cookie set. Is it possible that 1&1 doesn't allow me to use sessions without cookies?
    Think slow, type fats

  • #4
    Super Moderator Inigoesdr's Avatar
    Join Date
    Mar 2007
    Location
    Florida, USA
    Posts
    3,647
    Thanks
    2
    Thanked 406 Times in 398 Posts
    Try these in your .htaccess:
    Code:
    php_value session.use_cookies "0"
    php_value session.use_only_cookies "0"
    php_value session.use_trans_sid	"1"
    And/or:
    PHP Code:
    ini_set('session.use_cookies'0);
    ini_set('session.use_only_cookies'0);
    ini_set('session.use_trans_sid'1); 

  • #5
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Inigoesdr View Post
    Try these in your .htaccess:
    Code:
    php_value session.use_cookies "0"
    php_value session.use_only_cookies "0"
    php_value session.use_trans_sid	"1"
    And/or:
    PHP Code:
    ini_set('session.use_cookies'0);
    ini_set('session.use_only_cookies'0);
    ini_set('session.use_trans_sid'1); 
    Okay, the .htaccess code gave me the 500 - Internal Server Error, and removing the .htaccess and using the php code caused my page to cease working.. that is, it didn't remember the password after the submit and so causes each attempt to fail because a new password is generated on entry to the page given that one doesn't already exist.

    I copy/pasted your code, so no typos crept in.

    Really appreciate the help.. and I think I'm getting closer.. at least this last round made something change. Maybe I'll have to just live with setting cookies, but I so detest that idea. I want a clean site that doesn't try to execute any client-side scripting and that doesn't use cookies for anything unless they are truly needed and wanted by the visitor to maintain state between visits. I don't have anything running that requires that yet.

    Thanks again!

    Bob
    Think slow, type fats

  • #6
    Super Moderator Inigoesdr's Avatar
    Join Date
    Mar 2007
    Location
    Florida, USA
    Posts
    3,647
    Thanks
    2
    Thanked 406 Times in 398 Posts
    I just did a simple form to set/get the password after setting it and forcing the URL session id, and it worked fine. Are you storing the password after starting the session when you POST/GET it? Why are you so against cookies anyway?

  • #7
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Inigoesdr View Post
    I just did a simple form to set/get the password after setting it and forcing the URL session id, and it worked fine. Are you storing the password after starting the session when you POST/GET it? Why are you so against cookies anyway?
    Are you per chance using 1&1 hosting? If so, I don't know why it won't work for me.

    I start the session at the very top of the page, and after I've generated the password code I simply do this:

    PHP Code:
    session_register(pass); 
    It works fine if I allow the cookies, so I presume I'm setting up my session correctly. I'm a newbie, though, so nothing is for certain in that respect.

    As for being against cookies, I guess I'm just being a purist and a perfectionist. It's my first site, and I want it to be right. If someone comes along who doesn't accept cookies, I want it to still work precisely the same. And why have the overhead of sending and then reading back a cookie, in a matter of milliseconds, which isn't needed for any other purpose? It seems like a kludge.

    I have a friend who runs a site precisely the way I'd like to run mine, and his sentiments are summed up here:

    http://www.grc.com/privacy.htm

    It's just something that I feel strongly about.. not doing anything on my site that requires the user to do anything that THEY might not want to do. And especially if it's just a kludge because I can't figure out how to do it right. Make scents?

    Bob
    Think slow, type fats

  • #8
    Super Moderator Inigoesdr's Avatar
    Join Date
    Mar 2007
    Location
    Florida, USA
    Posts
    3,647
    Thanks
    2
    Thanked 406 Times in 398 Posts
    I just tried it on a 1and1 server and it did not work. They probably have it blocked for security reasons. You're going to have to switch hosts(hah), use your own custom system, use cookies, or there's probably something else that I can't think of right now. Someone else will probably chime in with another possibility too. Good luck!

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by RTrev View Post
    As for being against cookies, I guess I'm just being a purist and a perfectionist. It's my first site, and I want it to be right. If someone comes along who doesn't accept cookies, I want it to still work precisely the same. And why have the overhead of sending and then reading back a cookie, in a matter of milliseconds, which isn't needed for any other purpose?
    Sessions set session cookies that are stored in the browser and so they don't take any time for reading/writing because no reading or writing takes place. If cookies are disabled the session id usually gets appended to the URL as a querystring. There is no difference to the overhead, iit just makes the address bar look slightly less tidy but since visitors with session cookies disabled always see it that way while those with session cookies enabled have the browser pass the session id between pages internally to the browser there isn't any significant difference between the two. Sessions don't require the type of cookie that writes anything out to a file since the session can't continue if the browser is closed. Very few people disallow session cookies since it is only third party cookies stored on your hard drive that have a privacy issue.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    Sessions set session cookies that are stored in the browser and so they don't take any time for reading/writing because no reading or writing takes place. If cookies are disabled the session id usually gets appended to the URL as a querystring. There is no difference to the overhead, iit just makes the address bar look slightly less tidy but since visitors with session cookies disabled always see it that way while those with session cookies enabled have the browser pass the session id between pages internally to the browser there isn't any significant difference between the two. Sessions don't require the type of cookie that writes anything out to a file since the session can't continue if the browser is closed. Very few people disallow session cookies since it is only third party cookies stored on your hard drive that have a privacy issue.
    If I'm understanding you correctly, then, for example, if I want to store the message text of the message the user is writing to me so that it can be refreshed after the submit if some problem occurs, we don't end up with a cookie containing all of this text sitting on the user's machine, even if only briefly? All it will contain is the sessionid value? The actual *data* that has been registered in that session will *not* be on the user's machine? That is making it sound a lot better.

    If I hear you right, it's more efficient to use them than to try to avoid them? And the URL will *automatically* handle the details if someone shows up with cookies disabled, so I have to do nothing at all differently in my code to allow for those folks?

    That all being the case, I guess I'd better get over the cookie thing and just keep on coding.

    I'll experiment some more, using the routine with and without coolies enabled, and see how I make out. In any event, it's beginning to appear that my hosting service is giving me no choice in the matter.

    Thanks for the info!

    Bob
    Think slow, type fats

  • #11
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Inigoesdr View Post
    I just tried it on a 1and1 server and it did not work. They probably have it blocked for security reasons. You're going to have to switch hosts(hah), use your own custom system, use cookies, or there's probably something else that I can't think of right now. Someone else will probably chime in with another possibility too. Good luck!
    Thanks for going to all the trouble of testing it for me. Much appreciated!

    I even thought about writing the information to a little file on the server, or storing it in a MySQL database, but that seems like it would really be overkill.

    Thanks again!

    Bob
    Think slow, type fats

  • #12
    Super Moderator Inigoesdr's Avatar
    Join Date
    Mar 2007
    Location
    Florida, USA
    Posts
    3,647
    Thanks
    2
    Thanked 406 Times in 398 Posts
    Quote Originally Posted by RTrev View Post
    If I'm understanding you correctly, then, for example, if I want to store the message text of the message the user is writing to me so that it can be refreshed after the submit if some problem occurs, we don't end up with a cookie containing all of this text sitting on the user's machine, even if only briefly? All it will contain is the sessionid value? The actual *data* that has been registered in that session will *not* be on the user's machine? That is making it sound a lot better.
    Yes, all that is stored on the user's machine is the session id.
    Quote Originally Posted by RTrev View Post
    If I hear you right, it's more efficient to use them than to try to avoid them?
    Yeah..
    Quote Originally Posted by RTrev View Post
    And the URL will *automatically* handle the details if someone shows up with cookies disabled, so I have to do nothing at all differently in my code to allow for those folks?
    Correct, in theory. 1and1 could have the URL method disabled altogether, though.
    Quote Originally Posted by RTrev
    I even thought about writing the information to a little file on the server, or storing it in a MySQL database, but that seems like it would really be overkill.
    1and1 probably won't let you, but sessions can actually be setup to use the database to store the information.

  • #13
    Senior Coder
    Join Date
    Jan 2007
    Posts
    1,648
    Thanks
    1
    Thanked 58 Times in 54 Posts
    I have a friend who runs a site precisely the way I'd like to run mine, and his sentiments are summed up here:

    http://www.grc.com/privacy.htm
    I honestly feel sorry for your friend.

    A website written assembly (as far as that is true) is crazy.

    Just because some people are maniacs about privacy, shouldn't mean that you waste thousands of hours writing things in assembly, and writing roundabout ways for simple solutions.

    When I read that, I was expecting "April Fools" at the bottom.

    They may sell products that concern privacy, but it's a website. That sells what, software? Why would anyone ever care if people found out they bought HD recovery software, or some other product. If this was an important thing like tax information, maybe it would be acceptable.

    Just wow...

    At least I understand your hesitation with cookies now

  • #14
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by aedrin View Post
    I honestly feel sorry for your friend.

    A website written assembly (as far as that is true) is crazy.

    Just because some people are maniacs about privacy, shouldn't mean that you waste thousands of hours writing things in assembly, and writing roundabout ways for simple solutions.

    When I read that, I was expecting "April Fools" at the bottom.

    They may sell products that concern privacy, but it's a website. That sells what, software? Why would anyone ever care if people found out they bought HD recovery software, or some other product. If this was an important thing like tax information, maybe it would be acceptable.

    Just wow...

    At least I understand your hesitation with cookies now
    I should ask Steve to post some of his code.. he did once.. and it's gorgeous. If you know what you're doing, you can be as productive that way as in any other language. During intense testing periods, he will release 30 changes in one day for little things for us to try. He has a nice library of functions built up, and his code is readable and clean and easy to understand. It looks more like a well-written example of a high-level language. Of course his final products are 20K instead of 30 Megs of bloat! He's a unique guy!
    Think slow, type fats

  • #15
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Inigoesdr View Post
    Correct, in theory. 1and1 could have the URL method disabled altogether, though.
    What would I look for in phpinfo() that would tell me that? Or I can just wait until I get home and test it. I'll be quite disappointed if they've done such a thing, and would presume that they must get a lot of complaints if so?

    Thanks,
    Bob
    Think slow, type fats


  •  
    Page 1 of 4 123 ... LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •