You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Per Newgro <pe...@gmx.ch> on 2013/10/11 12:50:55 UTC
[auth-roles] Design of x-RoleAuthorizationStartegy
Hi,
we had a simple usecase today leading us to confusion on AnnotationsRoleAuthorizationStrategy (ARAS).
We tried to protect a button by using two different permissions. So we had to use AuthorizeActions.
We did it this way
<code>
@AuthorizeActions(actions = {
@AuthorizeAction(action = Action.RENDER, roles = { "entity.create" }),
@AuthorizeAction(action = Action.RENDER, roles = { "document.fillout" })
})
private static class NewDocumentForNewEntityLink extends BookmarkablePageLink<Void> {
public NewDocumentForNewEntityLink(String id, Class<? extends WebPage> pageClass) {
super(id, pageClass);
}
}
</code>
Ok we don't use the roles as their name would suggest it. We use it more as permissions.
But that is not relevant here (IMHO).
In one of our test cases we've found out that only one permission is required to get
that link displayed. But we would like to include all permissions. And so the story begins.
The first maybe intuitive way to customize the annotation handling was to implement our own
IRoleCheckingStrategy. But the first issue we had was the name of the interface method we
had to implement (hasAny(Roles)) which suggests an or condition.
=> Isn't this to thight for an interface? Shouldn't the name be accepts(Roles)?
With further checks we saw no chance to get an "and condition check" done by the current
ARAS implementation. The only possibility was to overwrite
<code>
protected boolean isActionAuthorized(final Class<?> componentClass, final Action action)
</code>
and do it by our own. Another problem could be the handling of the deny permissions.
If we would like to use an "or condition check" here this wouldn't be possible because
accept and deny checks use the same method (hasAny(Roles)).
=> Shouldn't the role check a task of the RoleCheckingStartegy? Shouldn't it be a more
configurable implementation?
I hope my problem got clear. I don't want to snub anybody. The intention of this is
only to have a discussion here before we create a ticket with a patch.
What do you think?
Thanks for your opinion
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [auth-roles] Design of x-RoleAuthorizationStartegy
Posted by Per Newgro <pe...@gmx.ch>.
Thanks for your reply Sven. That makes sense. Ok then we can definitly
build our own solution.
Cheers
Per
Am 15.10.2013 13:48, schrieb Sven Meier:
> Hi,
>
> wicket-auth-roles is 'mostly a technology demonstration':
>
> https://wicket.apache.org/learn/projects/authroles.html
>
> It's a very simple starting point, thus it cannot serve all needs.
> Please use it as an inspiration for your own solution.
>
> Regards
> Sven
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [auth-roles] Design of x-RoleAuthorizationStartegy
Posted by Sven Meier <sv...@meiers.net>.
Hi,
wicket-auth-roles is 'mostly a technology demonstration':
https://wicket.apache.org/learn/projects/authroles.html
It's a very simple starting point, thus it cannot serve all needs.
Please use it as an inspiration for your own solution.
Regards
Sven
On 10/11/2013 12:50 PM, Per Newgro wrote:
> Hi,
>
> we had a simple usecase today leading us to confusion on AnnotationsRoleAuthorizationStrategy (ARAS).
>
> We tried to protect a button by using two different permissions. So we had to use AuthorizeActions.
> We did it this way
> <code>
> @AuthorizeActions(actions = {
> @AuthorizeAction(action = Action.RENDER, roles = { "entity.create" }),
> @AuthorizeAction(action = Action.RENDER, roles = { "document.fillout" })
> })
> private static class NewDocumentForNewEntityLink extends BookmarkablePageLink<Void> {
> public NewDocumentForNewEntityLink(String id, Class<? extends WebPage> pageClass) {
> super(id, pageClass);
> }
> }
> </code>
>
> Ok we don't use the roles as their name would suggest it. We use it more as permissions.
> But that is not relevant here (IMHO).
>
> In one of our test cases we've found out that only one permission is required to get
> that link displayed. But we would like to include all permissions. And so the story begins.
>
> The first maybe intuitive way to customize the annotation handling was to implement our own
> IRoleCheckingStrategy. But the first issue we had was the name of the interface method we
> had to implement (hasAny(Roles)) which suggests an or condition.
>
> => Isn't this to thight for an interface? Shouldn't the name be accepts(Roles)?
>
> With further checks we saw no chance to get an "and condition check" done by the current
> ARAS implementation. The only possibility was to overwrite
> <code>
> protected boolean isActionAuthorized(final Class<?> componentClass, final Action action)
> </code>
> and do it by our own. Another problem could be the handling of the deny permissions.
> If we would like to use an "or condition check" here this wouldn't be possible because
> accept and deny checks use the same method (hasAny(Roles)).
>
> => Shouldn't the role check a task of the RoleCheckingStartegy? Shouldn't it be a more
> configurable implementation?
>
> I hope my problem got clear. I don't want to snub anybody. The intention of this is
> only to have a discussion here before we create a ticket with a patch.
>
> What do you think?
>
> Thanks for your opinion
> Per
>
> ---------------------------------------------------------------------
> 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