-Igor
On 2/8/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I'm +1 for removing.
Eelco
On 2/8/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Yes but checkAccess is then a bit strange method name..
> With the new interface it is better named and refactored.
>
> The question still stays.. Can i remove checkAccess() in 1.2 all together or
> depricate it for 1.2 and remove it later on?
> If the latter then i need to fix a few problems with the current
> checkAccess()
>
> johan
>
>
>
> On 2/8/06, Maurice Marrink < [EMAIL PROTECTED]> wrote:
> > Isn't that basicly the same as having a checkAccess method in Page.
> > The way i see it you are moving the checkAccess inside the render
> > method as the very first step. And you apply it to all child
> > components whereas in checkAccess the user can decide for himself if
> > he wan'ts to check his childs.
> >
> > Just my 2 cents.
> >
> > Maurice
> >
> > 2006/2/7, Johan Compagner <[EMAIL PROTECTED] >:
> > > no need to because choose checks are the first thing that is checked for
> a
> > > page.doRender() (itself and the childs)
> > > So if the check fails we don't have any written output yet and the other
> > > redirect page can be rendered just fine.
> > >
> > >
> > >
> > > On 2/7/06, Igor Vaynberg < [EMAIL PROTECTED] > wrote:
> > > > do the same as the error for modifying tree during render?
> > > >
> > > > -Igor
> > > >
> > > >
> > > >
> > > >
> > > > On 2/7/06, Johan Compagner <[EMAIL PROTECTED] > wrote:
> > > > > hmm i don't think this will work right:
> > > > >
> > > > > protected final void onRender(final MarkupStream markupStream)
> > > > > {
> > > > > // first try to check if the page can be rendered:
> > > > > authorize(RENDER);
> > > > > // Visit all this page's children to reset markup streams
> and
> > > check
> > > > > // rendering authorization, as appropriate. We set any
> result;
> > > positive
> > > > > // or negative as a temporary boolean in the components, and
> > > when a
> > > > > // authorization exception is thrown it will block the
> rendering
> > > of this
> > > > > // page
> > > > > visitChildren(new IVisitor()
> > > > > {
> > > > > public Object component(final Component component)
> > > > > {
> > > > > // Find out if this component can be rendered
> > > > > final boolean renderAllowed =
> > > component.authorize(RENDER);
> > > > >
> > > > > // Authorize rendering
> > > > > component.setRenderAllowed(renderAllowed);
> > > > > return IVisitor.CONTINUE_TRAVERSAL ;
> > > > > }
> > > > > });
> > > > >
> > > > >
> > > > > what happens if one of the calls of authorize doesn't return true or
> > > false but returns a redirect exception?
> > > > > we are already in the render phase (checkaccess was moved from there
> to
> > > be one of the steps before the response phase!)
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On 2/7/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > > > > not for a page itself as far as i can see:
> > > > > >
> > > > > > this is Page.onRender:
> > > > > >
> > > > > > // Visit all this page's children to reset markup streams and
> check
> > > > > > // rendering authorization, as appropriate. We set any
> result;
> > > positive
> > > > > > // or negative as a temporary boolean in the components,
> and
> > > when a
> > > > > > // authorization exception is thrown it will block the
> > > rendering of this
> > > > > > // page
> > > > > > visitChildren(new IVisitor()
> > > > > > {
> > > > > > public Object component(final Component component)
> > > > > > {
> > > > > > // Find out if this component can be rendered
> > > > > > final boolean renderAllowed = component.authorize
> > > (RENDER);
> > > > > >
> > > > > > // Authorize rendering
> > > > > > component.setRenderAllowed (renderAllowed);
> > > > > > return IVisitor.CONTINUE_TRAVERSAL ;
> > > > > > }
> > > > > > });
> > > > > >
> > > > > > should we also add first:
> > > > > > authorize(RENDER);
> > > > > >
> > > > > > so that we first check the page if it can be rendered?
> > > > > >
> > > > > > johan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2/7/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > > > > > > 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?cmdlnk&kid3432&bid#0486&dat1642
> > > > > > > _______________________________________________
> > > > > > > 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?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > 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?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
