Re: [jira] Commented: (MODPYTHON-59) Add get_session() method torequest object

[Graham Dumpleton <gr...@dscpl.com.au>]

> > 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.

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.

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.

Is my memory that internal redirect does return actually right? Have
no time now to research it.

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.

Graham

Re: [jira] Commented: (MODPYTHON-59) Add get_session() method torequest object

[Jim Gallacher <jg...@sympatico.ca>]

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