authorizeAction is called with Action "RENDER" on every render and the
method is called with Action "ENABLE" by DisabledAttributeModifier and
Component.setModelObject.
You can define your own actions too, and call the
IAuthorizationStrategy methods where you want them by plugging in the
calls in your custom components/ pages are by using AOP to hook into
the existing components.
Eelco
On 2/7/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> This is page construction example yes that works but Page.checkAccess() does
> much more.
> Page.checkAccess() also works after the page is used again when it is
> constructed and when it is rendered the X times.
> And checkAccess can also look for data that the page will display because it
> has instance data. to see if the user can display that data or not.
> Those 2 use cases are not covered by just "boolean
> authorizeInstantiation(Class componentClass)"
>
> I do see we have also a:
>
> boolean authorizeAction(Component component, Action action)
>
> But currently i don't know when that is called. Is that called when the page
> is just rendered again? (set as a response page?)
>
>
> johan
>
>
>
> On 2/7/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> >
> > IAuthorizationStrategy is pretty darn easy to use and really suffers
> > from none of the problems you described. in your application's
> > constructor you would do something like this:
> >
> > getSecuritySettings().setAuthorizationStrategy(new
> > IAuthorizationStrategy()
> > {
> > boolean authorizeInstantiation(Class componentClass)
> > {
> > if (!
> <check-authorization(componentClass)>) // could be
> > annotations or instanceof equivalent or whatever
> > {
> > throw new
> RestartResponseAtSignInPageException();
> > }
> > return true;
> > }
> >
> > boolean authorizeAction(Component component, Action action)
> > {
> > return true;
> > }
> > });
> >
> > and you also have to register a sign in page class in your
> > ISecuritySettings. when the given component (Page in this case)
> > instantiation is attempted, the Component constructor will
> > immediately call your authorization strategy's authorizeInstantiation
> > () method (before anything significant has happened). You can return
> > true or false, or you can throw a
> > RestartResponseAtSignInPageException, which will redirect
> to a sign-
> > in intercept page to allow the user to authenticate themselves before
> > continuing where they left off trying to access.
> >
> > if we want to make this super easy, we could create an Abstract base
> > class for this which lets you just implement the check and not worry
> > about the rest of it. in fact, i think i'll do that... ;-)
> >
> > jon
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
