[Tutor] mod_python authentication

[Alan Plum]

On Mo, 2009-12-07 at 09:35 -0400, Rayon wrote:
> How do I Check for an active login session on every page that requires
> authentication
>  
> Been at this for days and it’s holding me back can someone  plz help
> me with some code examples.

To understand sessions you first need to understand that HTTP is a
stateless protocol: you connect, send your request, receive a response
and the connection is closed.

Sessions add a layer of abstraction to create functionality the protocol
doesn't provide: multiple requests are grouped and treated as belonging
together.

There are several ways to accomplish this. The most straightforward way
would be remembering the client's IP and persisting variables as
relative to that IP -- problem is, IPs are unreliable, can be faked, and
do not provide a strong indicator of identity (while an IP only resolves
to one machine at a time, that machine may be acting as a gateway or
proxy for multiple users connected from other machines -- also, many IPs
are dynamically allocated thanks to ISPs).

Another method is putting the session's ID in the URLs you display to
your users. This creates a lot of problems, though: the session is only
maintained as long as the user uses exactly the URLs you provide (they
won't stay logged in, for example, if they bookmark a plain URL without
the session ID) and it may accidentally be shared between different
users by passing the URL verbatim (most users don't know enough about
URLs to clean session IDs out of them before sending them to other
people -- or don't care!).

The fix for this is usually to restrict the session to an IP (which is
why you often see the checkbox "Restrict my session to this IP" in
log-in forms), but that screws you over if your IP may randomly change
between consecutive requests and thus may break the illusion.

The most common and reliable choice is the good old session cookie: a
cookie (a small data string) is sent to the browser, containing just the
session ID (and, sometimes, non-critical data such as accessibility
settings if the website provides them). Because the browser is normally
restricted to a single user, the session ID is stored in a safe place --
except it isn't really because some people use e.g. internet cafés and
such which may not dispose of session data regularly. Also, a user may
access the same site from different devices or places, therefore
hoarding cookies for different sessions creating consistency problems.

Still, cookies are the easiest and most reliable way to store a session
ID and non-critical data. If you couple them with IP restrictions and a
conservative expiry time (i.e. duration of inactivity until the session
becomes invalid or "expired" and all associated variables are wiped) and
provide a fallback mechanism for users who disabled (or can't accept)
cookies, you should have most scenarios covered (although some sites
actually just stick to cookies and provide no fallbacks).

So once you've decided on a mechanism to persist the session ID, let's
see what a session actually is. In most cases you want to use them for a
log-in mechanism: the user enters their username and password,
successfully, and is welcomed by a personal greeting and a new
navigation subtree that was previously unavailable.

In this case it may be tempting to simply store the user's ID and log-in
state in a cookie, but that'd be incredibly silly because the user can
easily edit them if he knows about cookies (even worse things can happen
if you provide useful variables like "is_admin: False"). Instead you
should store those variables in a safe place ("persist" them) like a
database or special session files.

The session ID acts as a key to the session file or database entry, so
you need to make sure it's not easily guessable: many websites use very
long seemingly-randomly generated strings (a hash of the user's IP and
the millisecond time of the session's creation may yield good results).

Also, if you want to persist something, make sure it's easily
persistable. A string variable is child's play, an open file on the
other hand may cause locking problems and if you deal with large volumes
of data (e.g. binary file uploads kept in memory) you may quickly run
out of space.

If you don't want to have to deal with all of these considerations and
instead prefer something shrinkwrapped and ready for use, Google is your
friend. Depending on what you use there are plenty of CGI-compatible
packages and WSGI frameworks to choose from.


Cheers,

Alan Plum