Browser ID Manager cookie name problem

Bug #142615 reported by Bug Importer
0
Affects Status Importance Assigned to Milestone
Zope 2
Invalid
Low
Unassigned

Bug Description

Zope Session management works fine as long as you change the cookie name in the browser id manager.
If I change the cookies name, I got two different session data records, one usable in python scripts refering to a session derived from a still set cookie named "_ZopeId" an another session data record referenced to a cookie named as I wanted. This session is used in my page templates. This behavior is not wanted by me, I wanted one session data record, accessable from both, python as well as TAL. This I only get leaving the cookies name untouched .

Tags: bug zope
Revision history for this message
Peter Dreuw (pdreuw) wrote :

I forgot to say, the used browser got both cookies , one with the name "_ZopeId" and one with the entered ID. Both cookies expire after browser session, this all happens with Mozilla as well as IE 6.0.

Revision history for this message
Chris McDonough (chrism-plope) wrote :

I cannot replicate this behavior. Can you provide a set of steps that would allow me to do so?

Revision history for this message
Peter Dreuw (pdreuw) wrote :

I did this using Zope 2.6.2. I did not test that with newer versions.

step1: place a browser_id_manager in your test application folder and change the entry "Browser id name" in the browser_id_manager page to a desired name.

step1b: add a session_data_manager with session_data etc. in the test app folder (and as i did the CookieCrumbler)

step2: build a page template with code that reads some SESSION data

step3: build a python func (in ZMI) that reads or manipulates the SESSION data

step4: glue that together with some nice HTML forms - actually the SESSION was meant to transport form data from multiple forms to the last form. Each form calls a python script that fills the data from thle last form into the SESSION data and calls the next TAL HTML form and so on till the last form is reached an a summary is shown (as zpt)

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.

I consider this a bug. I did not any more research on that, I simply let the name unchanged and that´s it. (But that´s a workaround..) Again, I did that on Zope 2.6.2.

Revision history for this message
Chris McDonough (chrism-plope) wrote :
Download full text (3.2 KiB)

<pdreuw recounts steps to reproduce>

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").

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

Read more...

Revision history for this message
Peter Dreuw (pdreuw) wrote :

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

Well, sorry, I definitely tracked that down to the depicted facts. Any Browser in game als well as the Zope server where restarted after rename of the cookie. (and no proxy nor apache where involved)

> [about two session managers]

Do you mean, that another session manager placed somerwehre in my ZODB - not in the traversed folders - does affect this ? Well if that is the fact, that should be noted in the docs *g*

I´ll test it. Thanks in adv.

Tres Seaver (tseaver)
Changed in zope2:
status: New → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.