Alan, I am very impressed! This one goes to my knowledge base. Thanks a lot.
2009/12/7 Alan Plum <alan.p...@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 - tu...@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor