Well, provided you've implemented the ComponentSubclassPermission, you could overwrite the alias for ComponentPermission by subclassing the SwarmPolicyFileHiveFactory like this:
public class MyFileHiveFactory extends SwarmPolicyFileHiveFactory { public MyFileHiveFactory(ActionFactory actionFactory) { super(actionFactory); setAlias("ComponentPermission", my.ComponentSubclassPermission"); } } This would replace the usage of ComponentPermission by ComponentSubclassPermission and requires no change to the hive file. Emond On Thursday 07 January 2010 11:09:52 Olger Warnier wrote: > Hi Emond, > > Very nice. Could you think of a way to support your scenario and a way to > support anonymous classes in a way that you don't have to specify a > MyPageClass$1$2 and we don't have to impose a change in the hive file ? > > Kind Regards, > > Olger > > On 6 jan 2010, at 14:03, Emond Papegaaij wrote: > > Hi Olger, > > > > The InPrincipal annotation is something we developed as an alternative > > for the hive files (which we find difficult to maintain, not only with > > anonymous inner classes). Principals are defined by a set of classes with > > annotations defining things like implies relations between principals and > > DataPermissions. ComponentPermissions are created by scanning for > > components with the InPrincipal annotation and creating the permissions > > for those. We are thinking about releasing this code, perhaps by > > including it in wicket-security. > > > > When using a hive file, you define your principals, each with a set of > > permissions. Currently, you can use ComponentPermission, DataPermission > > and AllPermissions. My suggestion is to add another permission that gives > > permissions to a component and all of its subclasses (including anonymous > > classes), something like: > > > > permission ${ComponentSubclassPermission} "MyPage", "inherit, render; > > > > This would give you permission for MyPage and its subclasses. You can > > define the alias for ComponentSubclassPermission in > > SwarmPolicyFileHiveFactory. I think that this is the way Swarm/Wasp is > > 'supposed to be used'. > > > > Best regards, > > Emond > > > > On Wednesday 06 January 2010 13:09:09 Olger Warnier wrote: > >> 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 > > > > --------------------------------------------------------------------- > > 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