Users API help

Bryan Kearney bkearney at redhat.com
Mon May 16 19:03:56 UTC 2011


On 05/16/2011 02:28 PM, Justin Harris wrote:
>
>
> ----- Original Message -----
>> On 05/16/2011 02:15 PM, Justin Harris wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 05/16/2011 02:08 PM, Justin Harris wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> On 05/16/2011 01:57 PM, Justin Harris wrote:
>>>>>>> Hey gang,
>>>>>>>       So for this multi-owner stuff, we probably need to change
>>>>>>>       how
>>>>>>>       users are created, then associated with an owner.
>>>>>>>       Currently,
>>>>>>>       the
>>>>>>>       client will POST to /owners/<id>/users to create a new user
>>>>>>>       under
>>>>>>>       that owner. We could keep this the same, but that will
>>>>>>>       likely
>>>>>>>       involve a lot of semi-magic logic where we check if that
>>>>>>>       user
>>>>>>>       is
>>>>>>>       already in the database and either update or create them.
>>>>>>>       Alternatively, we could move the user creation to POST
>>>>>>>       /users
>>>>>>>       and
>>>>>>>       then require a second call to associate a user with an
>>>>>>>       owner
>>>>>>>       (and
>>>>>>>       subsequent calls when adding more than one owner). The
>>>>>>>       super
>>>>>>>       RESTy approach would be to create a /membership resource to
>>>>>>>       manage this, which would be fine to implement. All this
>>>>>>>       does
>>>>>>>       mean
>>>>>>>       that we break the api for user creation, though I'm not
>>>>>>>       sure
>>>>>>>       how
>>>>>>>       heavily we are using this outside of our functional tests.
>>>>>>>       Does
>>>>>>>       anyone have an opinion on this either way?
>>>>>>
>>>>>> So.. not to throw scope creep into this (But I will) :)
>>>>>>
>>>>>> Do we want a simple RBAC for hosted? So.. a user could have a
>>>>>> role
>>>>>> in
>>>>>> an
>>>>>> org? That is basically your membership concept, but with some
>>>>>> enhance
>>>>>> functionality around it. We could go whole hog on RBAC.. but
>>>>>> since
>>>>>> it
>>>>>> is
>>>>>> a free product..we may not want to.
>>>>>>
>>>>>> SUPER_ADMIN would be a bit different.. since it would have no
>>>>>> target
>>>>>> owner. But you get the idea.
>>>>>>
>>>>>> -- bk
>>>>>
>>>>> Well, to push back on your scope creep somewhat, we could leave
>>>>> all
>>>>> that out but
>>>>> still introduce the membership model (basically as a join between
>>>>> owner and user)
>>>>> which sets us up to go in that direction in the future?
>>>>>
>>>>>     - Justin
>>>>>
>>>> so.. to be clear...
>>>>
>>>> 1. you would remove the owner attribute on the user, but keep the
>>>> super
>>>> user one.
>>>> 1. you would create an instance of membership which joins owner and
>>>> user. And the assumption is that the users is a super-admin.
>>>>
>>>> Is that correct? It would not surprise me if we would need a
>>>> "Normal"
>>>> user or read only. Which is why I like the Role model... but as you
>>>> said.. it is a step in the right direction.
>>>>
>>>> -- bk
>>>
>>> Yes, I think that is the general idea - we can then add roles to the
>>> membership as a later story
>>> if we want to go in that direction. This way a user can be e.g. and
>>> admin for one owner and a
>>> basic user for another owner.
>>
>> hmm.. membership sounds soooo much like a role :)
>>
>> -- bk
>
> Maybe this is just a difference in semantics, then.  I was thinking a role is, for example, admin.  A membership
> would be a combination of a user, role, and owner.  Maybe my working definition of a role is really a role type?
well.. today we have a role of SUPER_ADMIN which is really a collection 
of permissions on the assume parent owner.

If we move the word "SUPER_ADMIN" to the membership.. then that 
membership becomes really a set of permissions.

-- bk




More information about the candlepin mailing list