Ah you mean the permission not being specified on a single line?
Should have spotted that too :)
>From the apidoc for PolicyFileHiveFactory:
A factory to produce Hive's based on policy files. This factory is
designed to make a best effort when problems occur. Meaning any
malconfiguration in the policy file is logged and then skipped. This
factory accepts the following policy format
grant[ principal <principal class> "name"]
{
permission <permission class> "name",[ "actions"];
};
where [] denotes an optional block, <> denotes a classname.
For brevity aliases are allowed in / for classnames and permission-,
principal names. An alias takes the form of ${foo} the alias (the part
between {}) must be at least 1 character long and must not contain one
of the following 4 characters "${} For example: permission
${ComponentPermission} "myname.${foo}", "render";
Note that:
-names and action must be quoted
-a permission statement must be on a single line and terminated by a ;
-the grant block must be terminated by a ;
-if you don't specify a principal after the grant statement, everybody
will be given those permissions automagically
-using double quotes '"' is not allowed, instead use a single quote '''
-aliases may be chained but not nested, so ${foo}${bar} is valid but
not ${foo${bar}}
-aliases are not allowed in actions or reserved words (grant,
permission, principal)
-aliases are case sensitive.
By default the following aliases are available ComponentPermission,
DataPermission and AllPermissions for
org.apache.wicket.security.hive.authorization.permissions.ComponentPermission,
org.apache.wicket.security.hive.authorization.permissions.DataPermission
and org.apache.wicket.security.hive.authorization.permissions.AllPermissions
respectively
As for a complex example, Hive files imo are not so much complex as
that they tend to grow (especially for big applications with complex
authorization they can get huge). This makes them intimidating and
somewhat difficult to maintain unless you are familiar with the
content. But even in the policy files for our application which are
combined easily around 10K lines the individual principal blocks are
not more complex then yours. The tricky part is understanding how
multiple principals interact with each other. Or how component
permission inheritance works. I tried documenting this sort of stuff
on the wiki (
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
) but i realize that i, like many other programmers, am not really
good at documenting things. Fortunately it is a wiki so other people
can add missing stuff, or clarify my ramblings :) Telling me what is
missing / wrong with the documentation also works but it tends to take
a bit longer then ;)
Maurice
On Sun, Jun 29, 2008 at 11:27 PM, Sergey Podatelev
<[EMAIL PROTECTED]> wrote:
> Thanks a lot again, Maurice, this time it was just the question of syntax.
> In fact, is there a description of the .hive file syntax somewhere, or at
> least a really complex .hive file to look at?
>
> On Sun, Jun 29, 2008 at 4:38 PM, Maurice Marrink <[EMAIL PROTECTED]> wrote:
>
>> In version 1.3.0 inheritance is somewhat limited. It can only follow
>> absolute paths.
>> So unless your ${SecuredTextFieldOne} alias resolves to something like
>> this: PageClass:panel1ID:panel2ID:textfieldID it will not work.
>>
>> This has been fixed in 1.3-SNAPSHOT where you can now use container
>> classes in the same way as pages. If you can switch to that version
>> something like org.mypackage.SecurePanelTwo:textfieldID should do the
>> trick or if you want to be more precise
>> PageClass:Panel1Class:Panel2Class:textfieldID
>>
>> Hope this helps.
>>
>> Maurice
>>
>> On Thu, Jun 26, 2008 at 11:00 PM, Sergey Podatelev
>> <[EMAIL PROTECTED]> wrote:
>> > Hello,
>> >
>> > I'm using Wicket-Security-1.3, and can't enable SecureTextFields.
>> > The SecureTextField sitting in a panel, which extends SecurePanel, which
>> > sits in another secured panel, and all this is on SecureWebPage.
>> >
>> > The problem is, no matter what I write in my policies.hive file, that
>> > textfield won't allow to write to it. It's displayed as disabled input.
>> >
>> > policies.hive:
>> >
>> > grant principal ${DefaultPrincipal} "testuser"
>> > {
>> > permission ${ComponentPermission} "${SecurePageOne}", "inherit, render";
>> > permission ${ComponentPermission} "${SecurePageOne}", "enable";
>> >
>> > permission ${ComponentPermission} "${SecurePanelOne}", "inherit,
>> render";
>> > permission ${ComponentPermission} "${SecurePanelOne}", "enable";
>> >
>> > permission ${ComponentPermission} "${SecurePanelTwo}", "inherit,
>> render";
>> > permission ${ComponentPermission} "${SecurePanelTwo}", "enable";
>> >
>> > permission ${ComponentPermission} "${SecuredTextFieldOne}", "render,
>> > enable";
>> >
>> > };
>> >
>> > SecurePanelTwo.java:
>> >
>> > public class SecurePanelTwo extends SecurePanel {
>> > public SecurePanelTwo(String id) {
>> > super(id);
>> >
>> > SecureTextFieldOne someField = new SecureTextFieldOne("someId");
>> > add(someField);
>> >
>> > }
>> >
>> > class SecureTextFieldOne extends SecureTextField {
>> > public SecureTextFieldOne(String id) {
>> > super(id);
>> > }
>> > }
>> > }
>> >
>> > In LianetApplications, all those aliases are set properly.
>> >
>> > --
>> > sp
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> sp
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
