You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by apsegian <ap...@gmail.com> on 2007/12/13 13:05:57 UTC
Where to apply a general security policy
I am requested to apply a security policy in a wicket project on every
request (including ajax requests) posted to the server. The obvious solution
to this, is to call a method (like applySecurity()) in every onClick(),
onUpdate() etc event of all form components of the page. The problem is that
this solution is very buggy, because every developer working on this
project should be aware of this restriction. Is there any method of the
framework that can be overwritten in order to achieve this more centralized?
--
View this message in context: http://www.nabble.com/Where-to-apply-a-general-security-policy-tp14314461p14314461.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Where to apply a general security policy
Posted by Maurice Marrink <ma...@gmail.com>.
Actually wicket already does that for you. It does so by delegating to
the IAuthorizationStrategy. The default one just allows everything.
Maurice
On Dec 13, 2007 1:36 PM, Christopher Hlubek <br...@gmail.com> wrote:
> AFAIK you could use a custom WebRequestCycle that checks your security
> policy on every request (see
> http://wicket.sourceforge.net/apidocs/wicket/RequestCycle.html and
> http://wicket.sourceforge.net/apidocs/wicket/protocol/http/WebRequestCycle.html).
>
> Best regards,
>
> Christopher Hlubek
>
> 2007/12/13, apsegian <ap...@gmail.com>:
>
> >
> > I am requested to apply a security policy in a wicket project on every
> > request (including ajax requests) posted to the server. The obvious solution
> > to this, is to call a method (like applySecurity()) in every onClick(),
> > onUpdate() etc event of all form components of the page. The problem is that
> > this solution is very buggy, because every developer working on this
> > project should be aware of this restriction. Is there any method of the
> > framework that can be overwritten in order to achieve this more centralized?
> > --
> > View this message in context: http://www.nabble.com/Where-to-apply-a-general-security-policy-tp14314461p14314461.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > 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: Where to apply a general security policy
Posted by Christopher Hlubek <br...@gmail.com>.
AFAIK you could use a custom WebRequestCycle that checks your security
policy on every request (see
http://wicket.sourceforge.net/apidocs/wicket/RequestCycle.html and
http://wicket.sourceforge.net/apidocs/wicket/protocol/http/WebRequestCycle.html).
Best regards,
Christopher Hlubek
2007/12/13, apsegian <ap...@gmail.com>:
>
> I am requested to apply a security policy in a wicket project on every
> request (including ajax requests) posted to the server. The obvious solution
> to this, is to call a method (like applySecurity()) in every onClick(),
> onUpdate() etc event of all form components of the page. The problem is that
> this solution is very buggy, because every developer working on this
> project should be aware of this restriction. Is there any method of the
> framework that can be overwritten in order to achieve this more centralized?
> --
> View this message in context: http://www.nabble.com/Where-to-apply-a-general-security-policy-tp14314461p14314461.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Where to apply a general security policy
Posted by Maurice Marrink <ma...@gmail.com>.
you could take a look at the IAuthorizationStrategy but that would
basically mean building your own security framework from scratch.
A better solution would be to use either Wicket-Auth-Roles or Swarm as
your security framework.
Neither is centralized, both are geared towards securing individual
components. But you can easily use that to build your own components
that are secure and require your developers to use those instead of
the default wicket components.
A comparison between the two frameworks can be found here
http://wicketstuff.org/confluence/display/STUFFWIKI/Security+Framework+Comparison
>From there you can find links with more information.
Maurice
On Dec 13, 2007 1:05 PM, apsegian <ap...@gmail.com> wrote:
>
> I am requested to apply a security policy in a wicket project on every
> request (including ajax requests) posted to the server. The obvious solution
> to this, is to call a method (like applySecurity()) in every onClick(),
> onUpdate() etc event of all form components of the page. The problem is that
> this solution is very buggy, because every developer working on this
> project should be aware of this restriction. Is there any method of the
> framework that can be overwritten in order to achieve this more centralized?
> --
> View this message in context: http://www.nabble.com/Where-to-apply-a-general-security-policy-tp14314461p14314461.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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