[Web-SIG] and now for something completely different!
Shannon -jj Behrens
jjinux at gmail.com
Thu Aug 18 22:19:10 CEST 2005
> 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.
More information about the Web-SIG
mailing list