Hi,
Your change breaks some functionality. It is now no longer possible to grant
permissions for anonymous inner classes at all, you are now forced to grant
the permission on the superclass. This might seem sensible when using a hive
file, but it is not when permissions are configured in other ways.
We create permissions by annotating components with an @InPrincipal
annotation. It is possible to create a (abstract) component and have multiple,
anonymous subclasses, each with their own @InPrincipal annotation.
I think, this should be fixed with a special ComponentPermission: one that
does not only give permission to the specified class, but also to its
subclasses. This could be achieved by extending ComponentPermission and
overriding the implies method. The first part of the the path array should
contain the classname of the component.
Best regards,
Emond Papegaaij
On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
> Hi Sam,
>
> Found the way to solve it. It is fixed in the trunk. Still need to fix the
> build server - so a check out and build of the whole is probably best. An
> anonymous class will act like its' parent now.
>
> Happy new year (to you all).
>
> Olger
>
> On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
> > In my opinion, that's how it should work; just seems like common sense to
> > me. Even for regular (non-anonymous) classes, it would be useful although
> > that's not as important.
> >
> > As far as the technical part I have no idea. I've only been working with
> > swam for 3 days. But I will do some looking at the source code.
> >
> > Sent via BlackBerry from T-Mobile
> >
> > -----Original Message-----
> > From: Olger Warnier <ol...@xs4all.nl>
> > Date: Thu, 31 Dec 2009 22:35:22
> > To: <users@wicket.apache.org>
> > Subject: Re: question about swarm
> >
> > Hi Sam & Jeremy,
> >
> > Together with the remark that Jeremy made - I agree, it is quite fragile
> > - I had a look at the code that does the checks. I could 'assume' that an
> > anonymous class needs the same rights as the 'normal' class. so when your
> > CreateItemPage has the proper rights, an anonymous variant has the
> > similar rights.
> >
> > The other way is some kind of inheritance assumption. This needs some
> > kind of syntax in the hive file like the 'inherit' that is currently
> > available. This inherit is more page with child component 'inheritance'
> > and not like in OO thinking (If understand this completely). With this in
> > mind, I would say that treating an anonymous class as the class it
> > 'extends' may be the best. I tried to figure out how to recognize an
> > anonymous class. It seems that Class.getSimpleName = "" or a search to
> > $[0-9] in getName is a solution but it seems risky when you use a non-sun
> > JVM.
> >
> > What do you think ?
> >
> > Kind Regards,
> >
> > Olger
> >
> > On 31 dec 2009, at 10:53, Sam Barrow wrote:
> >> I know I can do that, but there's no way do do it by inheritance? I have
> >> hundreds of anonymous subclasses throughout my application. Seems
> >> sensible that subclasses should inherit their parent's permissions.
> >>
> >> On Thu, 2009-12-31 at 10:41 +0100, Olger Warnier wrote:
> >>> Hi Sam,
> >>>
> >>> I have added a sample to the secureform sample where the home page
> >>> creates an anonymous class of the MySecurePage An anonymous page has a
> >>> kind of a class name. Look for a
> >>>
> >>> ERROR - RequestCycle - Not authorized to instantiate
> >>> class org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
> >>> org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
> >>> authorized to instantiate class
> >>> org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
> >>>
> >>> And add the line to the hive:
> >>>
> >>> permission ${ComponentPermission}
> >>> "org.apache.wicket.security.examples.secureform.pages.HomePage$2$1",
> >>> "render, enable";
> >>>
> >>> As you can see it does not contain a line with the target response page
> >>> but a line that contains the setResponsePage call. So you need to add a
> >>> line that contains the 'name' of the anonymous class to the hive.
> >>>
> >>>
> >>> Kind Regards,
> >>>
> >>> Olger
> >>>
> >>> On 31 dec 2009, at 02:46, Sam Barrow wrote:
> >>>> I hope this is the right list for wasp/swarm.
> >>>> How do i manage permissions for an anonymous subclass?
> >>>>
> >>>> I have a page called ItemPage. I can view ItemPage, but if I try to
> >>>> redirect to an anonymous subclass of ItemPage, i get an access denied
> >>>> error.
> >>>>
> >>>> this works:
> >>>> setResponsePage(new CreateItemPage(getPage()));
> >>>>
> >>>> but this doesnt:
> >>>> setResponsePage(new CreateItemPage(getPage()) {
> >>>> @Override
> >>>> protected void onSuccess(final Serializable index) {
> >>>> setResponsePage(new ViewItemPage(getBackPage(), index));
> >>>> }
> >>>> });
> >>>>
> >>>> hive file:
> >>>>
> >>>> permission ${ComponentPermission} "${pages}.CreateItemPage", "inherit,
> >>>> render";
> >>>> permission ${ComponentPermission} "${pages}.CreateItemPage", "enable";
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
