session within standard_error_message
Can you set values inside the session object from within standard_error_message? I note that doing a request.RESPONSE.redirect requires a "lock=1" arg, I'm wondering if session variable setting suffers similar problems or not. Reason I ask is, I have an app that tries to set session variables within the standard_error_message, and debug indicates the variables are there within that transaction, but gone on the next request from the browser. KevinL
This is because the database transaction which contained the session write is aborted on an error.. this is "normal" Zope behavior, and unfortunately there's no easy way around it. Why do you want to set a session variable on an error display, maybe there's a better way? ----- Original Message ----- From: "KevinL" <darius@obsidian.com.au> To: <zope@zope.org> Sent: Thursday, August 01, 2002 11:12 AM Subject: [Zope] session within standard_error_message
Can you set values inside the session object from within standard_error_message? I note that doing a request.RESPONSE.redirect requires a "lock=1" arg, I'm wondering if session variable setting suffers similar problems or not.
Reason I ask is, I have an app that tries to set session variables within the standard_error_message, and debug indicates the variables are there within that transaction, but gone on the next request from the browser.
KevinL
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Fri, 2002-08-02 at 02:14, Chris McDonough wrote:
This is because the database transaction which contained the session write is aborted on an error.. this is "normal" Zope behavior, and unfortunately there's no easy way around it. Why do you want to set a session variable on an error display, maybe there's a better way?
Laziness mostly, I suspect. I'm abusing standard_error_message to catch an auth failure and bounce the user to a different folder/product instance based on the '@domain' portion of their username. The right way(tm) is to write my own auth module, but I haven't had time to deal with that for this project - it's high on the list of changes once we're clear the current press. In the meantime, it looks like setting a cookie on the client, combined with redirecting them, may work - although I'm a bit concerned about browser-specific issues with that "solution". The problem, essentially, is that I have a system that allows creation of multiple "realms", and only have a single login page (in a default realm). If the user enters "user@realm" as the username to that login page (each realm being a completely separate instance of a product), I need to quietly redirect them to the appropriate location and log them in - without allowing the username and/or password to appear in the URL (ie. not a get request, hence no meta-refreshes). I've hacked up exUserFolder to get most of what I needed, but it's a bit rough. I was going to lean on session data for holding user/pass over the redirect, but that doesn't work, more's the pity. Not to worry, I'll bludgeon it into submission for now, and clean off the edges in a week or two when it all calms down a bit. Thanks all for responses. KJL
KevinL wrote:
Reason I ask is, I have an app that tries to set session variables within the standard_error_message, and debug indicates the variables are there within that transaction, but gone on the next request from the browser.
Short version: You can't set session information in standard_error_message. The session info is stored in a ram-based ZODB. Now, because an error has occured, the ZODB transaction has most likely been aborted by the publisher, hence your values aren't actually stored in the session. cheers, Chris
KevinL writes:
Can you set values inside the session object from within standard_error_message? I note that doing a request.RESPONSE.redirect requires a "lock=1" arg, I'm wondering if session variable setting suffers similar problems or not. I am not sure, but I fear you cannot modify the session in "standard_error_message". My reasoning:
The transaction has already been aborted (and no new one started) when "standard_error_message" is executed. I do not know what happens when you write to the ZODB (and especially a session) in this state. I would expect that the modification is non-deterministic: it may or may not be written to the ZODB; it may or may not be seen by subsequent requests. A very bad situation... Dieter
participants (4)
-
Chris McDonough -
Chris Withers -
Dieter Maurer -
KevinL