Is this for Authentication only or also for Authorisation?

[VinceW]

First, tnx for the module. Nice work.

I noticed in the description of the module this module is an: "Authentication framework for Dancer-based web applications"

Currently the module provides more functionality then Authentication alone. It also provides some functionality in the Authorisation spectrum (for instance user_has_role).

Is this combination intended?

One of the reasons for my question is because I would like to see more authorisation functionality (such as: can_user('Edit this form) etc, but currently I am in doubt where to put this functionality.

As seen from an architectural point of view there is a difference between Authentication and Authorisation (see also: http://en.wikipedia.org/wiki/AAA_protocol).

This module could be extended with this extra functionality (willing to contribute to it) but isn't this going to be cluttered up to much?

[bigpresh]

Yes, it provides authorisation too, via roles. The idea being that you'd define roles required to perform specific actions. It will handle checking whether you're able to access a route based on the roles it requires and the roles it has; if you need to check things in your code, as you say it provides user_has_role too.

As I see it, that provides what you need to perform authorisation as well as authentication?

[VinceW]

thanks for your explanation about authentication and authorisation.

However, this still leaves me with 'authorisation' question: I mean a user can have a role of "BeerDrinker" but I don't always want to check on the role, but sometimes on the (CRUD) action one can perform.

Is there a way (with this module or another) to have somewhere in my code the check: can_user('Edit this form' )

[bigpresh]

Is there a way (with this module or another) to have somewhere in my code the check: can_user('Edit this form' )

Not currently; I didn't think that would be too useful as I use roles for everything.

However, I guess the module could provide a way to see if a user would be able to execute a given route, given the method and the URL to it, if the authentication wrappers (e.g. require_role) added each 'protected' route to a registry containing the route definition (method and URL) and the roles required so that a user_can_access_route(method => url) keyword could consult that and return true or false, so you could say things like:

if (user_can_access_route( DELETE => '/user/:user_id' )) {
    # OK, the current user can delete other users, offer them that option
}

In your examples you keep using free-text descriptions (e.g. 'Edit this form'), though - where would they come from? I'm a little puzzled as to how that would work.

[VinceW]

To start with the latter .... they are coming from a drupal background where content type specific CRUD can be applied.

I mean various roles can have access to a form, but sometimes it's needed to make a distinction if a user can edit some content, or has the rights to see some additional content.

However it's also possible (perhaps even likely) that I don't have a good understanding of the route implementation within dancer, and thus this modules authorization. If this is the case, please say so, and I'll have to do some homework.

[racke]

On 09/20/2013 04:23 PM, VinceW wrote:

To start with the latter .... they are coming from a drupal background where content type specific CRUD can be applied.

I mean various roles can have access to a form, but sometimes it's needed to make a distinction if a user can edit some content, or has the rights to see some additional content.

However it's also possible (perhaps even likely) that I don't have a good understanding of the route implementation within dancer, and thus this modules authorization. If this is the case, please say so, and I'll have to do some homework.

I would love to have the "permissions" feature supported by DPAE, which controls access by permission, in additional
to control access by role.

A permission can be granted to roles / users.

Regards
Racke

LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team

[bigpresh]

At the moment I'm not clear on exaclty what's wanted here or how it'd be implemented, beyond my suggestion of a way to check if a user could execute a given route, so I'm not sure where this ticket is going. As I see it, a "permission" is something you get by having a role. For instance, if you have defined a route delete '/user/:user_id' => require_role 'Annihilator' => sub { ...}, then you get permission to execute that route if you have the Annihilator role - but checking for that permission is as simple as calling user_has_role('Annihilator').

Per-user permissions may be useful, possibly, but also tend to lead to a messy morass of special exceptions and no clear view of who can do what, IMO.

[racke]

OK, I agree about the per-user permissions. However the difference between roles and permissions is that multiple roles can have the same permission.

[bigpresh]

As I see it, the roles implementation is clear and simple; I don't really see the value of an additional abstraction above that particularly - but I suppose I can see the value of a simple "Could the user execute $method $role" feature, if that's desired.

So - if I implemented a keyword that checks if a user can access a given route with a given method, e.g. user_can_access_route( DELETE => '/user/:user_id' ), would that be useful?

That way, the route definition could allow various roles to access it, and you don't need to care which roles the user has if all you want to know is "do they have one of the roles that gives them permission to execute that route?".

[bigpresh]

I've raised #56 for the implementation of a user_can_access_route() keyword, so I'm going to close this ticket now. (Sorry it sat for so long!)