Looks quite good. It should be able to handle all the uses I have for sessions. I am sure it will change a little once it is started to be implemented.
> > * Scenario 2: Same, but the apps are in separate processes. The > > dispatcher remains. (forking servers) > > If the two apps share the same pool of long-lived worker processes, then > all the same issues remain as with scenario 1. This isn't really an > issue of threaded vs. multiprocess, but an issue of processes that run > multiple independent applications over time. A common pool of worker > processes would be similar to PHP, except that PHP tends to throw away > more information each request... though I believe session clobbering > would be a problem in PHP if you had two apps on the same domain that > shared a session variable name. > Yes session clobbering can happen with php. It gets around it by allowing you to set the session.name. Eg PHP_SESSION becomes MY_BLOG_PHP_SESSION. Just like in the proposal with SessionManager and its app_id. http://www.php.net/function.session-name.php > > * Scenario 3: Two apps mounted at /foo and /bar, using separate handlers > > in the Apache config. At no point is there a common Python process > > between them. > > It depends on the configuration, but clobbering could happen here too. > If both apps use the same session id (e.g., they use the same cookie > name) and share session store configuration (they are writing to the > same location), then it will be a problem. Using session managers with > separate app ids they can share session store configuration safely. > > > * Scenario 4: Two apps in different virtual hosts. > > Probably not an issue because the session id won't be shared. A good > session id manager might be able to handle this, though, but forwarding > the user between the two hosts with a special GET variable that triggers > the setting of a cookie; if that was happening it would be like scenario 3. > The most secure way for virtual hosts would be to use different session stores? Using different session stores for separate domains should be the default for a little extra security? However using the same SessionStores accross virtual domains could be quite useful for passing users settings amongst virtual domains(just like Ian said above). _______________________________________________ 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
