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
