2010-06-21 16:30, Marius Dumitru Florea skrev:
> Hi Andreas,
>
> On 06/21/2010 05:00 PM, Andreas Jonsson wrote:
>
>> I will make two proposals for changing the RightService API:
>>
>> The first does not actually change any code, but it is a preparation
>> for future changes. I want to be sure that the methods checkAccess
>> and hasAccessLevel aren't used interchangeably; it should be well
>> defined when to use one or the other.
>>
>> The second proposal is a complete rework of the API, which might be a
>> bit further into the future.
>>
>> 1. Change the semantics of hasAccessLevel slightly.
>>
>> Currently the method hasAccessLevel is defined as:
>> /**
>> * Verifies if the user identified by {...@code username} has the
>> * access level identified by {...@code right} on the document with
>> * the name {...@code docname}.
>>
>> I would like to make a change the describing text into:
>>
>> /**
>> * Decides whether the access level given by {...@code right} should
>> * be granted during rendering of the document identified by
>> * {...@code docname} by request of the user identified by {...@code
>> * username}.
>>
>> In other words, the rights queried for is tied to the thread
>> executing a request on behalf of the user. In contrast, the
>> checkAccess method queries for the configured rights of a
>> particular user.
>>
>> This suggests that the underlying implementation may choose to base
>> its decision on more things than the given user and document, and
>> thus opens up for more possibilities to change the security policy.
>>
>> For instance,
>>
>> hasAccessLevel("programming", context.getUser(), docname, context)
>>
>> could be made equivalent to
>>
>> hasProgrammingRights(context.getWiki().getDocument(docname), context)
>>
>> In the current implementation, XWikiRightServiceImpl, the methods
>> checkAccess and hasAccessLevel can be used interchangeably once the
>> user have been authenticated. But it seems that the current usage
>> pattern more or less matches the above change in semantics already.
>>
>> 2. Deprecate all methods in the current API and introduce the following
>> new ones:
>>
>> boolean checkAccess(String action, EntityReference entity);
>>
>> boolean userHasRight(DocumentReference userIdentity, Right right,
>> EntityReference entity);
>>
>> boolean hasAccessLevel(Right right);
>>
>> Iterable<Right> getEnabledRights(EntityType entityType);
>>
>> The differences are:
>>
>> 1. The context parameter is dropped. The right service can have
>> an Execution instance injected instead.
>>
>> 2. No exceptions are thrown. Instead, on error, log and deny access.
>>
>> 3. Identify users by the DocumentReference of their profile page.
>>
>>
>
>> 4. Introduction of the enum 'Right'.
>>
> During the discussion for the new Rights Management UI the idea that the
> rights system should be extensible emerged (i.e. components should be
> able to define new rights). Using a 'Right' enum doesn't cope well with
> that.
>
>
In that case I propose adding these methods to the RightService API:
Right registerRight(RightDescription rightDescription) throws
UnableToRegisterRightException;
Right getRight(String name);
Where we have:
public interface RightDescription {
/**
* @return Additional rights implied by this right.
*/
Iterable<Right> getImpliedRights();
/**
* @return The levels in the document hierarchy where this right
* should be enabled.
*/
Iterable<EntityType> getDocumentLevels();
/**
* @return Policy on how this right should be inherited from
* higher levels in the document hierarchy.
*/
InheritancePolicy getInheritancePolicy();
/**
* @return Whether this right should be allowed or denied in case
* of a tie.
*/
TieResolutionPolicy getTieResolutionPolicy();
/**
* @return The default value, in case no matching right is found
* at any level.
*/
RightState getDefaultValue();
/**
* @return The string representation of this right.
*/
String getName();
}
enum InheritancePolicy { HIGHER_LEVEL_WINS, LOWER_LEVEL_WINS };
enum TieResolutionPolicy { DENY_WINS, ALLOW_WINS };
enum RightState { DENY, ALLOW }
Best regards,
Andreas Jonsson
> Thanks,
> Marius
>
>
>> 5. The rights are controlled against entities identified by
>> EntityReferences that may be of type WIKI, SPACE or DOCUMENT.
>>
>> 6. Add a new method, userHasRight, for querying for the specific
>> rights of a given user on a given entity, where the entity may
>> be wiki, space or document. This method replaces the method
>> hasAdminRights. I guess this method will be primarily used by
>> the user interface.
>>
>> 7. hasAccessLevel have the same change in semantics as mentioned
>> above, and could thus replace the hasProgrammingRights
>> methods. In other words, hasAccessLevel provides the answer
>> to the question "should access for an operation that requires
>> the specified right be granted given the current context?"
>>
>> Within the lifecycle of a request, first a call should be made
>> to checkAccess to authenticate the user and to grant access to
>> the specific action. Subsequent security checkpoinst should
>> normally use hasAccessLevel.
>>
>> 8. The listAllLevels-method is moved to the Right enum class.
>> The right service could instead provide a method that lists
>> what rights are enabled at a particular level in the document
>> hierarchy, i.e., the getEnabledRights method, which I guess is
>> relevant for the rights manager.
>>
>>
>> So, what do you think?
>>
>>
>> Best regards,
>>
>> Andreas Jonsson
>>
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
