You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by qMax <qm...@mediasoft.ru> on 2005/04/15 11:49:10 UTC

why there are build-in semantic of roles ?

Another weird thing about roles:
what is a reason to have roles with built-in semantic:
URLPolicy.getVisitRole(AccreditableManager)
URLPolicy.getAdministratorRole(AccreditableManager)
URLPolicy.getAuthorRole(AccreditableManager)
Thus, some code relies on that there are at least 3 roles with
("visitor", "visit"),("administrator", "admin", "organize"),("author",
"edit");

This should be at least explained in docs for how such roles would be
used internally, and what will happen if publication missed some of
such roles.

-- 
 qMax


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re[2]: why there are build-in semantic of roles ?

Posted by qMax <qm...@mediasoft.ru>.
Monday, April 18, 2005, 2:46:08 PM, andreas@apache.org wrote:

AH> qMax wrote:
>> Monday, April 18, 2005, 2:20:31 PM, andreas@apache.org wrote:
>> 
>>>>URLPolicy.getVisitorRole() is used in URLPolicy itself,
>>>>when there no roles could be get from Identity.
>>>>
>>>>Since accreditable World is added to any Identity,
>>>>such situation could happen only when there's no policy for World
>>>>defined.
>>>>I'd consider this as policy misconfiguration.
>> 
>> 
>> AH> I don't understand. Why is it a misconfiguration when no policy
>> AH> for "world" is defined?
>> 
>> Well, i mean - it is misconfiguration, if in some situation there no
>> roles defined at all.
>> At least there should be one role 'visit' for World,
>> unless i intentionally want to prevent world to visit something.

AH> And that would be the case for protected areas, where only certain
AH> users/groups should be able to visit the pages. I agree that it is
AH> strange to have an "inaccessible area" (which means there is no
AH> policy at all), but does this endanger the system integrity?
In my humble opinion - this endanger security.
If i forgot to set up permissions or set them bogus,
any access should be rather denied.

(Think of confidential info on protected site areas.)

-- 
 qMax


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why there are build-in semantic of roles ?

Posted by Andreas Hartmann <an...@apache.org>.
qMax wrote:
> Monday, April 18, 2005, 2:20:31 PM, andreas@apache.org wrote:
> 
>>>URLPolicy.getVisitorRole() is used in URLPolicy itself,
>>>when there no roles could be get from Identity.
>>>
>>>Since accreditable World is added to any Identity,
>>>such situation could happen only when there's no policy for World
>>>defined.
>>>I'd consider this as policy misconfiguration.
> 
> 
> AH> I don't understand. Why is it a misconfiguration when no policy
> AH> for "world" is defined?
> 
> Well, i mean - it is misconfiguration, if in some situation there no
> roles defined at all.
> At least there should be one role 'visit' for World,
> unless i intentionally want to prevent world to visit something.

And that would be the case for protected areas, where only certain
users/groups should be able to visit the pages. I agree that it is
strange to have an "inaccessible area" (which means there is no
policy at all), but does this endanger the system integrity?

-- Andreas


> Currently, URLPolicy provides "default" role.
> Does it makes a sence ?
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re[2]: why there are build-in semantic of roles ?

Posted by qMax <qm...@mediasoft.ru>.
Monday, April 18, 2005, 2:20:31 PM, andreas@apache.org wrote:
>> URLPolicy.getVisitorRole() is used in URLPolicy itself,
>> when there no roles could be get from Identity.
>> 
>> Since accreditable World is added to any Identity,
>> such situation could happen only when there's no policy for World
>> defined.
>> I'd consider this as policy misconfiguration.

AH> I don't understand. Why is it a misconfiguration when no policy
AH> for "world" is defined?

Well, i mean - it is misconfiguration, if in some situation there no
roles defined at all.
At least there should be one role 'visit' for World,
unless i intentionally want to prevent world to visit something.

Currently, URLPolicy provides "default" role.
Does it makes a sence ?

-- 
 qMax


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why there are build-in semantic of roles ?

