Re: question about swarm
te 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 > > >>>>> Date: Thu, 31 Dec 2009 22:35:22 > > >>>>> To: > > >>>>> 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 >
Re: question about swarm
x
> >>>> 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
> >>>>> Date: Thu, 31 Dec 2009 22:35:22
> >>>>> To:
> >>>>> 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&#x
Re: question about swarm
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
>>>>> Date: Thu, 31 Dec 2009 22:35:
Re: question about swarm
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
> >>> Date: Thu, 31 Dec 2009 22:35:22
> >>> To:
> >>> 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
> >>&g
Re: question about swarm
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 >>> Date: Thu, 31 Dec 2009 22:35:22 >>> To: >>> 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.securi
Re: question about swarm
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
> > Date: Thu, 31 Dec 2009 22:35:22
> > To:
> > 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, a
Re: question about swarm
Wow that was quick. Thanks a lot I really appreciate it
Sent via BlackBerry from T-Mobile
-Original Message-
From: Olger Warnier
Date: Thu, 31 Dec 2009 23:31:34
To:
Subject: Re: question about swarm
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
> Date: Thu, 31 Dec 2009 22:35:22
> To:
> 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";
>>>
Re: question about swarm
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
> Date: Thu, 31 Dec 2009 22:35:22
> To:
> 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";
>>>>
>>>>
>>>> -
>
Re: question about swarm
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
Date: Thu, 31 Dec 2009 22:35:22
To:
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
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
Re: question about swarm
That's extremely fragile.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Dec 31, 2009 at 3:41 AM, 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
>
>
Re: question about swarm
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
Re: question about swarm
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
question about swarm
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
