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?
Thanks, - Justin
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
----- 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
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
----- 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...
- you would remove the owner attribute on the user, but keep the
super user one.
- 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.
- Justin
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...
- you would remove the owner attribute on the user, but keep the
super user one.
- 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
----- 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...
- you would remove the owner attribute on the user, but keep the
super user one.
- 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?
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?
- Justinso.. to be clear...
- you would remove the owner attribute on the user, but keep the
super user one.
- 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
Just to throw a wrench into things, is it possible to POST /users and in the JSON, define the owners to associate with? (similar to how we were talking about setting the owner on a consumer, only with multiple instead of just one in this case)
On Mon, May 16, 2011 at 4:03 PM, Bryan Kearney bkearney@redhat.com wrote:
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...
- you would remove the owner attribute on the user, but keep the
super user one.
- 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
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 05/16/2011 02:06 PM, Bryan Kearney wrote:
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.
Or integrate into FreeIPA! We do Role and Host based access controls already.
SUPER_ADMIN would be a bit different.. since it would have no target owner. But you get the idea. -- bk
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On Mon, May 16, 2011 at 1:57 PM, Justin Harris jharris@redhat.com 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?
At first glance I prefer:
POST /users to create the user PUT /owners/{id}/users/ to add the user to an owner
and maybe a PUT to roles if need be.
jesus
----- Original Message -----
On Mon, May 16, 2011 at 1:57 PM, Justin Harris < jharris@redhat.com > 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?
At first glance I prefer:
POST /users to create the user PUT /owners/{id}/users/ to add the user to an owner
This last one would equate to "replace the users collection with what I am providing" which doesn't seem like what we are trying to do here.
and maybe a PUT to roles if need be.
jesus _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin@lists.stg.fedorahosted.org
-
Adam Young -
Bryan Kearney -
Devan Goodwin -
Jesus M. Rodriguez -
Justin Harris