6.6. Sessions

Sessions are a way for the server to keep in memory information related to an individual user while he is browsing from page to page

Suppose you are on a site where you've found two CD's you'd like to order ; then on another page you find a book. After that you'll be asked a few questions about your address, a message to send if it's a present, then they'll want to know about you credit card. After that you'll be presented a page with all the info you've entered so far and asked if you want to confirm you purchase

Without sessions this would be difficult ; you'd have to pass all previous information as hidden form fields, which would be difficult to implement

With sessions it becomes very easy ; the user is identified with a "session identifier" which is sent with every request to the server under the form of a cookie. This identifier matches an object in the server to which attributes can be set or retrieved throughout the user's navigation

With Karrigell, on each page where you want to modify or access session information, begin by creating a session objet by :

sessionObj=Session()

If you're at the beginning of the session, Karrigell will generate a cookie called sessionId and send it back to the web browser. On subsequent requests, the browser will automatically send this cookie and the server will find the associated object

You can set attributes to this session object :

sessionObj.name = "John Doe"

From another script you'll have access to this value by :

name = Session().name

Session objects support a close() method, which causes the session information to be discarded

You don't really have to explicitely close a session ; Karrigell makes sure there are not more than 1000 simultaneaous sessions and erases the oldest ones when the 1000th is reached

Warning : there is a risk of the integrity of the session object if several, almost simultaneous requests are sent by the same user agent and modify this object. It is the case if a page holds frames or iframes : since the order in which the requests are handled is not predictable, it is mandatory to design the application to avoid this kind of situation

6.6.1 Persistent and in-memory sessions

The session object can be stored either in memory or on disk (persistent) : this is determined by the server configuration option persistent_session

For in-memory sessions, you can set any value as attribute to the session object, including instances of user-defined classes, connections to databases, etc.

Unfortunately, in-memory sessions can only work in a mono-process environment, such as the built-in monoprocess server ; it doesn't work in a multithread or multiprocess environment such as the built-in multithread server or behind Apache. In these cases, you must use persistent sessions, and you can only store Python built-in types in the session object

6.6.2 Example

<h3>Who are you ?</h3>
<form action="sessionTestBegin.pih">
Name <input name="myname">
<br>First name <input name="firstname">
<br><input type="submit" value="Ok">
</form>

The script will receive the input through QUERY or the form field variables in the namespace, create a session objet and save name and firstname as attributes of this object :

<h3>Begin session</h3>
<%
sessionObj=Session()
sessionObj.name=_myname
sessionObj.firstname=_firstname
print sessionObj.name
%>
<a href="sessionTestFollow.pih">Next...</a>

The next script is called without any query string, but it will retrieve the information through the session object :

<h3>Session test goes on</h3>
<%
session=Session()
print session.firstname
session.close()
%>

Because the script has closed the session, if you go back to the previous page with your browser and try again the Next... link you'll get a nice Python traceback telling you that the session doesn't have a firtsname attribute any more. Modify the script by deleting or commenting the session.close() line and see what happens