[Tutor] mod_python authentication

[aivars]

Alan,
I am very impressed! This one goes to my knowledge base.
Thanks a lot.

2009/12/7 Alan Plum <alan.plum at uni-koeln.de>:
> 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
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>