Posted by Andreas Hartmann <an...@apache.org>.
qMax wrote:
> Friday, April 15, 2005, 7:06:46 PM, andreas@apache.org wrote:
> 
> AH> qMax wrote:
> 
>>>Another weird thing about roles:
>>>what is a reason to have roles with built-in semantic:
>>>URLPolicy.getVisitRole(AccreditableManager)
>>>URLPolicy.getAdministratorRole(AccreditableManager)
>>>URLPolicy.getAuthorRole(AccreditableManager)
>>>Thus, some code relies on that there are at least 3 roles with
>>>("visitor", "visit"),("administrator", "admin", "organize"),("author",
>>>"edit");
> 
> 
> AH> You're right. It would be great to get rid of these pre-defined
> AH> roles. Do you see a way how this could be managed?
> 
> According to grep(1):
> 
> URLPolicy.getVisitorRole() is used in URLPolicy itself,
> when there no roles could be get from Identity.
> 
> Since accreditable World is added to any Identity,
> such situation could happen only when there's no policy for World
> defined.
> I'd consider this as policy misconfiguration.

I don't understand. Why is it a misconfiguration when no policy
for "world" is defined?

-- Andreas

> Seems liek this code also avoids possibility to prevent
> 'world'(unauthenticated users) from visiting some site areas.
> In this case it's rather Bug.
> 
> /* BTW, if to grant other policy to World, egg "editor", all editors
> will fail because "no user name". But this is rather Feature. */
> 
> URLPolicy.getAuthorRole() is used to grant acces to users to edit
> their own profiles, when AccreditableAdded/Removed.
> That is, for files /admin/users/$user.html
> 
> 
> I guess granting access to newly created documents should be performed
> by tasks, and it can be usefull for other files, not only user
> profiles
> 
> URLPolicy.getAdministratorRole() is not used anywhere.
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


addon Re[3]: why there are build-in semantic of roles ?

Posted by qMax <qm...@mediasoft.ru>.
q> I guess granting access to newly created documents should be performed
q> by tasks, and it can be usefull for other files, not only user
q> profiles
I meant, in this case the "author" role can be configured somwhere in
tasks.
(but i dont know about tasks well)

-- 
 qMax


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re[2]: why there are build-in semantic of roles ?

Posted by qMax <qm...@mediasoft.ru>.
Friday, April 15, 2005, 7:06:46 PM, andreas@apache.org wrote:

AH> qMax wrote:
>> Another weird thing about roles:
>> what is a reason to have roles with built-in semantic:
>> URLPolicy.getVisitRole(AccreditableManager)
>> URLPolicy.getAdministratorRole(AccreditableManager)
>> URLPolicy.getAuthorRole(AccreditableManager)
>> Thus, some code relies on that there are at least 3 roles with
>> ("visitor", "visit"),("administrator", "admin", "organize"),("author",
>> "edit");

AH> You're right. It would be great to get rid of these pre-defined
AH> roles. Do you see a way how this could be managed?

According to grep(1):

URLPolicy.getVisitorRole() is used in URLPolicy itself,
when there no roles could be get from Identity.

Since accreditable World is added to any Identity,
such situation could happen only when there's no policy for World
defined.
I'd consider this as policy misconfiguration.
Seems liek this code also avoids possibility to prevent
'world'(unauthenticated users) from visiting some site areas.
In this case it's rather Bug.

/* BTW, if to grant other policy to World, egg "editor", all editors
will fail because "no user name". But this is rather Feature. */

URLPolicy.getAuthorRole() is used to grant acces to users to edit
their own profiles, when AccreditableAdded/Removed.
That is, for files /admin/users/$user.html


I guess granting access to newly created documents should be performed
by tasks, and it can be usefull for other files, not only user
profiles

URLPolicy.getAdministratorRole() is not used anywhere.



-- 
 qMax


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why there are build-in semantic of roles ?

Posted by Andreas Hartmann <an...@apache.org>.
qMax wrote:
> Another weird thing about roles:
> what is a reason to have roles with built-in semantic:
> URLPolicy.getVisitRole(AccreditableManager)
> URLPolicy.getAdministratorRole(AccreditableManager)
> URLPolicy.getAuthorRole(AccreditableManager)
> Thus, some code relies on that there are at least 3 roles with
> ("visitor", "visit"),("administrator", "admin", "organize"),("author",
> "edit");
> 
> This should be at least explained in docs for how such roles would be
> used internally, and what will happen if publication missed some of
> such roles.

You're right. It would be great to get rid of these pre-defined
roles. Do you see a way how this could be managed?

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org