In answer to the criticisms of HTTP authentication: 1. The generalilzations above about user experience don't click with my experience with users. No one ever reported a broken application on seeing the login dialog. THey really don't care if it's modal, if the background is grey, or any of that stuff that seems to drive developers to reinvent the authentication wheel in cookie-based sessions.
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. It's about not reinventing a stack that's already there and functioning. A decade ago HTTP auth was not well implemented across browsers, but that was a decade ago. 3. Digest Authentication does not send plain text, and is as easy to setup as Basic. The last paragraph, Reinier, the one that starts "There really is no problem here...", I'm not getting your meaning. HTTP Auth is just another session that the developer doesn't have to program. 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. 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. But as a real security feature, it doesn't get much use. If a user has to leave her work area and is concerned about someone gaining unauthorized access, she is more likely to "CTL-ALT- DEL,k" (which locks the entire computer) than to start logging out of individual applications. It's easy to implement logout properly in IE, harder with other browsers because they don't support a "clear identity cache" function, but still possible. In fact, I wonder why it is that the other browsers are not better in this respect. Best, Walden On Nov 19, 1:40 pm, Sumit Chandel <[EMAIL PROTECTED]> wrote: > Hello everyone, > > Just a note that I've removed a couple of posts from this thread due > to inappropriate comments. This also seems like a good time to remind > everyone that we're here to collaborate and help each other, not to > curse or antagonize anyone. > > One of the posts did contain some useful content aside from the > inappropriate bits, which I've posted below to keep the value of the > post on this thread. > > Thanks, > -Sumit Chandel > > ---- Pasted from previous post --- > > HTTPAuthentication? Don't make me laugh - it's ridiculous design, and > more importantly, users don't get it. at all. They think your app is > broken and try to browse away (only they can't, thatauthentication > dialog box is modal). There's also no better security there than what > you can do with cookies, as it boils down to sending the username and > password in plain text to the server. I know, I know, its base64 > encoded so it doesn't look like it on first glance, but -any- sniffer > - > anywhere- can see that its a Authorization header and de-base64 it. > It's the same thing from a security perspective. > > There really is no problem here. If your developer can serve the > content without knowing the user's session information (which > presupposes that the session ID was checked and validated in the first > place), then its rather unlikely to be relevant,security wise. In > corporate settings there are some exceptions (downloading static > files / global uncustomized information which is still not meant for > outside eyes), but not too many. > > On Nov 19, 5:54 am, "olivier nouguier" <[EMAIL PROTECTED]> > wrote: > > > > > Walden, > > > See below, please. > > > On Wed, Nov 19, 2008 at 2:29 PM, walden <[EMAIL PROTECTED]> wrote: > > > > Olivier, > > > > I'm still a little perplexed, see below. > > > >> >> * session expiration, because the GWT RPC will fail soon (401). > > >> >> * forbiden because the GWT RPC will fail soon (403). > > > >> When session is expired, the RPC will fail soon with a 401 (Auth > > >> required status), before GWT 1.5 it was not (easily ) possible to > > >> detect such failure. But session expiration is not an issue forHTTP > > >> basic.>> * activation of widget when authority is granted. > > > > Originally, I thought your points were againstHTTPauth, but now it > > > looks like they were for it? > > > I'm not talking ofHTTPBasic Scheme where AFAIK there is no > > expiration. I'm talking of Session Base mecanism like Acegi or Form > > Basedauthentication. > > > What I was (trying) to explain is that when relying on a previous > >authentication, then the GWT application is in fact unaware of being > > under a restricted access. That might be a good (as it simple). But > > when an error (security errorsAuthRequired (401) when session has > > expired , a forbidden access (403)) occurs on a GWT-RPC call the GWT > > application has to handle this error (much simpler under GWT >= 1.5). > > > So the GWT application has to handle some security concern (Auth > > required && Forbidden). > > > >> About widget activation && authorization, I my proposal the widget are > > >> aware of theauthenticationevents so they can activate/desactivate > > >> when login/logout occurs. > > > > This doesn't come up for me. I secure my site in such a way that you > > > don't get any widgets until you're authenticated and authorized. I > > > thought you were referring to a more fine grained authorization scheme > > > where certain widgets appear only for certain users. > > > I do ! Some GWT element may be notified for theauthenticationevent > > (granted authorities) and then they can do what they want ... > > > >That sort of > > > entitlement management goes beyond authorization, and the point I was > > > making was that it seems somewhat orthogonal to what protocol you use > > > forauth. > > Definitively ! > > > > Walden > > > Regards > > Olivier.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
