RE: Guards and authentication mechanisms

: mardi 10 juin 2008 10:45 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi, Perhaps this can help, I've made a (long) list of authentication mechanisms (about as many as I could find and I've tried most): http://blog.distributedmatter.net/post/2008/06/09/HTTP

Re: Guards and authentication mechanisms

Hello, Tim Peierls wrote: On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Josh Bloch has a nice presentation of the tradeoffs in Effective Java, 2nd edition, Item 71. I'll try to summarize briefly. First, and most important, don't use

Re: Guards and authentication mechanisms

authentication http://restlet.tigris.org/issues/show_bug.cgi?id=444 Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : dimanche 1 juin 2008 23:50 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication

Re: Guards and authentication mechanisms

On Tue, Jun 10, 2008 at 4:37 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Thank you for all these details. I was a bit confused, because in Java Concurrency in Practice, you don't seem very fond of the double-check idiom (even when volatile is used). Yeah ... sorry about the confusion. *Java

Re: Guards and authentication mechanisms

Hi Jerome, Jerome Louvel wrote: Hi Bruno, Thanks for the patch! A slightly modified version has been checked in SVN trunk: - better concurrency support - no more addChallengeRequest() method - use getChallengeRequests().add(..) instead) Let me know if I broke anything :-) Thanks,

Re: Guards and authentication mechanisms

On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: What I'm less clear about is the benefits of the double-check locking (DLC) pattern. I think the intent behind this pattern was to improve performance, but was in fact broken until the Java 5 memory model (and the use of

Re: Guards and authentication mechanisms

Hi Jerome, Jerome Louvel wrote: Hi Bruno, I'm not sure we want to add such a feature in an official build. Fair enough. Also, if you can come up with a patch that would add a getChallengeRequests():ListChallengeRequest method on Response and deprecate the current challengeRequest

Re: Guards and authentication mechanisms

I tried it. I like it. - R I've just submitted a patch to http://restlet.tigris.org/issues/show_bug.cgi?id=457 Basically, setChallengeRequest is deprecated (and uses the first entry in the list) and replaced with addChallengeRequest and setChallengeRequests; getChallengeRequest is also

RE: Guards and authentication mechanisms

de Bruno Harbulot Envoyé : dimanche 1 juin 2008 23:50 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi all, Jerome Louvel wrote: Hi all, Thanks Bruno for the nice synthesis, that definitely helps moving forward. I have entered a new RFE to consolidate your

Re: Guards and authentication mechanisms

Hi Jerome, One think that could help in the short term for experimenting would be to be able to override the standard HTTP headers. I'm thinking of HttpConstants.HEADER_WWW_AUTHENTICATE to be specific, which HttpConverter.addAdditionalHeaders(...) makes impossible to override. It's therefore

Re: Guards and authentication mechanisms

Hi all, Jerome Louvel wrote: Hi all, Thanks Bruno for the nice synthesis, that definitely helps moving forward. I have entered a new RFE to consolidate your comments and other ones from Stephan: Refactor authentication and authorization http://restlet.tigris.org/issues/show_bug.cgi?id=505

Re: Guards and authentication mechanisms

Hi Bruno, This general idea is good. I have one small objection, though: HTTP allows multiple challenges per 401 response. This means you might want to have a guard with parallel authentication checks. For this reason, I don't think that subclassing Guard per authentication scheme