>From rfc 2617. http://www.ietf.org/rfc/rfc2617
Digest authentication uses 'stale' to indicate whether client should require user reenter credential information. It seems to me that should mean a message of terminating current session. On Oct 27, 2:44 pm, Hraban Luyat <[EMAIL PROTECTED]> wrote: > Aaron Swartz wrote: > > Here's an excerpt from the book I'm working on about building > > programmable web apps. It almost makes me want to take the sessions > > module out of web.py. What do people think? Here it is: > > > The second major choice [in designing the Web] was that the Web would > > be "stateless". Imagine a network connection as your computer phoning > > up HQ and starting a conversation. In a stateful protocol, these are > > long conversations -- "Hello?" "Hello, welcome to Amazon. This is > > Shirley." "Hi Shirley, how are you doing?" "Oh, fine, how are you?" > > "Oh, great. Just great." "Glad to hear it. What can I do for you?" > > "Well, I was wondering what you had in the Books department." "Hmm, > > let me see. Well, it looks like we have over 15 million books. Could > > you be a bit more specific?" "Well, do you have any by Dostoevsky?" > > (etc.). But the Web is stateless -- each connection begins completely > > anew, with no prior history. > > > This has its upsides. For one thing, if you're in the middle of > > looking for a book on Amazon but right as you're about to find it you > > notice the clock and geebus! it's late, you're about to miss your > > flight! So you slam your laptop shut and toss it in your bag and dash > > to your gate and board the plane and eventually get to your hotel > > entire _days_ later, there's nothing stopping you from reopening your > > laptop in this completely different country and picking up your search > > right where you left off. All the links will still work, after all. A > > stateful conversation, on the other hand, would never survive a > > day-long pause or a change of country. (Similarly, you can send a link > > to your search to a friend across the globe and you both can use it > > without a hitch.) > > > It has benefits for servers too. Instead of having each client tie up > > part of a particular server for as long as their conversation lasts, > > stateless conversations get wrapped up very quickly and can be handled > > by any old server, since they don't need to know any history. > > > Some bad web apps try to avoid the Web's stateless nature. The most > > common way is thru session cookies. Now cookies certainly have their > > uses. Just like when you call your bank on the phone and they ask you > > for your account number so they can pull up your file, cookies can > > allow servers to build pages customized just for you. There's nothing > > wrong with that. > > > (Although you have to wonder whether users might not be better served > > by the more secure Digest authentication features built into HTTP, but > > since just about every application on the Web uses cookies at this > > point, that's probably a lost cause. There's some hope for improvement > > in HTML5 (the next version of HTML) since they're-- oh, wait, they're > > not fixing this. Hmm, well, I'll try suggesting it.[^w]) > > > [^w]:http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/0167... > > > The real problem comes when you use cookies to create sessions. For > > example, imagine if Amazon.com just had one URL: > >http://www.amazon.com/The first time you visited it'd give you the > > front page and a session number (let's say 349382). Then, you'd send > > call back and say "I'm session number 349382 and I want to look at > > books" and it'd send you back the books page. Then you'd say call back > > and say "I'm session number 349382 and I want to search for > > Dostoevsky". And so on. > > > Crazy as it sounds, a lot of sites work this way (and many more used > > to). For many years, the worst offender was probably a toolkit called > > WebObjects, which most famously runs Apple's Web store. But, after > > years and years, it seems WebObjects might have been fixed. Still, new > > frameworks like Arc and Seaside are springing up to take its place. > > All do it for the same basic reason: they're software for building Web > > apps that want to hide the Web from you. They want to make it so that > > you just write some software normally and it magically becomes a web > > app, without you having to do any of the work of thinking up URLs or > > following REST. Well, you may get an application you can use through a > > browser out of it, but you won't get a web app. > > Hi Aaron, > > RFC 2616: HTTP/1.1, Section 15.6: > > > > > 15.6 Authentication Credentials and Idle Clients > > > Existing HTTP clients and user agents typically retain authentication > > information indefinitely. HTTP/1.1. does not provide a method for a > > server to direct clients to discard these cached credentials. This is > > a significant defect that requires further extensions to HTTP. > > Circumstances under which credential caching can interfere with the > > application's security model include but are not limited to: > > > - Clients which have been idle for an extended period following > > which the server might wish to cause the client to reprompt the > > user for credentials. > > > - Applications which include a session termination indication > > (such as a `logout' or `commit' button on a page) after which > > the server side of the application `knows' that there is no > > further reason for the client to retain the credentials. > > > This is currently under separate study. There are a number of work- > > arounds to parts of this problem, and we encourage the use of > > password protection in screen savers, idle time-outs, and other > > methods which mitigate the security problems inherent in this > > problem. In particular, user agents which cache credentials are > > encouraged to provide a readily accessible mechanism for discarding > > cached credentials under user control. > > (Source: <http://www.ietf.org/rfc/rfc2616.txt>) > > That is the reason for HTTP authentication not finding wide deployment. > In my applications, at least. Of course, it doesn't "look pretty", yes, > that's an added problem, but using existing and well-tested mechanisms > like this requires less code and is thus less error-prone. If HTTP/1.1 > provided a logout functionality we'd see a whole lot less SQL injection > attacks in login forms. Simply because they wouldn't exist. > > I will leave your real point ("web applications should be stateless") > untouched, though :). For today. > > Greetings. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to webpy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
