>First, I don't agree with getExtraFailureInformation. If you want to >have more info on a method, let it return such info (like in a >authorisation result object) or throw an exception with that info.
Ok, I can certainly live with an exception or result object. Actually jaas throws exceptions al the time. The reason why we aren't using securityexceptions yet in our implementation is because johan favored the Boolean and there certainly is a lot to say for using them. But it does make it more difficult to relay addional information. Like you said you can always throw an exception, but then again like the Effective Java Programming Language Guide says: Exceptions are for exceptional use. But I could certainly live with throwing an exception. > The reason >for multiple methods is because that is clearer case-by-case compared >to having method that may have very different outcomes depending on >their input (the actions argument). Ehm isn't that one of the reasons for having method parameters? Are you saying we all should abandon methods that take input? If I make a login method with a username and password argument I certainly want a different outcome depending on the validity of input, whether that would be a boolean or an exception makes no difference. > The advantage of this deliberate >inflexibility is that, as any change will break all clients I'm sorry I don't see this as being an advantage. You don't see jaas code breaking if sun or anyone else comes up with something new like execute rights. > those >clients (the components etc) will have to think about how they're >going to support this additional/ changed authorization functionality. if you're client is only supporting read for example you can check if the input matches read if it doesn't you can throw a not implemented exception or whatever. In most cases the security system will make the conversion for you between action (int) and whatever the system itself uses, if the system can't convert it will throw an exception of some sort. If the system blindly converts the action to something it does not know, then in most cases there still is no problem because the result will be that you don't have that right. If you are going to use isEnabled in say an attributemodifier to change some attribute based on security, isEnabled does not cover the purpose of the method. Perhaps isAuthorized would be a better choice. Actually our ISecurityCheck first came with an isAuthorized method without input params, making it look even more like your interface. But for the sake of flexibility and reusability we changed it to endure the ages. If you add an additional method every time we think of a new check both interfaces certainly can do the same job, but it is so inflexible. It breaks every existing implementation! ________________________________ Maurice Marrink www.topicus.nl -----Original Message----- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: donderdag 27 oktober 2005 1:32 To: wicket-develop@lists.sourceforge.net Subject: Re: [Wicket-develop] integrating authorization First, I don't agree with getExtraFailureInformation. If you want to have more info on a method, let it return such info (like in a authorisation result object) or throw an exception with that info. The reasons for using booleans is because they are cheap. The reason for multiple methods is because that is clearer case-by-case compared to having method that may have very different outcomes depending on their input (the actions argument). Lastely, in this case, as it is such a basic infrastructural interface, whenever we think of more things we need to support, we need to add/ change a method instead of just inventing another 'action'. The advantage of this deliberate inflexibility is that, as any change will break all clients, those clients (the components etc) will have to think about how they're going to support this additional/ changed authorisation functionality. Eelco On 10/26/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > I'm not to crazy about this interface. It looks to me it does what the > ISecurityCheck johan and I came up with does, only less flexible. > > Also it will impose multiple security checks on the component. > If a component is allowed to render it will always check next if it is > allowed to be enabled. > I would very much like a solution where the component only needs to make the > desired checks as specified by the user. One way of doing that would be to > specify on the component what needs to be checked, read or write. > For comparison I will post the ISecurityCheck interface here too. > > package wicket.security; > > import java.io.Serializable; > > public interface ISecurityCheck extends Serializable > { > /** > * Checks if there are sufficient rights to perform the desired > action(s). > * Note that we dont ask what needs to have these rights, the > implementation > * will decide if it chgecks the component or the model. > * > * @param actions > * the action(s) like read or read and write. > * @return true if there are sufficient rights, false otherwise. > */ > public boolean isAuthorized(int actions); > > /** > * Checks if there is an authenticated user available. If not a page > might > * decide to redirect to a login page instead. other components > won't use > * this ordinarily. > * > * @return true if an authenticated user is available, false > otherwise. > */ > public boolean isAuthenticated(); > > /** > * Some optional extra information about the check we just did that > failed > * (returned false). You might use this to display additional > information on > * an accessdenied page, specifie the accessdenied page itself or > something > * completely different. > * > * @return some object containing extra information or null. > */ > public Object getExtraFailureInformation(); > } > > Maurice > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eelco > Hillenius > Sent: donderdag 27 oktober 2005 0:44 > To: wicket-develop@lists.sourceforge.net > Subject: Re: [Wicket-develop] integrating authorization > > 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
