[Zope] concurrent logins and Zope

[Oliver Bleutgen]

Carlo Giomini wrote:
> Hi everybody,
> I'd like to know if Zope can keep track of concurrent logins of the same
> user and treat them independently.
> 
> Let's say user 'foo' connects to a portal and has many tasks to do (at the
> same time). He keeps an open browser window for each of them, logging in
>>from each window (from now on I will call 'session' the whole sequence of
> actions issued from the same browser window, starting from login up to
> logout):
> 
> what I'm thinking of is having the possibility to 'isolate' one login from
> another (of the same user at the same time) and keep track of each of
> these 'sessions' independently from one another: does Zope support this
> kind of task some way? I mean does it have internal structures, APIs,
> functions etc to do this or do I have to code the whole mechanism from
> scratch? 
> 
> It's worth noting that the point is not only telling one browser window
>>from another (the BrowserIdManager fits well here), but also (mostly)
> keeping track of every 'session' (group of actions issued from the same
> browser by the same user) in parallel with every other. 
> 
> Of course the opposite situation could come handy as well: treating all
> the requests (issued by the same user) as an unique 'session', without
> regard of the browser window these were issued from. 
> 
> Any help will be appreciated (also references to source code). Thanks in
> advance, cheers,
> 	Carlo.
> 
> P.S. With 'keeping track of a session' I mean keeping track of the status 
> 	of the user related to that session, in some data structure like
> 	a table, dictionary, etc.  

I think zope has no API to somehow keep track of session inside the the 
same browser. This means also, that it's not possible to differentiate 
browser windows of the same browser, that is not possible with 
BrowserIDManager AFAIK.
The reason is, that there is simply not the instrumentary in http to 
keep state information which could fullfill that (barring some sort of 
hidden attributes/form stuff (ab)use).

But you could use the cookie domain property to seperate your sessions. 
Let's say you need two session, like "edit" and "view", then you could 
introduce a new host, say edit.yourhost.com. That way the cookies could 
be seperated. With some virtual host/apache config trickery you could 
scale that relativly well, adding some dns trickery to the game would 
make it possible to scale that ad infinitum. Didn't have to do that 
before, but it's possible to direct abc.somedomain.com to the same 
webserver regardless what abc is.

Another, perhaps simpler, possibility is to use the path to restrict the 
effect of a cookie in your server. Add a "work" folder in to top level 
of your zope hierachy and restrict the cookie path of your "work" cookie 
to that folder. Via acquisition, you can now inject the work folder on 
top of your normal folder (i.e. /content/foldera/index_html gets 
/work/content/foldera/index_html) and the "work" cookie is only active 
there. As above with the domain thing, this is scalable ad infinitum 
when you use a special object instead of a simple folder - for instance 
a python script - and use that to insert arbitrary elements at the 
beginning of your path.


cheers,
oliver