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