> 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.
_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
