Hi Emond, Thanks for your comments, Interesting matter. Extending ComponentPermission to change the behavior sounds like an option. I can't find the @InPrincipal annotation in the wicket-security project, is this something specific ?
When you look at it from the 'hive' side: It is the standard way of working with Swarm/Wasp, isn't it ? That current way has a quite fragile way to define the authorization rules on anonymous inner classes. How to deal with that ? Is it an option to contribute your annotations with a specific AnnotatedPermission ? That would be really great. Kind Regards, Olger On 6 jan 2010, at 12:52, Emond Papegaaij wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org