nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (NIFI-1884) Add User & Group API
Date Thu, 19 May 2016 12:18:12 GMT


ASF GitHub Bot commented on NIFI-1884:

Github user mcgilman commented on the pull request:
    @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:
>             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:
> The parent JIRA for all authorization work is NIFI-1550.

This message was sent by Atlassian JIRA

View raw message