On Wed, Jun 8, 2011 at 11:57 AM, Bryan Kearney <bkearney(a)redhat.com> wrote:
On 06/08/2011 10:49 AM, James Bowes wrote:
> On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
>> On Wed, Jun 8, 2011 at 11:33 AM, James Bowes<jbowes(a)redhat.com> wrote:
>>> On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
>>>> Here is my current plan for refactoring and modelling the role to user
>>>> and role to permission relationships as resources themselves.
>>>>
>>>> - Create a role with POST /roles (json blob containing not much more
>>>> than a name) Calls UserServiceAdapter.createRole which returns a role
>>>> with a unique ID.
>>>>
>>>> - Add a user to a role: POST /memberships with JSON containing just a
>>>> username and a role ID. Calls UserServiceAdapter.createMembership()
>>>> and returns a membership with a unique ID.
>>>>
>>>> - Delete a user from a role: DEL /memberships/membershipid. Calls
>>>> UserServiceAdapter.deleteMembership().
>>>
>>> Why isn't role memebership just a list of role ids hanging off a user?
>>
>> Rails tends to try to represent this type of membership as an actual
>> resource with it's own distinct ID. Up until yesterday it was just a
>> straight Role-User relationship and created/updated by posting JSON
>> blobs with the users in it. As Justin pointed out this implies the
>> caller has to know the full set of users before it can change
>> anything, and introduces problems with race conditions. We can go back
>> to straight Role-User and perhaps do something like POST
>> /roles/id/users/username or DEL /roles/id/username to update the set.
>> However current path was to treat the relationship like an actual
>> resource. Should we revert to direct ManyToMany from Role to User?
>>
>
> If there's a reasoning behind it, then that's cool. Perhaps for next rev
> of the API we can update the other resources to match.
>
If we have the model where a Role == an ldap group.. then it is Many to
Many.
-- bk
Yeah it's just a question if it's Role ManyToMany with User, or Role
OneToMany with an intermediate Membership object (which is just a Role
and a User), but in both cases roles have many users and users have
many roles.
Something else to remember with this, the roles are almost irrelevant
to our application, it's basically an implementation detail that I
suspect could be hidden behind the user service. All we really care
about in Candlepin is ending up with a principal that has permissions.
The roles are just how we get *some* of those permissions if you
authenticate as a user and are using our default user service.
The LDAP user service can do whatever it wants behind the scenes, it
just needs to get us a principal with the right permissions. If we
keep these role/membership/permission methods on the user service
adapter interface, the LDAP user service is going to just be throwing
not implemented exceptions for them all. Possible in the future we'll
want to take these off the user service interface.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca