On Wed, May 14, 2008 at 1:10 PM, Andrea Jahn <[EMAIL PROTECTED]> wrote:
>
>
>
> I just tried to reproduce the problem, why the resultHiddenPanel was not
> visible, when I used the ContainerSecurityCheck in the class
> SecureWebMarkupContainer (what I do now also). I used the old policy file,
> the PolicyFileHiveFactory instead of the SwarmPolicyFileHiveFactory, ... but
> I cannot reproduce the permission denied.
>
> Now it always works correct ;-)
>
> I think the reason is eliminated in 1.3-SNAPSHOT .
Correct, the 1.3.1-SNAPSHOT contained old code.
>
> Now I will try to secure other types of components on the pages, test the
> different settings for the permissions you explained below and after that I
> have to find out how to set data permissions.
I just committed a DataSecurityCheck ( a very simple class) to help
you do just that. just use it like any other ISecurityCheck (e.g
ContainerSecurityCheck)
Maurice
>
> Andrea
>
> *Von:* users@wicket.apache.org
> *Gesendet:* 14.05.08 12:35:11
> *An:* users@wicket.apache.org
> *Betreff:* Re: Swarm: Authorization for WebMarkupContainer
>
>
>
> On Wed, May 14, 2008 at 11:53 AM, Andrea Jahn <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>> Hi,
>>
>> thanks for the test example. With the help of that I found the error in the
>> policy file:
>> the permission of the page must not contain the inherit action, when there
>> are secure components on the page, which are not permitted.
>
> Thats why i asked :)
>
>>
>>
>>
>> grant principal
>> org.apache.wicket.security.hive.authorization.SimplePrincipal "APPL_TEST"
>> {
>> permission ${ComponentPermission} "${front}.ProductAreaListPage", "render";
>> permission ${ComponentPermission} "${front}.ProductAreaListPage", "enable";
>> };
>>
>> Now a user with permission "APPL_TEST" can open the page
>> ProductAreaListPage, but he cannot see the secure component
>> "resultHiddenPanel".
>> When the action "inherit" is added to the first line, the
>> "resultHiddenPanel" is visible.
>>
>> I need the second line, because the user calls the page via the menu (link).
>
> Correct, however you can shorten it to one permission with a "render,
> enable" action.
> The reason i always split my permissions "inherit, render" and
> "enable" is because i often want all child components to be visible
> but not all of them editable (enabled)
> In this case there is no inherit action and thus you can put
> everything in 1 permission.
>
>>
>>
>>
>> grant principal
>> org.apache.wicket.security.hive.authorization.SimplePrincipal "APPL_ADMIN"
>> {
>> permission ${ComponentPermission}
>> "${front}.ProductAreaListPage:resultHiddenPanel", "inherit, render";
>> permission ${ComponentPermission} "${front}.ProductAreaListPage", "enable";
>> };
>>
>> A user who has the permission "APPL_ADMIN" can see the page and the secure
>> component "resultHiddenPanel".
>> So am I right, that the first line implies the security permission for the
>> page ?
>
> Both do actually. "inherit render" is for visibility and to allow
> users to instantiate that page. (page instantiation is actually the
> "access" action but it is implied by every other action and therefore
> can be omitted from the policy. It is used internally though).
> "enable" is used by SecurePageLinks. For example if i have a
> SecurePageLink "link" on a Page A pointing to Page B and i want only
> specific users to have access to B then i would add permission
> ${ComponentPermission} "B", "enable";
> for those users. every other user will not see the link. although it
> is logical if you think about it it is different from other components
> where a permission ${ComponentPermission} "A:link", "render"; or
> permission ${ComponentPermission} "A", "inherit, render"; would be
> required. This behavior can be changed though :)
>
> Hmm reading back the above i can see how you might get a bit confused.
> I was just trying to explain it, maybe a bit to condensed.
> Anyhow most people require both permissions :)
>
> Maurice
>>
>>
>>
>> I have changed to 1.3-SNAPSHOT and I will go on working with that.
>>
>>
>> Andrea
>>
>>
>> *Von:* users@wicket.apache.org
>> *Gesendet:* 14.05.08 00:07:49
>>
>> *An:* users@wicket.apache.org
>> *Betreff:* Re: Swarm: Authorization for WebMarkupContainer
>>
>>
>>
>>
>>
>> Ok, so i did some testing (and in the process found another bug,
>> unrelated to your issue :)), but i could not reproduce your permission
>> denied.
>> Here is my simple setup:
>>
>> public class ContainerPage2 extends SecureWebPage
>> {
>>
>> /**
>> * Construct.
>> */
>> public ContainerPage2()
>> {
>> add(new Label("label", "always visible"));
>> SecureMarkupContainer container = new SecureMarkupContainer("secure");
>> container.add(new Label("hidden", "hidden label"));
>> add(container);
>> }
>>
>> /**
>> * Simple secure container.
>> *
>> * @author marrink
>> */
>> private static final class SecureMarkupContainer extends WebMarkupContainer
>> implements
>> ISecureComponent
>> {
>> /**
>> *
>> */
>> private static final long serialVersionUID = 1L;
>>
>> /**
>> *
>> * Construct.
>> *
>> * @param id
>> */
>> public SecureMarkupContainer(String id)
>> {
>> super(id);
>> setSecurityCheck(new ContainerSecurityCheck(this));
>> }
>>
>> /**
>> *
>> * @see
>> org.apache.wicket.security.components.ISecureComponent#getSecurityCheck()
>> */
>> public ISecurityCheck getSecurityCheck()
>> {
>> return SecureComponentHelper.getSecurityCheck(this);
>> }
>>
>> /**
>> *
>> * @see
>> org.apache.wicket.security.components.ISecureComponent#isActionAuthorized(java.lang.String)
>> */
>> public boolean isActionAuthorized(String waspAction)
>> {
>> return SecureComponentHelper.isActionAuthorized(this, waspAction);
>> }
>>
>> /**
>> *
>> * @see
>> org.apache.wicket.security.components.ISecureComponent#isActionAuthorized(org.apache.wicket.security.actions.WaspAction)
>> */
>> public boolean isActionAuthorized(WaspAction action)
>> {
>> return SecureComponentHelper.isActionAuthorized(this, action);
>> }
>>
>> /**
>> *
>> * @see
>> org.apache.wicket.security.components.ISecureComponent#isAuthenticated()
>> */
>> public boolean isAuthenticated()
>> {
>> return SecureComponentHelper.isAuthenticated(this);
>> }
>>
>> /**
>> *
>> * @see
>> org.apache.wicket.security.components.ISecureComponent#setSecurityCheck(org.apache.wicket.security.checks.ISecurityCheck)
>> */
>> public void setSecurityCheck(ISecurityCheck check)
>> {
>> SecureComponentHelper.setSecurityCheck(this, check);
>> }
>>
>> }
>>
>> }
>>
>> and my policy file looks like this:
>>
>> grant principal ${SimplePrincipal} "container4"
>> {
>> //this does not permit secure components on a ContainerPage2 to be visible
>> permission ${ComponentPermission} "${myPackage}.ContainerPage2", "render";
>> permission ${ComponentPermission} "${myPackage}.ContainerPage2", "enable";
>> };
>> grant principal ${SimplePrincipal} "container5"
>> {
>> //this grants the permission to any component with id "secure" on a
>> ContainerPage2
>> permission ${ComponentPermission}
>> "${myPackage}.ContainerPage2:secure", "inherit, render";
>> permission ${ComponentPermission} "${myPackage}.ContainerPage2", "enable";
>> };
>> grant principal ${SimplePrincipal} "container6"
>> {
>> //this grants the permission to any SecureMarkupContainer inside a
>> ContainerPage2
>> permission ${ComponentPermission}
>> "${myPackage}.ContainerPage2:${myPackage}.ContainerPage2$SecureMarkupContainer",
>> "inherit, render";
>> permission ${ComponentPermission} "${myPackage}.ContainerPage2", "enable";
>> };
>> grant principal ${SimplePrincipal} "container7"
>> {
>> //this grants the permission to any SecureMarkupContainer, even when
>> placed on other pages (if it wasn't a private class)
>> permission ${ComponentPermission}
>> "${myPackage}.ContainerPage2$SecureMarkupContainer", "inherit,
>> render";
>> permission ${ComponentPermission} "${myPackage}.ContainerPage2", "enable";
>> };
>>
>>
>> Argh, i am only just reading you are using 1.3.1-SNAPSHOT. You should
>> be using 1.3-SNAPSHOT. That does it i am deleting those jars.
>>
>> Maurice
>>
>>
>> On Tue, May 13, 2008 at 8:10 PM, Maurice Marrink <[EMAIL PROTECTED]> wrote:
>> > On Tue, May 13, 2008 at 6:48 PM, Andrea Jahn <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Hi,
>> > >
>> >
>> > > I've changed to the 1.3.1-SNAPSHOT version. Therefore I have only
>> > > replaced the constructor PolicyFileHiveFactory() by
>> > > PolicyFileHiveFactory(ActionFactory).
>> > > The result was the same as with version 1.3.0 (resultHiddenPanel not
>> > > visible and the same output in the logfile).
>> >
>> > Are you using the SwarmPolicyFileHiveFactory? see
>>
>> > http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security+1.3.1#Wicket-Security1.3.1-migrateto1.3.1
>> >
>> >
>> > >
>>
>> > > Then I changed the ContainerSecurityCheck with a ComponentSecurityCheck
>> > > in the class SecureWebMarkupContainer.
>> > > The resultHiddenPanel now is always visible (also when the user has not
>> > > the permission).
>> >
>> > Well like i said earlier permission ${ComponentPermission}
>> > "xxx.yyy.zzz.front.ProductAreaListPage", "inherit, render"; is
>> > sufficient to allow the entire page to be rendered, does your policy
>> > file contain another grant statement with a similar permission?
>> >
>> >
>> > >
>> > > Logfile:
>> > >
>> > > 2008-05-13 18:30:30,880 DEBUG
>> > > org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:214)
>> > > - Subjects[HashKey: 821489378, sortOrder 0 = [EMAIL PROTECTED]
>> > > [mailto:[EMAIL PROTECTED] implies
>> > > org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
>> > > "xxx.yyy.zzz.front.ProductAreaListPage:resultHiddenPanel" "access,
>> > > render"
>> > >
>> > > 2008-05-13 18:30:32,583 DEBUG
>> > > org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:188)
>> > > - Subjects[HashKey: 821489378, sortOrder 0 = [EMAIL PROTECTED]
>> > > [mailto:[EMAIL PROTECTED] has a cached match for
>> > > org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
>> > > "xxx.yyy.zzz.front.ProductAreaListPage:resultHiddenPanel" "access,
>> > > render", result true
>> > >
>> > >
>> > > Perhaps I have made another mistake ?
>> >
>> > Hmm, the ContainerSecurityCheck should have worked, let me see if i
>> > can reproduce that with a test.
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > > Maurice,
>> > >
>> > > thank you very much for the quick replies !
>> > > Should I (or could you) delete my first question from the "Getting
>> > > started with SWARM" page, as it was the wrong place to post the question
>> > > ?
>> > >
>> >
>> > Deleted.
>> >
>> > Maurice
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>
>>
>>
>> Schon gehört? Der neue WEB.DE MultiMessenger kann`s mit allen:
>> *http://www.produkte.web.de/messenger/?did=3016*
>> [http://www.produkte.web.de/messenger/?did=3016]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> *http://smartsurfer.web.de/?mc=100071&distributionid=000000000066*
> [http://smartsurfer.web.de/?mc=100071&distributionid=000000000066]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
