Problem with multiple Browser Id Managers
Hello all, I have a situation here; as I has previously posted, I need to set the domain/host for of the cookie that stores the session id so it is shared among multiple subdomains. As Dieter has pointed to me, I should change the 'domain' property for the Browser Id Manager (from now on BMI) that controls the session. Unfortunately, my Zope instance holds multiples virtual sites, so I can't simply change the root BMI that comes with Zope's installation; instead I need to create inner BMI instances. So I did, giving the new instance a different Browser Id Name than the root's _ZopeId both to differentiate them and to be more site-specific. Then I restarted Zope (don't know if this really matters) and re-entered the site to see what happened: I was still given the same cookie, _ZopeId. Reading the documentation I found this quote (browser-add.stx): """ Instantiating Multiple Browser Id Managers (Optional) (...) In its default configuration, Zope will not allow you to create a browser id manager if one is installed in the root or in a place where the new browser id manager can acquire the original browser id manager via its containment path (for programmers: the session id manager's class' Zope __replaceable__ property is set to UNIQUE). This means, practically, that if you wish to have multiple browser id managers, you need to carefully delete the root browser id manager, then you need to place additional browser id managers in the most deeply-nested containers first, working your way out towards the root, finally replacing the root browser id manager if desired. """ ...which is either false or (more likely), outdated, since first (as I said) I had no trouble in adding another deeper BMI; and second, because any attempt to delete root's BMI ends in a "/browser_id_manager/ cannot be deleted." page error message. Any hint? Thanks all in advance, Pablo Ziliani
Hi Pablo, On Thu, 2005-11-17 at 22:47 -0300, Pablo Ziliani wrote:
Unfortunately, my Zope instance holds multiples virtual sites, so I can't simply change the root BMI that comes with Zope's installation; instead I need to create inner BMI instances. So I did, giving the new instance a different Browser Id Name than the root's _ZopeId both to differentiate them and to be more site-specific. Then I restarted Zope (don't know if this really matters) and re-entered the site to see what happened: I was still given the same cookie, _ZopeId.
I'll assume that you mean you're getting the same set-cookie header from Zope rather than meaning that your browser continues sending the same "_ZopeId" cookie back to the site.
Reading the documentation I found this quote (browser-add.stx):
"""
Instantiating Multiple Browser Id Managers (Optional)
(...) In its default configuration, Zope will not allow you to create a browser id manager if one is installed in the root or in a place where the new browser id manager can acquire the original browser id manager via its containment path (for programmers: the session id manager's class' Zope __replaceable__ property is set to UNIQUE). This means, practically, that if you wish to have multiple browser id managers, you need to carefully delete the root browser id manager, then you need to place additional browser id managers in the most deeply-nested containers first, working your way out towards the root, finally replacing the root browser id manager if desired. """
...which is either false or (more likely), outdated,
Both.
since first (as I said) I had no trouble in adding another deeper BMI; and second, because any attempt to delete root's BMI ends in a "/browser_id_manager/ cannot be deleted." page error message.
Any hint?
I suspect it's a bug that the root browser id manager cannot be deleted. That said, it shouldn't be necessary to delete it, as the session data manager will use the "first" bid manager it finds in its acquisition path to get the browser id (see Products/Sessions/SessionDataManager.py). In your case, probably what's happening is that the machinery is finding the /session_data_manager object at the root, and the "first" bid manager in *its* acquisition path is the root /browser_id_manager. If you also create a 'session_data_manager' object in your site, this one should be found and it should use its peer 'browser_id_manager' object. This area is somewhat murky as it's unusual to need multiple browser id managers per server, so I'll be interested to know if creating a session data manager fixes this problem. - C
Thanks Chris and Dieter for your feedback, please see my notes below. Chris McDonough wrote:
On Thu, 2005-11-17 at 22:47 -0300, Pablo Ziliani wrote:
since first (as I said) I had no trouble in adding another deeper BMI; and second, because any attempt to delete root's BMI ends in a "/browser_id_manager/ cannot be deleted." page error message.
Any hint?
I suspect it's a bug that the root browser id manager cannot be deleted. That said, it shouldn't be necessary to delete it, as the session data manager will use the "first" bid manager it finds in its acquisition path to get the browser id (see Products/Sessions/SessionDataManager.py). In your case, probably what's happening is that the machinery is finding the /session_data_manager object at the root, and the "first" bid manager in *its* acquisition path is the root /browser_id_manager. If you also create a 'session_data_manager' object in your site, this one should be found and it should use its peer 'browser_id_manager' object.
This area is somewhat murky as it's unusual to need multiple browser id managers per server, so I'll be interested to know if creating a session data manager fixes this problem.
- C
Adding the new session_data_manager did the trick as you both suggested, THANKS! However, my first attempt was unsuccessful as upon creation I had set it to use an non-existing Transient Object Container (TrOC) under /temp_folder, in hope that this would create it at the same time. Yes, I know how easily I come to complicate things, but my hope was actually real: I did got both objects created... until I restarted Zope of course, where (consistently with its container function) I lost the new TrOC forever. I can see in OFS/Application.py that both the temp_folder and the default Transient OC are recreated on startup, so I guess that the only way to get a "permanent" TrOC is by monkey patching Zope, what of course is beyond my needs, given that I can use (as I finally did) the default TrOC. However now my question is: can't this configuration lead to session collisions, given that now I have multiple BIMs/SDMs making writes to the same TrOC? Thanks in advance for your advise, Pablo
Pablo Ziliani wrote at 2005-11-18 20:37 -0300:
... using the same "session data container" by various "session data manager"s ... However now my question is: can't this configuration lead to session collisions, given that now I have multiple BIMs/SDMs making writes to the same TrOC?
In principle, it could -- but with very low probability and not more as when it is used with a single "session data manager": The "session data container" essentially is a map of session ids to session objects. Of course, if different requests get the same session id (which in fact is a browser id) they may get the same session object. Even a single browser id manager does not explicitely protect itself from handing out the same browser id twice. But the probability is very low indeed: the session id consists of a time stamp (second resolution, I think) and a 4 byte (pseudo) random number. Thus, to get the same browser id twice, the requests need to be within the same second and the pseudo random number generator must return the same number. *BUT* not sure whether the (pseudo) random number generator behaves well in the presence of multiple threads accessing it concurrently. It may well be that it delivers the same number for different threads accessing it concurrently which *MUCH* higher probability as one would expect... -- Dieter
Dieter Maurer wrote:
Pablo Ziliani wrote at 2005-11-18 20:37 -0300:
... using the same "session data container" by various "session data manager"s ... However now my question is: can't this configuration lead to session collisions, given that now I have multiple BIMs/SDMs making writes to the same TrOC?
(...) Even a single browser id manager does not explicitely protect itself from handing out the same browser id twice. But the probability is very low indeed: the session id consists of a time stamp (second resolution, I think) and a 4 byte (pseudo) random number. (...) *BUT* not sure whether the (pseudo) random number generator behaves well in the presence of multiple threads accessing it concurrently. It may well be that it delivers the same number for different threads accessing it concurrently which *MUCH* higher probability as one would expect... (...)
Ok, this sounds fairly safe to me. Besides, my sites aren't that heavily loaded yet and I'm actually keeping the installation's default number of threads (4). Again, thanks a lot, Dieter. Pablo
Pablo Ziliani wrote at 2005-11-17 22:47 -0300:
... BrowserIdManager ... Unfortunately, my Zope instance holds multiples virtual sites, so I can't simply change the root BMI that comes with Zope's installation; instead I need to create inner BMI instances. So I did, giving the new instance a different Browser Id Name than the root's _ZopeId both to differentiate them and to be more site-specific.
The "BrowserIdManager" remains usually passive (unless you encode the session id as port of the Url). It is usually the "SessionDataManager" which activates the "BrowserIdManager". Thus, if you need local "BrowserIdManager"s, you must use local "SessionDataManager"s as well (a standard "SessionDataManager" located the "BrowserIdManager" via acquisition and the fixed name). -- Dieter
participants (3)
-
Chris McDonough -
Dieter Maurer -
Pablo Ziliani