I think authentication is resposibility of the implementation. The first thing the implentation should check for is if the user is authenticated, if they are not throw an AuthenticationException, catch it somewhere and redirect to the login page or wahtever it needs to do.
-Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Eelco Hillenius > Sent: Friday, October 28, 2005 8:26 AM > To: wicket-develop@lists.sourceforge.net > Subject: Re: [Wicket-develop] integrating authorization > > Yes, that's the last interesting issue to solve I think. > Something like you propose. Maybe. If we can ship 1.1. early > this weekend, we can be working on code together right after that :). > > As for Maurices' question: I implemented it as a drop-in (at > least that's the idea). > > Eelco > > > On 10/28/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > > allowAcccess() is not needed if we let allowRender() do 2 > things 1> > > return a boolean that means the component is just not visible 2> > > throw an exception. that means the component will block a > page (this > > exception is catched in Page.checkAccess() > > > > allowEnabled is for interpreting by the developer i think. If the > > developer sees it is a text component it can use that one for > > readonly (instead of disabled). I am fine with that it is > the same at > > the backend (no data can be changed) so it is only a ui > property what > > you want so the designer/developer can choose. > > > > > > My question is (but i will look at the implementation > eelco will make > > :)) > > > > what happens if i call: > > > > allowRender(component) > > > > and i am not logged in? > > Who is catching that? Is that the responsability of the > > implementation of the security? Should it set a response page?? > > But what is then thrown?? > > > > Page.checkAccess() > > { > > try > > { > > boolean visible = security.AllowRender(this); > > // I think allowRender(WithAPage) should always throw an > > exception like it should do with components that block a page. > > // but: > > if( !visible ) > > { > > // Page can't be visible but now that boolean is > saying that > > this was because it was not logged in? > > setResponsePage(MyLoginPage) > > } > > } Catch(NotAllowedException) > > { > > setResponsePage(AccessDenied) > > return false; > > } > > return true; > > } > > > > The visible for a page would have magically have 2 things, > I don't > > like that the security implementation has something to do > with pages, > > setting response things like that > > > > > > > > > > > > On 10/28/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > ------------------------------------------------------- > 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
