> 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 Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com