[
https://issues.apache.org/jira/browse/NIFI-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291004#comment-15291004
]
ASF GitHub Bot commented on NIFI-1884:
--------------------------------------
Github user mcgilman commented on the pull request:
https://github.com/apache/nifi/pull/452#issuecomment-220307255
@alopresto Thanks for the very thorough review! This API is designed
strictly for handling the persistence of access policies which would also
include Users and Groups. These objects are designed as simple data objects or
POJOs. While the MutableAuthorizer can load these records, it must be told when
to save. It wouldn't know a given User/Group/Policy has been modified. This is
part of the motivation to have the objects be immutable. The intent is very
clear to an implementor of MutableAuthorizer that the objects won't be modified
outside of their knowing. I believe that @bbende recommendation of introducing
a Builder for creating new versions of a given User/Group/Policy is a great way
to handle the cloning.
The end goal here was to design the API such that the implementation only
needed to be concerned with persistence.
**uniqueness constraint** - How we address this would ultimately be based
on whether we support reloading the Users/Groups/Policies while the application
is running. We decided against this as the motivation for the MutableAuthorizer
API was to support an Authorizer that was managed by NiFi. With this approach
we would be enforcing uniqueness at startup and when new records were added
outside of the MutableAuthorizer.
**ID mutability** - The identifier of a record is not mutable. The identity
of a user and name of a group are (using the clone/builder approach described).
This is to more easily support name chanes or typos without having to re-create
all the policies for that entity as well.
**locks & merge conflicts** - Thread locking is handled by the web tier
using the same mechanism as the other Resources. For 1.0.0 we are introducing
fine grain locking through a RevisionManager. Obtaining a write lock for a
given record would require a client to include a Revision. The RevisionManager
manager would validate the Revision and lock the Revision to prevent other
clients from modifying the same record.
> Add User & Group API
> --------------------
>
> Key: NIFI-1884
> URL: https://issues.apache.org/jira/browse/NIFI-1884
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Priority: Minor
> Fix For: 1.0.0
>
>
> Define the API for managing users, groups, and policies.
> This is to advance the work described in this feature proposal:
> https://cwiki.apache.org/confluence/display/NIFI/Support+Authorizer+API
> The parent JIRA for all authorization work is NIFI-1550.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
