Zope 2

Bug #142615 (zope2dev-958)
Comment #4

Comment 4 for bug 142615

Revision history for this message

Chris McDonough (chrism-plope) wrote on 2004-08-03:

> This works fine as long as you don´t change the Browser id name. If you
> do, Zope places two Cookies into the browser and creates two SESSION
> objects. The zpt forms (which in my example show some of the entered data
> of the prev. forms) see the one SESSION data, the python scripts see the
> other SESSION data.

The first assertion, that "Zope places two cookies into the browser" I can believe. The first one was put there by the browser id manager when it used the old cookie name and the sessioning machinery was used. The second was put there by the browser id manager when it uses the new cookie name after you make the change. No magic there. The browser can't know that the change was made so it continues to return the "old" cookie. If you close your browser and restart it after doing this rename, and repeat the set of steps that initially caused you problems, you will likely see that only one cookie now exists (the "new" cookie is recreated and the other goes away by virtue of being cleared out of memory when the browser gets shut down). It doesn't matter much that the second one is there; it's just an artifact of what you did last.

(FWIW, I'll note that there's very little reason to have more than one browser id manager in a site. One usually works out fine, regardless of the number of session data managers you have.)

The second assertion, that "The zpt forms see the one SESSION data, the python scripts see the other SESSION data" is likely due to the fact that you're using the "request.SESSION" mechanism for accessing the session. Note that it's possible to have more than one session data manager in play at once in a Zope site. You created a second one in your test folder. Note that there's no way for Zope to really understand *which* session data manager you mean when you ask for "request.SESSION" *except* if you change the "Place SESSION in REQUEST object as" in your new session data manager's Settings tab from the default 'SESSION' to something different. Changing the cookie name in the new browser id manager doesn't help disambiguate the lookup. So depending on how the form that does the session lookup is accessed, it might find the session data manager in the root and get that session data (if you call a method in the context of the root object). Or it might find the one you created in your folder and get that data (if you call a method in the context of your folder or "below").

Disambiguate the two session data managers by changing the "Place SESSION in REQUEST object as" setting (perhaps to SESSION2) and see if the problem disappears by using that name to look up the session data (e.g. request.SESSION2).

OK, thanks for this.  However, although this is a reasonable overview of what you believe generally seems to be a setup that presents you with a problem, but it still isn't enough to replicate the problem "from scratch".  FWIW, I tried to "play along" with this set of steps but got lost somewhere in your description of transporting things between multiple forms.  Sooo.. I'm just going to take the dangerous step of making assumptions because I think this is just a configuration problem rather than a bug.
 
> This works fine as long as you don´t change the Browser id name. If you
>   do, Zope places two Cookies into the browser and creates two SESSION
>   objects. The zpt forms (which in my example show some of the entered data
>   of the prev. forms) see the one SESSION data, the python scripts see the
>   other SESSION data.

The first assertion, that "Zope places two cookies into the browser" I can believe.  The first one was put there by the browser id manager when it used the old cookie name and the sessioning machinery was used.  The second was put there by the browser id manager when it uses the new cookie name after you make the change.  No magic there.  The browser can't know that the change was made so it continues to return the "old" cookie.  If you close your browser and restart it after doing this rename, and repeat the set of steps that initially caused you problems, you will likely see that only one cookie now exists (the "new" cookie is recreated and the other goes away by virtue of being cleared out of memory when the browser gets shut down).  It doesn't matter much that the second one is there; it's just an artifact of what you did last.

(FWIW, I'll note that there's very little reason to have more than one browser id manager in a site.  One usually works out fine, regardless of the number of session data managers you have.)

The second assertion, that "The zpt forms see the one SESSION data, the python scripts see the other SESSION data" is likely due to the fact that you're using the "request.SESSION" mechanism for accessing the session.  Note that it's possible to have more than one session data manager in play at once in a Zope site.  You created a second one in your test folder.  Note that there's no way for Zope to really understand *which* session data manager you mean when you ask for "request.SESSION" *except* if you change the "Place SESSION in REQUEST object as" in your new session data manager's Settings tab from the default 'SESSION' to something different.  Changing the cookie name in the new browser id manager doesn't help disambiguate the lookup.  So depending on how the form that does the session lookup is accessed, it might find the session data manager in the root and get that session data (if you call a method in the context of the root object).  Or it might find the one you created in your folder and get that data (if you call a method in the context of your folder or "below").