Session and Cookies
If you want to allow for user sessions even if users have cookies turned off, you have to insert the session id in every url. (Don't put the user id in the url.)
Two problems with this are that the urls become very long – and may add significantly to the weight of the page – and the urls are very nasty – you wouldn't expect to be able to email them, and even bookmarking is affected – if you bookmark a url with your current session, if you use the bookmark someday when you are already at the website, the results might not be pretty.
Generally, putting session in the url is a bad idea. Don't do it unless you absolutely must support users who have cookies turned off.
You can at least be smart enough to use cookies first, and only switch to the url if cookies are off. First set a cookie. But if you get an http request where the referer is your site, but you don't get a cookie, then assume cookies are off, and put the session in the urls.
That approach fails if the browser doesn't send the referer. If you want to cover browsers that don't send referers (very rare), you could start by sending the session id in both urls and cookie. Then if you get the cookie, drop the session id in the urls.
I would say that you could typically insist customers use a browser that sends the referer. After all, someone who is going to buy a product from you is going to give up their identity, as well as credit card.
If you must provide session in the url, you might consider two url hacks.
1) Put the session code in the base href tag (in the head section of the html page). That way, the webpage would only need to download the session id once, rather than for each link on the page. If you have long session ids, and many links, this might be helpful.
2) Use redirect and referer to get clean, bookmarkable, emailable urls. The urls in the webpage should all have the session id, but the server would redirect the browser to the clean url, and get the session id from the http referer environment variable. It seems like too much work for too little benefit, but there might be a situation where it would be useful.
If security is an issue, you must either force users to log in each time they enter a secure area (even during a single session), or you must simply run the entire session on a secure server.
Copyright © 1998-2011 J. R. Boynton