There's a requirement for the unalog project to allow users to pass in
an arbitrary number of form params, be authenticated if necessary, and
then process the form with their original params.  The authentication
step is modular to allow folks to plug in an custom adapter to use local
infrastructure.  E.g., here we need to bounce users to a remote central
web authentication service, which, when successful, passes back a user
id and form parameter for verification in a separate server-initiated
follow-up step; the default login model is a simple login/pass screen
within the app itself.

Users need to be able to pass in an arbitrary number of form params
because they might be redirected to a unalog instance from a variety of
other web applications (a bookmarklet, a library resource); this
redirection will eventually pass along arbitrary parameter profiles from
the NISO OpenURL specs.

Before the authn step was modularized I just captured a few necessary
params before the login screen, and passed those through by hand with
hidden params in the login form.  This breaks down with (a) the
potentially large set of arbitrary form parameters and (b) alternate
authn. models, like ours here, which bounce out of the application and
back, losing query_strings and such.

I'm having trouble stuffing the form params away long enough to recover
them and redirect newly-logged-in users to their original path, along
with the original params.  I've tried a few approaches to saving them in
the session, but the post-successful-login request seems to always kick
up a brand-new session.  Calling get_session() on the original request
for not-logged-in users and overriding has_info() as directed, then
calling session_mgr.commit_changes(), etc. doesn't seem to save the
session and send the session cookie either.

This seems to happen in multiple browsers on multiple platforms.  Cookie
paths and other settings all seem correct as far as I can tell.
Logged-in users just seem to always get a new session, with either authn
module.  So, I'm not sure whether this is due to ignorance, or
incompetence, but I'm missing something obvious. :)  I've re-read the
session doc, and searched through the msg archive, but don't yet see the
answer.

Fwiw I'm using qx-0.7a3 with medusa or scgi, dulcinea-0.1 sessions in
ZODB, rh9, python 2.2.3.  The main reason not to have upgraded to qx-1
or python 2.3 is that we need to get this app running asap and upgrading
might take a few days; if getting it running correctly might require
upgrading one or more of these other pieces first, then, no problem.

Any ideas/debugging suggestions/gifts of clue would be greatly appreciated.

Many thanks, -Dan


--
Daniel Chudnov
Yale Center for Medical Informatics
(203) 737-5789