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