Add get_session() method to request object

• Key: MODPYTHON-59
• Type: New Feature
• Status: Closed
• Resolution: Won't Fix
• Priority: Major
• Assignee: Jim Gallacher
• Reporter: Jim Gallacher
• Component/s: session
• Affects Version/s: 3.1.3, 3.1.4, 3.2.7

Description

Users will get session instances by calling req.get_session(). If a session already exists it will be returned, otherwise a new session instance will be created. Session configuration will be handled using apache directives rather than within their code.

Using this scheme means only one session instance will be created per request, which will eliminate the deadlock problems many people experience. Also, using this scheme makes it possible for sessions to be properly handled within psp pages and across req.internal_redirect() calls.

Code will be commited to svn shortly.

Comments

[Graham Dumpleton]

I previously commented on this on the mailing list but can't find the
email to reference.

The issue I raised was along the line that in order for this scheme to
be able to work nicely in with other code which creates and manages
session object, there probably also needs to be a way to determine if
the session object has already been created and to explicitly set the
sesssion, thereby bypassing the get_session() method. Ie., I don't
necessarily believe it should just be a black box whose behaviour
can't be overridden.

At minimum, it still should be possible to access the session object as
req.session and set it by assigning to req.session. Working code set
for 3.2 still doesn't appear to allow this.

Wish I could find the email as I may have suggested better reasons
in it. :-(

There is a potential issue with the way that PYSID is stored in the
subprocess_env table and then used to reconstruct the session object
after an internal redirect.

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.

The second problem is that an internal redirect could redirect to a
different part of the URL namespace where the PythonOption for "session"
is set differently. This could for example result in an instance of
Session being created initially but an attempt to create a FileSession
object after the redirect.

In the second case, if the redirect was to a part of the URL namespace
notionally under the same ApplicationPath (implicit or explicit), it is
probably a mistake on the part of the programmer to have specified
different session types within the same SID context. It still could occur
in conjunction with the first case though.

Is my analysis here correct? Along with PYSID it may be necessary to
save away the equivalent of the ApplicationPath (implicit or explicit)
and for the PYSID to be ignored if the target of the internal redirect is
within a different SID context. It would get harder to protect if there were
multiple nested applications of internal redirect. Ie., where you end up
with REDIRECT_PYSID, REDIRECT_REDIRECT_PYSID etc.

[Jim Gallacher]

Defering implentation to 3.3.

[Graham Dumpleton]

For posterity, attaching patch for an alternate way of dealing with this problem of locked Session objects and req.internal_redirect(). This actually avoids any changes to the request object itself, with all code changes in Session code. This was presented on developers mailing list. See:

  http://www.mail-archive.com/[e-mail]/msg00254.html

Experimentation with this idea still needed.

[Jim Gallacher]

General agreement was that the proposed solution for this feature was sub-optimal. The stub for get_session() has been removed from the source.

A new issue should likely be created in the future if another solution to the general problem is found.