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

Reply via email to