No announcement yet.

Confused about cookies and sessions

  • Filter
  • Time
  • Show
Clear All
new posts

  • Confused about cookies and sessions

    A while ago i set my browser to ask if a cookie may get stored.
    My browser asks to allow, allow for session or to refuse.

    Now, what i wondered about is that i get a question to save a cookie for the PHPsession and ASP.NET session stuff.
    I find this odd but i am also aware of a setting in ASP.NET which if you set it to cookieless it should solve the session by modifying the url's.
    This last one i have never tested or seen but my question is.., session handles are passed via the header and the browser handles this all for you.
    So why do i need a cookie?

    Anyone having some more knowledge about this subject?
    For a website i write i simply would like to use a session via the header, i assumed that this would be dealt without cookies, in fact i want to try this cookieless.

    At this time i haven't tested what happens with the session if i refuse the cookie.

  • #2
    Tested: it does not handle the session anymore when i refuse cookies.
    Hmm, why the header?


    • #3
      I must be confusing myself, can't find the header on these sites.
      I seen it in the cloud, will check that later, maybe something specific..

      Seems cookiebased only.


      • #4

        I would like to know more about cookies and when they are set up and what they do.

        Are you the right person to take a step back and explain them to me

        Remember I am a 'goto' programmer (but a very experienced and good one!)
        [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
        Kerry Farmer


        • #5
          I know about cookies but not in-depth so maybe you better start a new topic where i and others can respond?
          I am used to ASP.NET where cookies are trivial.
          I am currently doing legacy ASP where the order of responding is important.(sending headers before html and such)
          Though i understand it so far.., i have to dive into that part yet.

          w3schools is the official website so also read here:



          • #6
            Kerry, also see Don Dickinson's comments here:


            • #7
              Thanks guys

              I have read the references etc

              I am now informed!!
              [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
              Kerry Farmer


              • #8
                I use PHP a lot which helped me understand cookies. To a Browser a Cookie is a Cookie that expires. A Session Cookie is a Cookie for the current browsing session that is deleted when the browser closes. Browsers store cookies in files or databases locally. When the domain of the stored cookie matches the domain you are navigating to the browser sends it in the HTTP header. Cookies the server wishes to store are also sent in HTTP Headers in the response.

                PHP and ASP somewhat confuses things calling them session cookies for session files stored server side. PHP allows expiring "session" cookies or having them delete with the browser closing (True Session cookie), so really a "session" cookie to PHP is nothing more than a regular cookie that stores a hash. The cookie name, Hash Type, and Bits per char of the hash can also be customized. This hash is usually equal to or part of the filename that is stored server-side that contains your info that old cookies used to store. A little better privacy this way. I recently overrode the session handling in a PHP application (Using session_set_save_handler) to only use the PHP Session hash and pull data from a database so no data is stored to a file and open to hacking, etc. Then I just store the hash in the user table and delete it when they logout and the session is destroyed. Works pretty slick and faster in a database than in the filesystem as a plain text file that must be parsed.
                Mobile Solutions
                Sys Analyst and Development


                • #9
                  I was certainly confused and really thought there was a sessionID entry in the header like an e-tag.
                  An etag is received from the server and the browser sends it on the next request.
                  I am mistaken about a similar behaviour for sessionid's.
                  I spoke this through today with someone having much more knowledge about these matters.

                  A session is stored in a cookie but with limited time (a short expiry date/time)

                  I am about to program authentication from scratch so i must going to deal with this legacy ASP level of doing things.
                  This means i am partially going to use the session and another cookie for credentials (hash).
                  Reason is that i need to let the session make the cookie invalid (somehow) when the session expires unless they enabled keep me logged in which simply set's a more future date time.

                  Not sure what i precisly want with the session but that crossed my mind at this time.

                  I could skip the relationship between credentials and session, we did that all the time in the past.
                  In the past we simply had credentials cookie and a session for handy data.
                  If the session expires it doesn't mean we have to lose credentials, usually we gather the sessiondata from the db or code again for rapid use.

                  Not sure what i'll do at this time..., just rambling..



                  • #10
                    Yeah, proper handling of session cookies confuses a lot of people. On logout I used to set a cookie with the same name as the session id to nothing and with an expiration date in the past so either way should delete it. I then decided to just set my initial session ID cookie to expire at 0 (meaning when browser closes like a true session cookie...before it was set to expire in 8 hours). I then figured I didn't need to delete it on logout and just destroyed the session. I had it better the first way though and this seems to be a common mistake many others make where when you logout of their site and go back you are still logged in. Session files usually have a garbage collection that deletes them after so long and is at random so could be longer. When you go back the file is still there and your cookie didn't get cleared.

                    So, I kept the expire set to zero, but added my line back that set the cookie to nothing and expiring in the past on logout. The browser still wasn't clearing the cookie though. I ended up having to set the logout cookie to expire at 0 too. Appears Session Cookies/Cookies that expire when the browser closes- are considered different than regular cookies so you can't expire them. Setting them to nothing just deletes them though where with a regular cookie if you didn't expire and just set to nothing you'd sometimes just have an empty cookie.

                    The other thing to watch for is Session Hijacking. HTTP headers on public wifi or something like a Hotel/McDonald's/ATT's unpassworded wifi aren't encrypted. Someone can monitor your traffic and find out your session ID then spoof a cookie and become you. Connecting to Facebook, Twitter, and email over their HTTPS connections helps to avoid this. On your own though you might try just building your own hash possibly mixing IP address and such in there so you can verify the person connecting more. Then if another person tries connecting from somewhere else you know. Perhaps storing a user cookie and a hash of password and IP concatenated or combined in some way. Or store IP address in the user table likes banks do for allowed PCs.
                    Last edited by Roger Garstang; 2 Apr 2012, 04:24 PM.
                    Mobile Solutions
                    Sys Analyst and Development


                    • #11
                      On the account system for my site I generate a GUID for each successful login and store it in a time limited cookie (1 to 365 days) and also store this info as a list entry in the account database. So each time they revisit, the GUID and expiry are checked against the database. Logging out or time expiry erases the entry.

                      Any changes to the user's email/profile data or other important stuff requires immediate re-login (sites like eBay do this). If in any doubt, always void the credentials and ask the user to login again.

                      This is all done with PB CGIs and JavaScript where I need to display login status.

                      P.S: It's not really a good idea to do an IP check for login handling as many IPs are dynamic and will change (unless you're on an Intranet or some other private network)
                      Last edited by Kev Peel; 2 Apr 2012, 06:35 PM.
             | Slam DBMS | PrpT Control | Other Downloads | Contact Me


                      • #12
                        About the session + authentication:
                        For the authentication *without* the 'keep me in logged in longer' option i think i'll use the session indeed.
                        If the user closes the browser and reopens it, it should ignore the cookie with the short expiration date.
                        That's why i want to use a combination of session and credentials cookie.