Hi,
I've just reverted your change (which breaks backward compatibility) and added
the ComponentSubclassPermission. I've updated the secure forms example to use
this permission. To replace the default ComponentPermission with
ComponentSubclassPermission, use the construction below (with
org.apache.wicket.security.hive.authorization.permissions.ComponentSubclassPermission).
Best regards,
Emond Papegaaij
On Thursday 07 January 2010 12:42:17 Emond Papegaaij wrote:
> 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.UnauthorizedInstantiationExceptio
> > >>>>>>>n: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
