Mailing List Archive: Catalyst: Users

"Dynamic" authorization

Index | Next | Previous | View Threaded

gunnarstrand at yahoo

Jul 9, 2009, 1:13 AM

Post #1 of 3 (438 views)
Permalink

"Dynamic" authorization

Hi,

Most of the authorization schemes appear to aim to allow authorization
based on "type", so that a certain group of users are allowed to CRUD a
specific type of resource, eg. Albums or Artists etc. If a user has
access to "albums/update" then the user can change any album. I have
looked at the two available plugins for authorization, ACL and Roles,
and both seem to support this scheme.

I would like to have authorization per individual resource. A comparable
example would be a member only being allowed to update her own member
information. If I would implement something like this, I think I'd add a
table to the database for handling authorization:

Role Resource

administrators members
administrators blogs
user1 members/update/1
user2 members/update/15
user1 blogs/update/3
user2 blogs/update/13

The table would then be consulted whenever a resource is accessed, and
the lookup would be put in a central place, if possible. I've
implemented a ":Restricted" action which handles authentication, and
that is where I would try to add the authorization as well. One of the
tricky things would be to have a generic way to create the resource
identifier from request input.

Does anyone know if this be implemented using ACL or Roles, and what are
the principles for doing so?

If not, what is your experience in solving this problem?

KR,
Gunnar

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

bobtfish at bobtfish

Jul 9, 2009, 5:50 AM

Post #2 of 3 (390 views)
Permalink

Re: "Dynamic" authorization [In reply to]

Gunnar Strand wrote:
> The table would then be consulted whenever a resource is accessed, and
> the lookup would be put in a central place, if possible. I've
> implemented a ":Restricted" action which handles authentication, and
> that is where I would try to add the authorization as well. One of the
> tricky things would be to have a generic way to create the resource
> identifier from request input.

I think that for the complexity of what you're doing with auth, then the
authorization should be in the model layer.

You should have methods on the model layer which take some form of
'user', and restrict what can be retrieved by that user. This is domain
logic, so you need to build it into the domain.

> Does anyone know if this be implemented using ACL or Roles, and what are
> the principles for doing so?
>
> If not, what is your experience in solving this problem?

DBIx::Class::Schema::RestrictWithObject is probably the place to start
looking.

Cheers
t0m

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

gunnarstrand at yahoo

Jul 9, 2009, 11:12 AM

Post #3 of 3 (382 views)
Permalink

Re: "Dynamic" authorization [In reply to]

Tomas Doran skrev:
> Gunnar Strand wrote:
>> The table would then be consulted whenever a resource is accessed,
>> and the lookup would be put in a central place, if possible. I've
>> implemented a ":Restricted" action which handles authentication, and
>> that is where I would try to add the authorization as well. One of
>> the tricky things would be to have a generic way to create the
>> resource identifier from request input.
>
> I think that for the complexity of what you're doing with auth, then
> the authorization should be in the model layer.
>
> You should have methods on the model layer which take some form of
> 'user', and restrict what can be retrieved by that user. This is
> domain logic, so you need to build it into the domain.
Thanks, Tom. You are of course correct. Moving authorization to the data
model will make it harder to show only authorized functions in the
presentation layer, though. I'll have to think about this, but it seems
that it is a fairly early design decision if the authorization should be
in the control- or model part. And perhaps using ACL or groups will suffice.

KR,
Gunnar

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com