[Web-SIG] and now for something completely different!

[Shannon -jj Behrens]

> What might be more practical and easier to think about because its scope
> is so much smaller is a a common "browser identifier" implementation.
> 
> The most useful purpose of a session is to allow you to store state
> across requests by some anonymous browser.  If you can reliably detect
> that "the requesting browser is the browser identified by token ABC123"
> and that token can be associated with the browser reliably for some
> extended period of time, that's half the battle.  This can be done with
> a cookie, a URL element, a form variable, or a query string element.
> The association between an identifier and a browser doesn't really even
> need to time out; it could live forever with no ill effect.
> 
> Creating namespaces that can be written to from within application code
> and which expire after some number of minutes of inactivity and so forth
> (aka sessions) could be written in terms of storing and retrieving data
> based on this browser identifier.

It turns out that having one unique ID per browser is a bad idea. 
Specifically, if a client gives you a cookie with an sid, and you've
never heard about that sid (perhaps the session timed out), create a
new sid.  Also, it makes sense to change the sid when the user
successfully logs in.  There are a newly discovered set of session
injection attacks to be avoided:

    http://www.acros.si/papers/session_fixation.pdf

I hadn't heard about them until recently.  It's interesting reading.

I hope you'll find that to be helpful.

Best Regards,
-jj

-- 
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.