Hello everyone, I think all arguments that can be made on this thread have been made. Let's keep it friendly. I'm locking this thread; please take the time you would have spent replying and spend it on thinking about how much better this forum would be if we kept it positive and focused on the technology.
Cheers, -Sumit Chandel On Nov 20, 1:04 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > walden, please, pretty pretty please, stop confusing GWT users with > your very bad advice. You just restated your earlier arguments without > taking into consideration anything I wrote. Sticking your fingers in > your ears and singing loudly doesn't really work, and I request the > common courtesy that you stop doing that. Thanks. > > Just in case you are clueless to the ways of HTTP standardization, > I'll get this out the way up front: > > "RFC" Stands for Request for Comments, and a large stack of RFCs form > the standards of the internet. This includes HTTP, which is where HTTP > Basic Authentication is defined. Thus, anytime I say 'RFC', you can > replace that with 'the official standard', and it'll be semantically > correct, even though technically, HTTP does not really have a > universally recognized official spec that is called 'the official > spec'. The RFC is as close as you can get. And now, with no further > ado... replies inline. > > On Nov 20, 3:40 pm, walden <[EMAIL PROTECTED]> wrote: > > > In answer to the criticisms of HTTP authentication: > > > 1. The generalilzations above about user experience don't click with > > my experience with users. > > My experience is different. Perhaps more pointedly, name me 1 public > web app that uses HTTP-Basic. > > When experiences conflict, go with what is most common. > > > 2. It's not that HTTP Auth is better than what you can build with > > cookies. I don't know if it is or it isn't. > > I do know. It's worse. And I've explained, in lengthy detail, why HTTP > Auth sucks. I even mentioned that the authors of HTTP Auth (or as > close as you can get - the RFC) strongly suggest you don't actually > use it for authentication, just for identification. Please reread the > thread for the complete treatment about why HTTP Auth is technically > pretty bad. > > > It's about not > > reinventing a stack that's already there and functioning. > > There is no stack. Specifically, HTTP Auth doesn't let you keep your > login across browser restarts, which is something that every single > webapp that has any sort of success actually has, and is something > users obviously want. Even the security sensitive apps do this, just > so they can at least customize the things you see pre-login with non- > sensitive personal data, such as your username. (why the heck are you > using the security-broken HTTP Auth, again, according to the RFC > itself, if security is important enough to force re-logging in that > often anyway?) > > Thus, you have to 'implement' a session ID anyway. You're still not > spilling the beans on how you log out with HTTP Auth, which is quite > interesting, because the RFC specifically says that you CANNOT log > out. Going with what another poster kindly explained, you're actually > invalidating the session, which means you've 'reinvented the wheel' > according to your own definition just the same. > > I also find it insulting to say that the standard session management- > via-cookies principle is 'reinventing the wheel' somehow. If every > webapp this decade has been using it, then calling that 'reinventing > the wheel' is frankly facetious. You can't toss out terms with a > negative connotation when they don't apply. > > >A decade > > ago HTTP auth was not well implemented across browsers, but that was a > > decade ago. > > Actually, absolutely nothing changed in the way browsers implement > HTTP Basic Auth. The reason nothing changed is twofold: > > 1) HTTP Basic Auth was so extremely broken that it isn't fixable. > There' a new standard (HTTP Digest Auth), but it sees absolutely zero > use. I have no idea which browsers, if any even implement it. It > doesn't matter, because.... > > 2) Everyone and their uncle was using forms instead of http basic > auth to relay user/pass to the server, so by the time either the > slowish RFC process, or the even slower browser evolution process in > the 6 years after IE6 was released, caught up with the notion that > HTTP Basic Auth totally sucked - it was no longer relevant. > > > > > 3. Digest Authentication does not send plain text, and is as easy to > > setup as Basic. > > it isn't even remotely as simple to set up. No one uses this. Browser > support dubious. > > > > > The last paragraph, Reinier, the one that starts "There really is no > > problem here...", I'm not getting your meaning. > > That wasn't in reply to you, that was in reply to the original post. > He was worried that a servlet wouldn't check the authentication and in > that way leak data. I merely mentioned that this can't usually even > happen, because there is no data to leak without first knowing who > requested the information. And the only way to do that is to check the > session data, which implies the session data was deemed valid, > security-wise. If his setup does not work that way, he's doing > something very weird, and he's doing it very wrong. > > I also mentioned there are some exceptions to the rule - for example, > non-personalized data which is nevertheless only meant for people with > login credentials. This only applies if the app isn't a public webapp > that anyone can create an account for, obviously. > > > HTTP Auth is just > > another session that the developer doesn't have to program. > > HTTP Auth isn't a session at all. Sessions are server-side constructs. > HTTP Auth is a client side thing. Your argument appears to be stuck in > a Salvador Dali painting. > > If you meant that HTTP Auth is a session *TRACKING* system that a > developer doesn't have to program, then you're right. Fortunately, > cookies are also a tracking system that a developer doesn't have to > program. It's also safer, security-wise. It's also far more common. > It's also far more flexible. It also survives shutting down the > browser. You can also log those out. > > > But it's > > also a session that's maintained on the client, so it's consistent > > with the "stateless server" constraint of REST, and general network > > application scaleability. > > There you go throwing about negative words that have absolutely no > relationship to the topic at hand again. Please don't do that. > > Re-checking username/password for every request is as hard on the > database (and therefore just as hard to scale), or -harder- than > session IDs. > > > > > My application has a "logout" feature. It's a nice-to-have, > > especially for me if I have to troubleshoot the appliation from a > > user's terminal. > > It's called 'public terminal'. Like, say, an internet café. Or a > friends computer. You could lock those, perhaps, until you return, but > someone is bound to get mad at you. > > > In fact, I wonder why > > it is that the other browsers are not better in this respect. > > Because nobody uses HTTP Auth. It has been effectively abandoned by > the developers first, and then both the RFC community and the browsers > followed suit. If you listen to the browser wars, absolutely nobody > gives a crap about HTTP Auth. Because nobody uses it. Simple, isn't > it? General rule about browsers: Don't use what nobody is using if > there's an alternative that works just as well or better using systems > that everybody uses. > > From here on out I'll only rebut new facts. Please don't bother > reposting the same flawed arguments a third time. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
