Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Fine-grained access control with REST

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


moseley at hank

Apr 12, 2011, 11:29 AM

Post #1 of 2 (321 views)
Permalink
Fine-grained access control with REST

In our aging Music application where we have the familiar hierarchy Label ->
CD -> Track -> Note. We also have an extra table for access control that
joins CDs with a User: cd_user. The action "PUT /note/*" is allowed if the
Note object can be joined to the current user via the cd_user table.

Now we want to extend this to have fine-grained access control. So, we
might have roles "owner" with full read/write access, "reader" with only
read access, and "editor" with read/write access but can only update a
subset of a Note's columns compared to the "owner".

Essentially, the "owner" and "editor" can both PUT a Note object but the
action would use different forms to validate the request and update the
database.

So, my question is what makes for a good URL scheme? One option is to use
"PUT /note/123" and before updating determine the type of access and select
that correct form object. So, both editors and and owners PUT to the same
URL but supplying different columns to update.

Another option is separate URLs such as "PUT /owner/note/123" and "PUT
/editor/note/123" making it very explicit.

What's your opinion about these options? Is there a better approach?


I suppose it's not always a boolean access question: a given user might
have multiple roles and may wish to pick which role to act as using
different URLs.


--
Bill Moseley
moseley [at] hank


kyle.m.hall at gmail

Apr 13, 2011, 2:29 AM

Post #2 of 2 (308 views)
Permalink
Re: Fine-grained access control with REST [In reply to]

I would use the same URL for everyone, just use http basic access
authentication to send the users credentials and if the user does not
have the correct privileges just send back a 401 Unauthorized or
perhaps a 403 Forbidden. Let the client side handle the rest.

Kyle

http://www.kylehall.info
Mill Run Technology Solutions ( http://millruntech.com )
Crawford County Federated Library System ( http://www.ccfls.org )
Meadville Public Library ( http://www.meadvillelibrary.org )




On Tue, Apr 12, 2011 at 2:29 PM, Bill Moseley <moseley [at] hank> wrote:
> In our aging Music application where we have the familiar hierarchy Label ->
> CD -> Track -> Note.  We also have an extra table for access control that
> joins CDs with a User: cd_user.  The action "PUT /note/*" is allowed if the
> Note object can be joined to the current user via the cd_user table.
> Now we want to extend this to have fine-grained access control.  So, we
> might have roles "owner" with full read/write access, "reader" with only
> read access, and "editor" with read/write access but can only update a
> subset of a Note's columns compared to the "owner".
> Essentially, the "owner" and "editor" can both PUT a Note object but the
> action would use different forms to validate the request and update the
> database.
> So, my question is what makes for a good URL scheme?  One option is to use
> "PUT /note/123" and before updating determine the type of access and select
> that correct form object.  So, both editors and and owners PUT to the same
> URL but supplying different columns to update.
> Another option is separate URLs such as "PUT /owner/note/123" and "PUT
> /editor/note/123" making it very explicit.
> What's your opinion about these options?  Is there a better approach?
>
> I suppose it's not always a boolean access question:  a given user might
> have multiple roles and may wish to pick which role to act as using
> different URLs.
>
> --
> Bill Moseley
> moseley [at] hank
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.