|
Graham Dumpleton
grahamd at dscpl.com.au
Sat May 20 01:40:01 EDT 2006
On 20/05/2006, at 5:49 AM, Deron Meranda wrote: > On 5/19/06, Geoff Skerrett <geoff at teammsa.com> wrote: >> I am hoping someone can get me back on track and point me in thr >> right >> direction. >> >> I want to create a process where if the user requests a page they >> are not >> authorized for then; >> 1) a custom logon form is displayed >> 2) the users submits and it is processed verifying against a >> database if the >> user is valid >> 3) as part of the processing a session is created >> 4) the session stores the some data (userid, name, lastip, etc) >> 5) when complete the system redirects the user to the original >> page (ie the >> referrer for the login) >> >> I have a test case working and using the util.redirect function. >> Everything >> works fine, but the referred page is processed, it gets a new >> session so the >> variables I have stored during the login page process aren't >> available to >> the refered page. >> >> What am I missing? What is the best strategy for storing the session >> variables and dealing with this type of process ? > > First of all, be cautious using redirection for that purpose. Proxy > servers, caching, and the like may decide to just cache the > redirects too. And then you'd have cross-user contamination. The HTTP specification actually says for 307 (Temporary Redirection), which is what one would want to use: The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. In other words, any cache should by default not cache such a response. In order for it to be cached, it would require the handler to have explicitly set appropriate Cache-Control and/or Expires headers to tell it to cache it. So, as far as the response redirecting a request to a login page is concerned, that shouldn't be a problem in respect of any caching mechanism. Where caching is more of an issue is where the login page presents the form and does a request against some other URL to perform the authentication. If this is a POST, then it should be okay as a cache shouldn't remember POST requests. If someone wanted to mimic the POST and used a GET, supplying the form parameters in the URL as part of the query string, then a cache may remember the result of the authentication request if the handler for it didn't explicitly prohibit caching. Thus, always a good idea for the handler in this case to explicitly prohibit caching of the response. But then, the handler doing the authentication should be returning yet another redirect under normal circumstances to get back to the original page, thus shouldn't be cached after all as per specification for 307 responses. Still good idea to explicitly deny caching, and may be even better for the login handler to only work with POST requests and disallow GET requests. Same for any logout handler. All in all, it can be a bit tricky. Since there has been a couple of queries about session based form login lately, I'll try and post some code of my own that I was playing with. The code though only works with mod_python 3.3 development version, but still may be good for a laugh, ... I mean, may be useful for ideas. The code may well be adapted back to mod_python 3.2.8, but don't have time right now to do that. PS. This is my understanding of things. I could also be wrong. ;-) Graham
|