You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Boris Goldowsky <bg...@cast.org> on 2013/12/20 13:53:40 UTC
Question on role-based authorization
I’m trying to use wicket-auth-roles (in Wicket 1.5.9) to make a component that is enabled only for logged-in users. In my case if you’re not logged in, you have only a role called GUEST. If you are logged in you have a role called STUDENT (and also GUEST, since everything guests can do, students can do too).
I tried this annotation at the top of the class:
@AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={“GUEST"}, roles={"STUDENT"})})
However, everyone is denied (since everyone has the GUEST role).
Then I tried:
@AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={}, roles={"STUDENT"})})
but for some reason AbstractRoleAuthorizationStrategy.hasAny(roles) returns true for the empty list of roles, so everyone is denied again. If I leave out the deny list entirely:
@AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", roles={"STUDENT"})})
it is a null pointer exception.
I know I can write my own strategy or define my own annotation, but it seems like my case is exactly what the roles annotations are supposed to do. So either this a bug in wicket-auth-roles, or else I am doing something wrong. Thoughts?
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question on role-based authorization
Posted by Boris Goldowsky <bg...@cast.org>.
One oddity with AnnotationsRoleAuthorizationStrategy#check() is that specifying deny = {} actually denies everyone (since AbstractRoleAuthorizationStrategy.hasAny(roles) returns true for the empty list of roles). But people might be depending on that behavior, so it would be hard to recommend changing it.
A better case can be made for changing the current behavior when the deny parameter is omitted entirely.
With this annotation:
@AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", roles={"STUDENT"})})
when it gets to this line in AnnotationsRoleAuthorizationStrategy#check():
if (hasAny(new Roles(authorizeActionAnnotation.deny())))
invokes new Roles(""), which results in a set of one role called “”.
This is what causes the null pointer exception, in my own code, since there is no role named “”.
So I can fix the NPE, but how about a patch so that if the deny parameter is omitted, then it skips deny checking and moves right on to the next step of checking the roles parameter? The current behavior of assuming a role named “” for that defaulted case, does not seem like it would be useful for anyone.
Boris
On Dec 20, 2013, at 8:17 AM, Sven Meier <sv...@meiers.net> wrote:
> AnnotationsRoleAuthorizationStrategy#check() looks good to me.
>
> Can you debug what's happening there in your case?
>
> Sven
>
> On 12/20/2013 01:53 PM, Boris Goldowsky wrote:
>> I’m trying to use wicket-auth-roles (in Wicket 1.5.9) to make a component that is enabled only for logged-in users. In my case if you’re not logged in, you have only a role called GUEST. If you are logged in you have a role called STUDENT (and also GUEST, since everything guests can do, students can do too).
>>
>> I tried this annotation at the top of the class:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={“GUEST"}, roles={"STUDENT"})})
>>
>> However, everyone is denied (since everyone has the GUEST role).
>>
>> Then I tried:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={}, roles={"STUDENT"})})
>>
>> but for some reason AbstractRoleAuthorizationStrategy.hasAny(roles) returns true for the empty list of roles, so everyone is denied again. If I leave out the deny list entirely:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", roles={"STUDENT"})})
>>
>> it is a null pointer exception.
>>
>>
>> I know I can write my own strategy or define my own annotation, but it seems like my case is exactly what the roles annotations are supposed to do. So either this a bug in wicket-auth-roles, or else I am doing something wrong. Thoughts?
>>
>> Boris
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question on role-based authorization
Posted by Boris Goldowsky <bg...@cast.org>.
I should have checked JIRA first. It looks like this was fixed, but only for wicket 6, under this issue:
https://issues.apache.org/jira/browse/WICKET-3974
Boris
On Dec 20, 2013, at 8:17 AM, Sven Meier <sv...@meiers.net> wrote:
> AnnotationsRoleAuthorizationStrategy#check() looks good to me.
>
> Can you debug what's happening there in your case?
>
> Sven
>
> On 12/20/2013 01:53 PM, Boris Goldowsky wrote:
>> I’m trying to use wicket-auth-roles (in Wicket 1.5.9) to make a component that is enabled only for logged-in users. In my case if you’re not logged in, you have only a role called GUEST. If you are logged in you have a role called STUDENT (and also GUEST, since everything guests can do, students can do too).
>>
>> I tried this annotation at the top of the class:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={“GUEST"}, roles={"STUDENT"})})
>>
>> However, everyone is denied (since everyone has the GUEST role).
>>
>> Then I tried:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={}, roles={"STUDENT"})})
>>
>> but for some reason AbstractRoleAuthorizationStrategy.hasAny(roles) returns true for the empty list of roles, so everyone is denied again. If I leave out the deny list entirely:
>>
>> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", roles={"STUDENT"})})
>>
>> it is a null pointer exception.
>>
>>
>> I know I can write my own strategy or define my own annotation, but it seems like my case is exactly what the roles annotations are supposed to do. So either this a bug in wicket-auth-roles, or else I am doing something wrong. Thoughts?
>>
>> Boris
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question on role-based authorization
Posted by Sven Meier <sv...@meiers.net>.
AnnotationsRoleAuthorizationStrategy#check() looks good to me.
Can you debug what's happening there in your case?
Sven
On 12/20/2013 01:53 PM, Boris Goldowsky wrote:
> I’m trying to use wicket-auth-roles (in Wicket 1.5.9) to make a component that is enabled only for logged-in users. In my case if you’re not logged in, you have only a role called GUEST. If you are logged in you have a role called STUDENT (and also GUEST, since everything guests can do, students can do too).
>
> I tried this annotation at the top of the class:
>
> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={“GUEST"}, roles={"STUDENT"})})
>
> However, everyone is denied (since everyone has the GUEST role).
>
> Then I tried:
>
> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", deny={}, roles={"STUDENT"})})
>
> but for some reason AbstractRoleAuthorizationStrategy.hasAny(roles) returns true for the empty list of roles, so everyone is denied again. If I leave out the deny list entirely:
>
> @AuthorizeActions(actions = { @AuthorizeAction(action="ENABLE", roles={"STUDENT"})})
>
> it is a null pointer exception.
>
>
> I know I can write my own strategy or define my own annotation, but it seems like my case is exactly what the roles annotations are supposed to do. So either this a bug in wicket-auth-roles, or else I am doing something wrong. Thoughts?
>
> Boris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org