[Web-SIG] Session interface, v2
renesd at gmail.com
Sun Aug 21 01:42:34 CEST 2005
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
> > * 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
More information about the Web-SIG