You are entirely right: I stand corrected. What an oddity that they make no mention of this in RFC 2616... Well, that's that, then. No more pesky inline login forms for me!
Thanks :) yejun wrote: > 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 -~----------~----~----~----~------~----~------~--~---
