You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2007/09/16 00:00:35 UTC
remove Session#getAuthorizationStrategy?
Hey,
Do we have a very good reason for having getAuthorizationStrategy in
Session? By default, this just does
getApplication().getSecuritySettings().getAuthorizationStrategy();
I'm revising the chapter on authorization currently, and it just looks
yacni to me. In the probably rare case that you want to vary the
strategy by session, you can just do this with the strategy itself.
Is anyone against me removing this method, and change:
addComponentInstantiationListener(new IComponentInstantiationListener() {
public void onInstantiation(final Component component) {
if (!Session.get().getAuthorizationStrategy()
.isInstantiationAuthorized(component.getClass())) {
getSecuritySettings()
.getUnauthorizedComponentInstantiationListener()
.onUnauthorizedInstantiation(component);
}
}
});
to
addComponentInstantiationListener(new IComponentInstantiationListener() {
public void onInstantiation(final Component component) {
if (!getSecuritySettings().getAuthorizationStrategy()
.isInstantiationAuthorized(component.getClass())) {
getSecuritySettings()
.getUnauthorizedComponentInstantiationListener()
.onUnauthorizedInstantiation(component);
}
}
});
?
Eelco
Re: remove Session#getAuthorizationStrategy?
Posted by Eelco Hillenius <ee...@gmail.com>.
> I think this is a good place for chosing AuthenitcationStrategies
> according to e.g. currently logged user/role. Still, if you really
> want to remove this, what about a vote?
Ok. Well if people like you and Maurice disagree that's fine then. We
can leave things like they are now.
Eelco
Re: remove Session#getAuthorizationStrategy?
Posted by Matej Knopp <ma...@gmail.com>.
On 9/16/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 9/15/07, Matej Knopp <ma...@gmail.com> wrote:
> > Dunno. What's wrong with having possibility for authentication
> > strategy per session? I don't like API bloat, but I can imagine a good
> > usecase for this.
>
> If you want a per session strategy, you can still do that, as any
> implementation can just use the session for it, or you can even make a
> factory for it. It is just bloat.
>
> Eelco
>
This
/**
* @return The authorization strategy for this session
*/
public IAuthorizationStrategy getAuthorizationStrategy()
{
return getApplication().getSecuritySettings().getAuthorizationStrategy();
}
really looks more like indirection than a bloat to me. Sure there are
ways around it. You can make your authorization strategy that forwards
from specific AS from session, but why should you do that?
I think this is a good place for chosing AuthenitcationStrategies
according to e.g. currently logged user/role. Still, if you really
want to remove this, what about a vote?
-Matej
Re: remove Session#getAuthorizationStrategy?
Posted by Maurice Marrink <ma...@gmail.com>.
Eelco i am very much against this.
Wasp and Swarm have a session based authorization strategy.
IMO the little bit of extra indirection through the session makes it a
lot easier for people like me to implement a session based strategy.
and it poses really no inconvenience to other users.
Also i ma not convinced that by storing the strategy myself in the
session i will have solved everything as there will still be placed i
can not override where the application is used to get the strategy.
Yes i know i can overwrite getSecuritySettings from the application
but this will basically mean that users have to extend my application
rather than implementing my application interface. Or they have to get
knee deep into wicket internal details.
Maurice
On 9/16/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 9/15/07, Matej Knopp <ma...@gmail.com> wrote:
> > Dunno. What's wrong with having possibility for authentication
> > strategy per session? I don't like API bloat, but I can imagine a good
> > usecase for this.
>
> If you want a per session strategy, you can still do that, as any
> implementation can just use the session for it, or you can even make a
> factory for it. It is just bloat.
>
> Eelco
>
Re: remove Session#getAuthorizationStrategy?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/15/07, Matej Knopp <ma...@gmail.com> wrote:
> Dunno. What's wrong with having possibility for authentication
> strategy per session? I don't like API bloat, but I can imagine a good
> usecase for this.
If you want a per session strategy, you can still do that, as any
implementation can just use the session for it, or you can even make a
factory for it. It is just bloat.
Eelco
Re: remove Session#getAuthorizationStrategy?
Posted by Matej Knopp <ma...@gmail.com>.
Dunno. What's wrong with having possibility for authentication
strategy per session? I don't like API bloat, but I can imagine a good
usecase for this.
-Matej
On 9/16/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Hey,
>
> Do we have a very good reason for having getAuthorizationStrategy in
> Session? By default, this just does
> getApplication().getSecuritySettings().getAuthorizationStrategy();
>
> I'm revising the chapter on authorization currently, and it just looks
> yacni to me. In the probably rare case that you want to vary the
> strategy by session, you can just do this with the strategy itself.
>
> Is anyone against me removing this method, and change:
>
> addComponentInstantiationListener(new IComponentInstantiationListener() {
> public void onInstantiation(final Component component) {
> if (!Session.get().getAuthorizationStrategy()
> .isInstantiationAuthorized(component.getClass())) {
> getSecuritySettings()
> .getUnauthorizedComponentInstantiationListener()
> .onUnauthorizedInstantiation(component);
> }
> }
> });
>
> to
>
> addComponentInstantiationListener(new IComponentInstantiationListener() {
> public void onInstantiation(final Component component) {
> if (!getSecuritySettings().getAuthorizationStrategy()
> .isInstantiationAuthorized(component.getClass())) {
> getSecuritySettings()
> .getUnauthorizedComponentInstantiationListener()
> .onUnauthorizedInstantiation(component);
> }
> }
> });
>
> ?
>
> Eelco
>