RE: Guard suggestion
Hi all, I agree that having a 'guest' (or better 'anonymous') principal would be useful as default access rights/permissions could be assigned to it. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Stephan Koops [mailto:[EMAIL PROTECTED] Envoyé : jeudi 27 novembre 2008 16:31 À : discuss@restlet.tigris.org Objet : Re: Guard suggestion Hi Bruno, while now thinking about it: If the role checking logic is accesible via the principal, than a guest principal is useful. best regards Stephan Hi Stephan, Stephan Koops wrote: Hi Bruno, I think, in the context of wider refactorisation of authentication and authorisation, that authentication should provided a Principal when a client has been authenticated (and perhaps a default guest principal when no one has, like jGuard does, but that's a different matter). why not use null as guest principal? What is the advantage of an object for it? I don't think it's very significant. I was simply referring to what jGuard does: http://jguard.xwiki.com/xwiki/bin/view/Doc/Faq#HAccessFilterautomaticallytriestologmeinas27guest27Whyshouldtherebea22default22userin jGuard3FIsn27tthatasecurityissue3F Best wishes, Bruno. _ Sensationsangebot nur bis 30.11: WEB.DE FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a
Re: Guard suggestion
Hi Bruno, I think, in the context of wider refactorisation of authentication and authorisation, that authentication should provided a Principal when a client has been authenticated (and perhaps a default guest principal when no one has, like jGuard does, but that's a different matter). why not use null as guest principal? What is the advantage of an object for it? best regards Stephan
Re: Guard suggestion
Hi Stephan, Stephan Koops wrote: Hi Bruno, I think, in the context of wider refactorisation of authentication and authorisation, that authentication should provided a Principal when a client has been authenticated (and perhaps a default guest principal when no one has, like jGuard does, but that's a different matter). why not use null as guest principal? What is the advantage of an object for it? I don't think it's very significant. I was simply referring to what jGuard does: http://jguard.xwiki.com/xwiki/bin/view/Doc/Faq#HAccessFilterautomaticallytriestologmeinas27guest27Whyshouldtherebea22default22userinjGuard3FIsn27tthatasecurityissue3F Best wishes, Bruno.
Re: Guard suggestion
Hi Bruno, while now thinking about it: If the role checking logic is accesible via the principal, than a guest principal is useful. best regards Stephan Hi Stephan, Stephan Koops wrote: Hi Bruno, I think, in the context of wider refactorisation of authentication and authorisation, that authentication should provided a Principal when a client has been authenticated (and perhaps a default guest principal when no one has, like jGuard does, but that's a different matter). why not use null as guest principal? What is the advantage of an object for it? I don't think it's very significant. I was simply referring to what jGuard does: http://jguard.xwiki.com/xwiki/bin/view/Doc/Faq#HAccessFilterautomaticallytriestologmeinas27guest27Whyshouldtherebea22default22userinjGuard3FIsn27tthatasecurityissue3F Best wishes, Bruno. _ Sensationsangebot nur bis 30.11: WEB.DE FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a
RE: Guard suggestion
Hi Rémi,
Thanks, I've added your use case as a comment in the RFE.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com/
http://www.noelios.com
_
De : Rémi Dewitte [mailto:[EMAIL PROTECTED]
Envoyé : lundi 24 novembre 2008 14:35
À : discuss@restlet.tigris.org
Objet : Re: Guard suggestion
Hello,
For example you have an application where you want to display various
informations with different levels of information.
There is an interface to manage rules for authorizations. One of the rule could
be to authorize all users to access the resource or only authorized or only
specific users, etc.
It is up to the authorize method to trigger 401 responses...
Rémi
On Tue, Nov 18, 2008 at 09:34, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Rémi,
I have added your suggestion to the RFE mentioned by Stephan:
Refactor authentication and authorization
http://restlet.tigris.org/issues/show_bug.cgi?id=505
Do you have examples in mind where it would be nice to authorize
unauthenticated client requests ?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com/
http://www.noelios.com
_
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Rémi Dewitte
Envoyé : vendredi 14 novembre 2008 23:27
À : discuss@restlet.tigris.org
Objet : Re: Guard suggestion
It would also let the autorize() method to decide whether AuthenticationMissing
forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not required? I think
this is a good ideas. For browser applications I don't now, if browsers could
work with this.
The authentication should be reworked in the near future (I don't know te
current timetable for this). If your proposal is missing then, throw it into
the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Re: Guard suggestion
Hi Jerome and Remi,
I think, in the context of wider refactorisation of authentication and
authorisation, that authentication should provided a Principal when a
client has been authenticated (and perhaps a default guest principal
when no one has, like jGuard does, but that's a different matter).
Then, when authorise should take that Principal and choose
whether-or-not to authorise depending on that value. The case you
describe seems to correspond to a null/guest value, which is fine.
Best wishes,
Bruno.
Jerome Louvel wrote:
Hi Rémi,
Thanks, I've added your use case as a comment in the RFE.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com/
*De :* Rémi Dewitte [mailto:[EMAIL PROTECTED]
*Envoyé :* lundi 24 novembre 2008 14:35
*À :* discuss@restlet.tigris.org
*Objet :* Re: Guard suggestion
Hello,
For example you have an application where you want to display various
informations with different levels of information.
There is an interface to manage rules for authorizations. One of the
rule could be to authorize all users to access the resource or only
authorized or only specific users, etc.
It is up to the authorize method to trigger 401 responses...
Rémi
On Tue, Nov 18, 2008 at 09:34, Jerome Louvel [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Rémi,
I have added your suggestion to the RFE mentioned by Stephan:
Refactor authentication and authorization
http://restlet.tigris.org/issues/show_bug.cgi?id=505
Do you have examples in mind where it would be nice to authorize
unauthenticated client requests ?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
http://www.restlet.org/
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com/
*De :* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *De la
part de* Rémi Dewitte
*Envoyé :* vendredi 14 novembre 2008 23:27
*À :* discuss@restlet.tigris.org mailto:discuss@restlet.tigris.org
*Objet :* Re: Guard suggestion
It would also let the autorize() method to decide whether
AuthenticationMissing forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not
required? I think this is a good ideas. For browser applications
I don't now, if browsers could work with this.
The authentication should be reworked in the near future (I
don't know te current timetable for this). If your proposal is
missing then, throw it into the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even
if no authentication is present.
Why not adding an authorizeMissing attribute and change
handling of AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Re: Guard suggestion
Hello,
For example you have an application where you want to display various
informations with different levels of information.
There is an interface to manage rules for authorizations. One of the rule
could be to authorize all users to access the resource or only authorized or
only specific users, etc.
It is up to the authorize method to trigger 401 responses...
Rémi
On Tue, Nov 18, 2008 at 09:34, Jerome Louvel [EMAIL PROTECTED]wrote:
Hi Rémi,
I have added your suggestion to the RFE mentioned by Stephan:
Refactor authentication and authorization
http://restlet.tigris.org/issues/show_bug.cgi?id=505
Do you have examples in mind where it would be nice to authorize
unauthenticated client requests ?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
*De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de
* Rémi Dewitte
*Envoyé :* vendredi 14 novembre 2008 23:27
*À :* discuss@restlet.tigris.org
*Objet :* Re: Guard suggestion
It would also let the autorize() method to decide whether
AuthenticationMissing forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not required? I
think this is a good ideas. For browser applications I don't now, if
browsers could work with this.
The authentication should be reworked in the near future (I don't know te
current timetable for this). If your proposal is missing then, throw it into
the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
RE: Guard suggestion
Hi Rémi,
I have added your suggestion to the RFE mentioned by Stephan:
Refactor authentication and authorization
http://restlet.tigris.org/issues/show_bug.cgi?id=505
Do you have examples in mind where it would be nice to authorize
unauthenticated client requests ?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com/
http://www.noelios.com
_
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Rémi Dewitte
Envoyé : vendredi 14 novembre 2008 23:27
À : discuss@restlet.tigris.org
Objet : Re: Guard suggestion
It would also let the autorize() method to decide whether AuthenticationMissing
forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not required? I think
this is a good ideas. For browser applications I don't now, if browsers could
work with this.
The authentication should be reworked in the near future (I don't know te
current timetable for this). If your proposal is missing then, throw it into
the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Guard suggestion
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Guard suggestion
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Re: Guard suggestion
Hi Rémi,
You mean, that a client can authorize himself, but it is not required? I
think this is a good ideas. For browser applications I don't now, if
browsers could work with this.
The authentication should be reworked in the near future (I don't know
te current timetable for this). If your proposal is missing then, throw
it into the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Re: Guard suggestion
It would also let the autorize() method to decide whether
AuthenticationMissing forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not required? I
think this is a good ideas. For browser applications I don't now, if
browsers could work with this.
The authentication should be reworked in the near future (I don't know te
current timetable for this). If your proposal is missing then, throw it into
the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even if no
authentication is present.
Why not adding an authorizeMissing attribute and change handling of
AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
