Still can't say I'm very enthusiastic about this interface, but it could work. IMO there are however still a few things missing in the interface. Currently it has : boolean allowCreateComponent(Class c); to allow/disallow component creation. If it returns false the component will throw a securityexception.
boolean allowRender(Component c); to allow/disallow component rendering. boolean allowEnabled(Component c); to enable/disable a component. What I think is missing: boolean allowWrite(Component c); sometimes you want to set the readonly property on textfields and the like, especially since a disabled formcomponent is not submitted with the form. You could use allowEnabled for this in an attributemodifier but I am not in favor for that. boolean allowAccess(Component c); childs use this to block access to the parent page. In affect the page will not be rendered instead we might redirect to an accessdenied page. If I want to do something unusual like change the background color of my component based on the presence of the foobar right of the user, I would probably use an attributemodifier to do it. My implementation of the interface would contain an additional hasFoorbar check and the attributemodifier would use that. --I was trying to find an example of this interface not working, but I guess I've just blown it for myself ;)-- Still think the 2 methods above should be in the interface though. And I still don't like the fact that if we change this interface later on it will brake any existing code. Ok, so we have an interface, that is not enough to build a securityframework. What are the plans for that? I think the framework johan and I designed could very easily be adapted to use this interface instead of the IsecurityCheck it does now. Basicly I'm looking for answers for the following questions. Is the interface going to be a drop in (setSecurity(SecurityInterface sec) or will components implement the interface? --The drop in has my vote. How will users specify what security framework to use (jaas, aesgi)? (factory of some sort or do users have to set up everything manually and make the calls to the framework directly from within the interface) --I am in favor of the factory, but even without that it will be relatively easily to provide some basic implementation in wicket-extensions for jaas or aesgi. Ok, feeling better about the interface now then I did when I started writing it. ________________________________ Maurice Marrink www.topicus.nl -----Original Message----- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: donderdag 27 oktober 2005 21:00 To: wicket-develop@lists.sourceforge.net Subject: RE: [Wicket-develop] integrating authorization What Eelco meant is that allowEnabled does not dictate component visibility, allowRender does that. If allowRender returns false you will never get allowEnabled callback for the same component. allowEnabled dictates whether this component is enabled - normal mode or disabled - effectively read-only mode. Our idea is to provide an interface that is completely free of implementation details, in fact it is nothing more then a callback interface for certain places in component lifecycle. -Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Maurice Marrink > Sent: Thursday, October 27, 2005 12:52 AM > To: wicket-develop@lists.sourceforge.net > Subject: RE: [Wicket-develop] integrating authorization > > Not sure i get what isn't, but disabling components based on > user authorization is also exactly what we need for our project. > > Yes throwing an exception should do the same trick. > > ________________________________ > > Maurice Marrink > www.topicus.nl > > -----Original Message----- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: donderdag 27 oktober 2005 1:36 > To: wicket-develop@lists.sourceforge.net > Subject: Re: [Wicket-develop] integrating authorization > > Nope it isn't. It is one of the main things I want to use in > my current project. Not rendering components based on the > current roles of a user. Kind of like portal functionality. > > I didn't really think of the case of letting one component > trigger a page to be invalid. I see... good case too. I think > that might be an implementation detail though. Instead of > returning the boolean, a component may still throw an auth > related exception. That should work, right? > > Eelco > > > On 10/26/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > and Links/Labels are using allowEnabled for there visible state. > > Now that's great I wonder why we haven't thought of that > before, we'll > just > > use allowEnabled to dictate a components visibility!. It > makes so much > > sense! > > Sorry for being sarcastic here but is getting late :) You > can't have > > allowEnabled doing double duty here it will confuse the > hell > > out of people. > > But johan is right we need a way of letting a component / > model block > access > > to a page completely or just allow the page to be displayed but not > the > > component itself. > > And you know what, we already can by using actions like access, read > and > > write. If something does not have access it blocks the page, if it > does not > > have read the page will display but not the component. > > > > Maurice > > > > ________________________________________ > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > Behalf Of Johan > > Compagner > > Sent: donderdag 27 oktober 2005 1:14 > > To: wicket-develop@lists.sourceforge.net > > Subject: Re: [Wicket-develop] integrating authorization > > > > yes that i did get. > > So if one component on the page returns false for > allowRender() then > > the page it self is not visible (allowAccess() failes) > > > > and Links/Labels are using allowEnabled for there visible state. > > > > On 10/27/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > It works exactly like isVisible, with the exception that it will > > allways overrule isVisible (I'll put that in the docs). > > > > Eelco > > > > > > On 10/26/05, Johan Compagner <[EMAIL PROTECTED] > wrote: > > > where will allowRender() be called in wicket? > > >I think the most logical first place it the Page.checkAccess() or > > > Page.checkSecurity() that is also called besides checkAccess() > > > > > >Does then the implementation do the compleet check for the page? > > >So the page itself and then all the components on the page? > > >But how does it check the components and there model data? ( think > models > > > > > need some kind of marker interface like SecurityModel) > > > > > >Because it can be that a form's model data is saying i can't render > so > > the > > > page can be renderd > > >But a link can also say i can't be renderd but that > doesn't mean the > page > > > > > can't be rendered (just the link can't be rendered) > > > > > >Or if allowRender() is false in any component/model on the > page then > the > > > complete page can't be rendered > > >but then allowEnabled is used to say to a link that it can't be > visible > > (so > > > there are no non enabled links they are always not rendered) > > > > > > > > > > > > On 10/27/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > Here's the interface method we (Jonathan, Igor and I) think will > work: > > > > > > > > /** > > > >* Checks whether an instance of the given component class may > > be > > > created. > > > >* If this method returns false, a [EMAIL PROTECTED] > > AuthorizationException} > > > is thrown > > > >* in during construction. > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether the given component may be created */ boolean > > > >allowCreateComponent(Class c); > > > > > > > > /** > > > >* Gets whether the given component may be rendered. If this > > > method returns > > > >* false, the component is not rendered, and neither are it's > > > children. > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether the given component may be rendered */ > boolean > > > >allowRender(Component c); > > > > > > > > /** > > > >* <p> > > > >* Gets whether a component is allowed to be enabled. If this > > > method returns > > > >* true, a component may decide by itself (typically using it's > > > enabled > > > >* property) whether it is enabled or not. If this method > > returns > > > false, the > > > >* passed component is marked disabled, regardless it's enabled > > > property. > > > >* </p> > > > >* <p> > > > >* When a component is not allowed to be enabled (in effect > > > disabled through > > > >* the implementation of this interface), Wicket will try to > > > prevent model > > > >* updates too. This is not completely fail safe, as constructs > > > like: > > > >* > > > >* <pre> > > > >* User u = (User)getModelObject(); > > > >* u.setName ("got you there!"); > > > >* </pre> > > > >* > > > >* can't be prevented. Indeed it can be argued that any model > > > protection is > > > >* best dealt with in your model objects to be completely > > secured. > > > Wicket > > > >* will catch all normal use though. > > > >* > > > >* </p> > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether a component is allowed to be enabled > */ boolean > > > >allowEnabled(Component c); > > > > > > > > Eelco > > > > > > > > > > > > On 10/26/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > > > Well, then there's no special wicket support for that > nescesarry > > either. > > > > > > > > > > >I only want to test at a certain point what is inside the > model. > > And > > > if a > > > > > > user can see that object > > > > > >and if he can see it if he can alter it. > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > Get Certified Today * Register for a JBoss Training Course Free > > > > Certification Exam for All Training Attendees Through End of > 2005 > > > > Visit http://www.jboss.com/services/certification for > > > more information > > > > _______________________________________________ > > > > Wicket-develop mailing list > > > > Wicket-develop@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course Free > > Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more > information > > _______________________________________________ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course Free > > Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more > information > > _______________________________________________ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through > End of 2005 Visit http://www.jboss.com/services/certification > for more information _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through > End of 2005 Visit http://www.jboss.com/services/certification > for more information _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
