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@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor