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
