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.