[Zope] Problem with multiple Browser Id Managers

[Chris McDonough]

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