[Web-SIG] Session interface, v2

[Rene Dudfield]

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).