quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <jg.li...@sympatico.ca>
Subject Re: [jira] Commented: (MODPYTHON-59) Add get_session() method torequest object
Date Thu, 28 Jul 2005 01:43:24 GMT
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

Mime
View raw message