I've been into this research in the last week as well, but haven't made any conclusions yet. We use cookies in several sites now, and while over the last 2 years or so cookier-related tech support calls have declined markedly, we'd still like cookie-less solution.

However, some PM threads that have been excellent, useful or informative are:

• practical aspects of sessions and state
• Polling All Monks: Favorite Ways To Maintain State
• Writing web pages in Perl with sessions
• Adding "state" to HTTP to save saintmerlyn from having to post this link... :)
• the best way to implement persistent data across CGI scripts
• (OT) Security Rant
• Maintaining state with CGI.pm

Plus, in the last 48 hours, unless I'm hallucinating (which shouldn't be true), I thought I saw a recent release of something (for Apache?) that handles cookie-less state management. However, I can't find it again.

Hope the links help with the review of the philosophies and/or methods of cookie-less state.

Doing without cookies means embedding a unique number in every link, sort of like: http://mysite.com/cgi-bin/script.cgi?cookienum=32984563298745&action=showpage. Then every time someone clicks a link you extract the number on use it to load the session data. Quite painful, but certainly doable. It also gets worse if you generate a new unique number for each page (people can't press the back button any more).

____________________
Jeremy
I didn't believe in evil until I dated it.

-- Randal L. Schwartz, Perl hacker

The biggest disadvantage is the ease in which a session can be hijacked.

If, for example, you cut and paste the URL and email it to another person, they will have your session. Its a rather simplistic example, but is a threat I would consider, especially if you have personal information on your site.

Here is a good article outlining good web session security. It may be a little overkill, but great reading.

Update: To help cover against the hijacking, a different token should be used for every page sent.

Well, considering that the contents of the session cookie is sent to the server with each HTTP request, a cookie solution isn't that much secure anyway. If someone monitors your network traffic, hijacking the session is trivial no matter if you are using cookies or not. The only antidote is to connect through an encrypted channel.

Granted, it's easy to cut&paste the URL and mail it to someone else, but if you're that eager to compromise your own security you could just as well edit the contents of cookies.txt.

Cheers,
--Moodster

If you embed session the URL, use some common sense:
• if a session shows no activity for 30 minutes, kill the session and start a new one. depending on your site, this may mean asking for a login, or it may mean just cutting a new session key.
• if a session comes in that is "inconsistent" (different browser type, different referrer, etc) with the last session request, kill the session.
• as merlyn says here, make the session key unguessable
While these don't fix the problem completely (eg users coming in from AOL via the same AOL proxy machine might be able to swap sessions if they do it reasonably quickly), they go a long way to reduce it.
nop