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
