walden,Stop being such a cry baby. So its okay for you to be snide with other users but you don't like it when you get the treatment. Reinier is also rather brash in his response to users, but the difference is he can back his stuff up so I have nothing to say to him.
Stop complaining to the moderators and instead be more mindful in your response to users. If you don't have anything useful to add, don't feel compelled to reply. This was precisely the case in this particular thread. Ivan On Wed, Nov 19, 2008 at 8:19 AM, walden <[EMAIL PROTECTED]> wrote: > > Reinier, > > I think you need a different outlet for your anger. I don't > appreciate you calling me a jackass, especially in a public forum such > as this. I'm going to ask the moderator to remove your post. > > If you want to have the discussion, please take the prism glasses off, > try to read what I wrote, and stick to the technical issues with > specific examples and counterexamples, if you have them. Trying to > summarize the experience and sentiment of others as if from authority > is also not helpful. > > Walden > > > > > On Nov 18, 2:49 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > HTTP Authentication? 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, that authentication > > 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. > > > > Also, walden: You're a bit of a jackass. If someone makes a comment > > that asserts a widely perceived truth (you can't log out with HTTP > > basic authentication), don't answer with "But I can! Ha! Neener neener > > neener!". Explain how instead of being so dense. Thanks, on behalf of > > everyone else. > > > > On Nov 18, 7:29 pm, walden <[EMAIL PROTECTED]> wrote: > > > > > > > > > Olivier, > > > > > > * session expiration, because the GWT RPC will fail soon (401). > > > > * forbiden because the GWT RPC will fail soon (403). > > > > * activation of widget when authority is granted. > > > > > I'm scratching my head wondering what those mean. In my app, RPC's > > > are secure and they don't fail. As for widget activation, you're > > > talking authorization, and I don't see any difference among the > > > proposals on that. > > > > > > * logout (not possible with HTTP Basic). > > > > > And yet I have it. Go figure. > > > > > Walden- 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
