Session Cookies - When? Where? Why?
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Session Cookies - When? Where? Why?
Sessions are integral to many applications, but in some areas I see them used when they're strictly not necessary. I'd like to know about your views on when session cookies should be used (logged in or all the time), where they should be used (dynamic pages or all pages), and why they should be used (versus an anonymous identifier sent via a form). For example:
Front page session cookie blues: Until Firefox supports the ability to automatically keep Session cookies and ask me about the rest, I am annoyed at the fact that websites that I have never visited before and I have no intention of using any of their cross-request features automatically ask me if I'd like a cookie. I end up blocking most of them, which does cause some trouble if I actually decide I want to log in (in which case I have to unblock the cookie).
On the developer's side, you could try selectively initializing the session, perhaps, when the user logs in, but if you have any sort of feature that requires persistence for anonymous users (perhaps a Captcha for anonymous comments), you'll have to either start the session or implement your own system of data persistence that doesn't need a cookie (for Captcha's, its not that bad, because the only persistence necessary is between the page where the captcha is served and the page the comment is submitted. However, other features are not as lucky).
Of course, I could be blowing this problem way out of proportion. How many users actively block cookies? Most Internet Explorer users won't mind having ten cookies dumped on them in the first page. Once you've given the okay for a site to set cookies, they never bother you again. Is it really that important?
One last question, and it involves when a user logs out. Obviously, you should destroy all session variables that particular application set during the session so that a hacker with the session can't log in. Is there any point in taking this further and destroying the session cookie itself, so that the session id is regenerated the next time the user logs in? Or is it better just to let the session linger and make a new one when the time comes?
Front page session cookie blues: Until Firefox supports the ability to automatically keep Session cookies and ask me about the rest, I am annoyed at the fact that websites that I have never visited before and I have no intention of using any of their cross-request features automatically ask me if I'd like a cookie. I end up blocking most of them, which does cause some trouble if I actually decide I want to log in (in which case I have to unblock the cookie).
On the developer's side, you could try selectively initializing the session, perhaps, when the user logs in, but if you have any sort of feature that requires persistence for anonymous users (perhaps a Captcha for anonymous comments), you'll have to either start the session or implement your own system of data persistence that doesn't need a cookie (for Captcha's, its not that bad, because the only persistence necessary is between the page where the captcha is served and the page the comment is submitted. However, other features are not as lucky).
Of course, I could be blowing this problem way out of proportion. How many users actively block cookies? Most Internet Explorer users won't mind having ten cookies dumped on them in the first page. Once you've given the okay for a site to set cookies, they never bother you again. Is it really that important?
One last question, and it involves when a user logs out. Obviously, you should destroy all session variables that particular application set during the session so that a hacker with the session can't log in. Is there any point in taking this further and destroying the session cookie itself, so that the session id is regenerated the next time the user logs in? Or is it better just to let the session linger and make a new one when the time comes?
Well, that's where you're wrong... Most IE users don't fiddle with cookies, and that means, if they do end up blocking your cookies, it's because of Microsofts updates automatically doing it for them. I've had this problem with many of my visitors.
Edit: And to the last paragraph, couldn't that be a bad thing? Why not delete all sessions of their visit? It could conflict with a user who uses a public computer OR has other people using the PC. Although that'd probably be a low case of that happening.
Edit: And to the last paragraph, couldn't that be a bad thing? Why not delete all sessions of their visit? It could conflict with a user who uses a public computer OR has other people using the PC. Although that'd probably be a low case of that happening.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
It's the P3P thing, right? I heard it's only a problem when third parties try to set cookies.
Edit One - Although, I'm asking for a more general outlook on sessions overall.
Edit Two - That makes sense, especially if the web app has to coexist with others on the same domain: killing one session cookie will kill it for all of them, so you shouldn't be greedy. Of course, the same would result from regenerating the session id, so I guess you should just keep the session IDs the same.
Edit One - Although, I'm asking for a more general outlook on sessions overall.
Edit Two - That makes sense, especially if the web app has to coexist with others on the same domain: killing one session cookie will kill it for all of them, so you shouldn't be greedy. Of course, the same would result from regenerating the session id, so I guess you should just keep the session IDs the same.
And this suggestion comes from a non-expert person, so if it seems a little novice, that's because I am ^_^; This is the only Theory and Design thread i could actually contribute to without getting confused.
Personally, I'd love to use sessions on my website, but I get more confused with all the things I'd have to switch ~_~
Personally, I'd love to use sessions on my website, but I get more confused with all the things I'd have to switch ~_~
I personally like to start a session immediately, so yes my front page will try to set a cookie. Depending on the scale/security of the site, I'll have the fallback to GET enabled or not. When its disabled, I'll also normally enable the cookie via SSL on as well.
I have only once found a reason to set more than one cookie and don't like that one tme, but haven't had a a good reason to revisit it yet. I haven't grokked the Cliest Session State pattern yet from PoEAA so I'm not sure why you'd ever want to set multiple cookies.
I think a lot of the "front page cookie blues" is caused by ad supported sites where all the advertisers are trying to set a cookie.
I have only once found a reason to set more than one cookie and don't like that one tme, but haven't had a a good reason to revisit it yet. I haven't grokked the Cliest Session State pattern yet from PoEAA so I'm not sure why you'd ever want to set multiple cookies.
I think a lot of the "front page cookie blues" is caused by ad supported sites where all the advertisers are trying to set a cookie.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Hmm... I was always under the impression that passing session IDs over GET parameters was a really insecure way of doing business: any site that uses Sessions to handle user logins should not use this method of passing Session IDs.I personally like to start a session immediately, so yes my front page will try to set a cookie. Depending on the scale/security of the site, I'll have the fallback to GET enabled or not. When its disabled, I'll also normally enable the cookie via SSL on as well.
Well, you'd want to set a non-session cookie for a "remember me" feature.I have only once found a reason to set more than one cookie and don't like that one tme, but haven't had a a good reason to revisit it yet. I haven't grokked the Cliest Session State pattern yet from PoEAA so I'm not sure why you'd ever want to set multiple cookies.
True. Fortunantely, IE has taken steps to stop this tomfoolery via P3P.I think a lot of the "front page cookie blues" is caused by ad supported sites where all the advertisers are trying to set a cookie.
It should, theoretically, be third party cookies, regular cookies should be okay. Well, that's what you get what you pay for.That's why my cookies occasionally don't work... My webhost has stupid smurf galore <_<
Hmm... I think I might just throw my arms up in the arm and start initializing sessions at the very soonest.
Theoretically, though, this function would let you call session_starts with impunity regarding E_NOTICEs, am I correct?
Code: Select all
function safe_session_start() {
if (session_id() == "") {
session_start();
}
}Yes I agree. That's why I often set the php.ini for sessions.use_only_cookies to 1. However, using a non-SSL cookie is only marginally more secure than useing GET, so I'll normally also change session.cookie_secure to 1 as well.Ambush Commander wrote:Hmm... I was always under the impression that passing session IDs over GET parameters was a really insecure way of doing business: any site that uses Sessions to handle user logins should not use this method of passing Session IDs.I personally like to start a session immediately, so yes my front page will try to set a cookie. Depending on the scale/security of the site, I'll have the fallback to GET enabled or not. When its disabled, I'll also normally enable the cookie via SSL on as well.
True, but that won't be a front page cookie. So its not part of the initial onslaught of cookies and its in direct response to a user request, so its ok.Well, you'd want to set a non-session cookie for a "remember me" feature.I have only once found a reason to set more than one cookie and don't like that one tme, but haven't had a a good reason to revisit it yet. I haven't grokked the Cliest Session State pattern yet from PoEAA so I'm not sure why you'd ever want to set multiple cookies.
That looks OK, but if you're going to start a session on everypage, why not just move yourTheoretically, though, this function would let you call session_starts with impunity regarding E_NOTICEs, am I correct?Code: Select all
function safe_session_start() { if (session_id() == "") { session_start(); } }
session_start() into some include that's used on every page?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Does that mean that you don't have to be using https to use ssl on cookies? And SSL has certificate stuff: will a user be prompted if an untrusted cert is recieved for cookie transfer (for example, the cert that came with my site points to the wrong server, so users are asked things like "Do you want to trust http://www.server297.com/? It might be masquerading as http://www.thewritingpot.com/")nielsene wrote:Yes I agree. That's why I often set the php.ini for sessions.use_only_cookies to 1. However, using a non-SSL cookie is only marginally more secure than useing GET, so I'll normally also change session.cookie_secure to 1 as well.Ambush Commander wrote:Hmm... I was always under the impression that passing session IDs over GET parameters was a really insecure way of doing business: any site that uses Sessions to handle user logins should not use this method of passing Session IDs.I personally like to start a session immediately, so yes my front page will try to set a cookie. Depending on the scale/security of the site, I'll have the fallback to GET enabled or not. When its disabled, I'll also normally enable the cookie via SSL on as well.
Right. For initial cookies, one cookie seems about right.nielsene wrote:True, but that won't be a front page cookie. So its not part of the initial onslaught of cookies and its in direct response to a user request, so its ok.Well, you'd want to set a non-session cookie for a "remember me" feature.I have only once found a reason to set more than one cookie and don't like that one tme, but haven't had a a good reason to revisit it yet. I haven't grokked the Cliest Session State pattern yet from PoEAA so I'm not sure why you'd ever want to set multiple cookies.
Well, that's just in case I decide to selectively start sessions when they're needed.That looks OK, but if you're going to start a session on everypage, why not just move yourTheoretically, though, this function would let you call session_starts with impunity regarding E_NOTICEs, am I correct?Code: Select all
function safe_session_start() { if (session_id() == "") { session_start(); } }
session_start() into some include that's used on every page?
It requires SSL and a cert. So yes, I know its not possible for all uses. But I do feel that too many developers decide that SSL is too much of a hassle, when they really should look into it. You can get cheap hosts that allow you to use SSL and you can get cheap SSL certs that are recognized by 99% of the browsers out there. There's also one free SSL cert issuer that about to be included in FF's root chain; I've heard they're working on MSIE 7. If they get both then that's going to be a great option and the others will pick them up probably.Ambush Commander wrote:Does that mean that you don't have to be using https to use ssl on cookies? And SSL has certificate stuff: will a user be prompted if an untrusted cert is recieved for cookie transfer (for example, the cert that came with my site points to the wrong server, so users are asked things like "Do you want to trust http://www.server297.com/? It might be masquerading as http://www.thewritingpot.com/")nielsene wrote:Yes I agree. That's why I often set the php.ini for sessions.use_only_cookies to 1. However, using a non-SSL cookie is only marginally more secure than useing GET, so I'll normally also change session.cookie_secure to 1 as well.Ambush Commander wrote: Hmm... I was always under the impression that passing session IDs over GET parameters was a really insecure way of doing business: any site that uses Sessions to handle user logins should not use this method of passing Session IDs.