Graham Dumpleton wrote:
I can see two problems here. The first is that if the target of the
internal redirect is a part of the URL namespace which is under the
control of a different handler, or where ApplicationPath option was set
explicitly to be different, the PYSID would potentially override a valid
pysid for the alternate SID context provided by the browser.
I get your point but is this actually a problem? Since it's an internal
redirect, the browser will not be aware it is being redirected, so it
will always send the same PYSID cookie. (Did that sentence make sense?)
Even if the second handler sets a session cookie with a path for URL2,
the browser will always send the cookie corresponding to URL1.
Probably true. There may be convoluted cases where if someone was doing
extra wierd stuff with overriding ApplicationPath and playing with the
option being discussed for SessionCookieName, strange things might
occur, but if people get that convoluted they get what they deserve.
Agreed. BTW, Nicolas has already implemented a PythonOption to specify
the cookie name.
One other aspect of this that I have been thinking about is the feature
in there for auto saving and unlocking a session before doing an
internal redirect. In doing this you have changed how things work now
and it does open up slim chance that existing code could break.
Imagine where someone had stored stuff in the session object but then
used internal redirect to force a special error response by triggering a
handler outside of the session context. They didn't save the session
because they wanted to discard their progressive changes. Now that it
does an autosave, it may save stuff up code given that people didn't
want it saved.
Point taken.
Also, you don't recreate the session object after internal redirect has
returned. Since internal redirect returns control back to the caller
still, there is a chance that someone might be expecting to still be
able to use the session object in some way after the internal redirect
has returned.
Except for the session unlock/save, internal_redirect does not touch the
session object. The session is still available to the caller, so there
is no need to recreate it. Or am I missing something?
Is my memory that internal redirect does return actually right?
Yes.
I thus question whether autosave on redirect is a good idea or not.
People can explicitly do it now themselves. If the code is in there,
it should perhaps at least be off by default and require an explicit
option to turn it on. If it has to be turned on though, people may as
well code it themselves.
I've gone back and forth on the autosave. At this point I agree it's
best to leave the saving to the user's code, so I'll take it out. At one
point I raised the possibility of having an autosave for sessions
themselves and people were pretty much against that idea. By extension
internal_redirect shouldn't save the session so we are at least consistent.
I think the automatic session unlock needs to stay. It's just too easy
for the user to forget a manual unlock, deadlock the session and hose
their server in very short order.
Regards,
Jim
