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
