Re: [auth-roles] Design of x-RoleAuthorizationStartegy
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [auth-roles] Design of x-RoleAuthorizationStartegy
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
@AuthorizeActions(actions = {
@AuthorizeAction(action = Action.RENDER, roles = { "entity.create" }),
@AuthorizeAction(action = Action.RENDER, roles = { "document.fillout" })
})
private static class NewDocumentForNewEntityLink extends
BookmarkablePageLink {
public NewDocumentForNewEntityLink(String id, Class
pageClass) {
super(id, pageClass);
}
}
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
protected boolean isActionAuthorized(final Class componentClass, final
Action action)
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
[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
@AuthorizeActions(actions = {
@AuthorizeAction(action = Action.RENDER, roles = { "entity.create" }),
@AuthorizeAction(action = Action.RENDER, roles = { "document.fillout" })
})
private static class NewDocumentForNewEntityLink extends
BookmarkablePageLink {
public NewDocumentForNewEntityLink(String id, Class
pageClass) {
super(id, pageClass);
}
}
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
protected boolean isActionAuthorized(final Class componentClass, final
Action action)
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
