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
BookmarkablePageLinkVoid {
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
