Page 1 of 1
Session Cookies - When? Where? Why?
Posted: Sat Jul 30, 2005 10:12 am
by Ambush Commander
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?
Posted: Sat Jul 30, 2005 10:15 am
by theda
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.
Posted: Sat Jul 30, 2005 10:18 am
by Ambush Commander
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.
Posted: Sat Jul 30, 2005 10:46 am
by theda
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 ~_~
Posted: Sat Jul 30, 2005 10:55 am
by nielsene
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.
Posted: Sat Jul 30, 2005 10:59 am
by theda
That's why my cookies occasionally don't work... My webhost has stupid <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> galore <_<
Posted: Sat Jul 30, 2005 11:06 am
by Ambush Commander
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.
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 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, you'd want to set a non-session cookie for a "remember me" feature.
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.
True. Fortunantely, IE has taken steps to stop this tomfoolery via P3P.
That's why my cookies occasionally don't work... My webhost has stupid smurf galore <_<
It should, theoretically, be third party cookies, regular cookies should be okay. Well, that's what you get what you pay for.
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();
}
}
Posted: Sat Jul 30, 2005 11:13 am
by nielsene
Ambush Commander wrote: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.
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.
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.
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, you'd want to set a non-session cookie for a "remember me" feature.
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.
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();
}
}
That looks OK, but if you're going to start a session on everypage, why not just move your
session_start() into some include that's used on every page?
Posted: Sat Jul 30, 2005 11:18 am
by Ambush Commander
nielsene wrote:Ambush Commander wrote: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.
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.
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.
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:
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, you'd want to set a non-session cookie for a "remember me" feature.
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.
Right. For initial cookies, one cookie seems about right.
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();
}
}
That looks OK, but if you're going to start a session on everypage, why not just move your
session_start() into some include that's used on every page?
Well, that's just in case I decide to selectively start sessions when they're needed.
Posted: Sat Jul 30, 2005 12:15 pm
by nielsene
Ambush Commander wrote:nielsene wrote: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.
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.
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/")
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.