[Zope] concurrent logins and Zope

[Carlo Giomini]

On Thu, 25 Jul 2002, Oliver Bleutgen wrote:

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

Oliver, first of all thanks for helping!
 
The techniques you suggest are fine, but I would like to get
rid of cookies as much as possible. 

With regard to keeping track of multiple sessions inside the *same*
browser, you mean that unless using hidden form fields there's no way of
keeping track of multiple sessions on the same machine?

Let me know, regards,
	Carlo.