RE: Guards and authentication mechanisms

lot Envoyé : 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/

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.

Re: Guards and authentication mechanisms

;Support SPNEGO 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:

Re: Guards and authentication mechanisms

Hello, Tim Peierls wrote: On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot <[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

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

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

Heittman [mailto:[EMAIL PROTECTED] Envoyé : mercredi 4 juin 2008 05:47 À : discuss@restlet.tigris.org Objet : 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 Basi

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 a

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():List" method on Response and deprecate the current "challengeRequest" property, that could

RE: Guards and authentication mechanisms

Bruno Harbulot Envoyé : lundi 2 juin 2008 19:31 À : discuss@restlet.tigris.org Objet : 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 HttpConst

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

ROTECTED] De la part 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 enter

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 Rhett, Yes, you are right. The Guard class should allow for multiple challenge schemes (although it would be more realistic to try them one at a time). There could be a list of challenge scheme instances in the Guard. Each of these challenge scheme instances could be associated with an aut

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 (ba

RE: Guards and authentication mechanisms

cussion here and/or via comments to the RFE. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 29 mai 2008 10:22 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi Bruno, The idea is *very* go

Re: Guards and authentication mechanisms

Hi Bruno, The idea is *very* good. I've also thoughts in this direction, but your proposal is more complete than my ideas was. I've also proposed some month ago to switch the Guard to an abstract class which do the HTTP things, and ubclasses for the check of the secrets. Jerome said, if we chan

Guards and authentication mechanisms

Hi all, Following the discussion on the authentication scheme a few days ago, I've been looking at - "Access to connector authentication" http://restlet.tigris.org/issues/show_bug.cgi?id=503 - "Add notion of realm" http://restlet.tigris.org/issues/show_bug.cgi?id=504 - "Add support for