Sune B. Woeller wrote:
hi David,
I had the same problem, see this thread with a workaround, and this bug report: http://www.zope.org/Collectors/Zope/1594
regards, Sune B. Woeller
David H wrote:
Hi List,
I am curious about the SESSION.invalidate() method.
This code sets a SESSION key and value and then calls SESSION.invalidate():
<tal:block define="dummy python:request.SESSION.set('Dodgers','Baseball')" />
<p> before invalidate </p> <p tal:content="python: request.SESSION" />
<tal:block define="dummy python:request.SESSION.invalidate()" />
<p> after invalidate()</p> <p tal:content="python: request.SESSION" />
Produces this output:
before invalidate id: 11125588150079827980, token: 95966850A1xaz-gQYlU, contents: [('Dodgers', 'Baseball')]
after invalidate() id: 11125588150079827980, token: 95966850A1xaz-gQYlU, contents: [('Dodgers', 'Baseball')]
It seems that SESSION.invalidate() does not take immediate effect. Seems like a developer could getinto trouble if the same script *both* does SESSION.invalidate() SESSION.set('something','somevalue').
Because after the script runs 'something' goes away when invalidate() finally occurs.
And is the effect described above to be expected or do I have this wrong?
Thanks, David
Sune,
Thats great! Thanks. My tests confirm this excerpt from Collectors/Zope/1594: 'The suggestion ... to use "context.session_data_manager.getSessionData()" to get the session after the call to invalidate works - it gives me a new session object, and all is well :)' David