[dancer-users] Dancer::Plugin::Auth::Extensible - possible backwards-incompatible change

[sawyer x]

If the session is able to distinguish each subroutine context, it would be
possible.
I'm not sure if it's supported.

On Tue, Dec 11, 2012 at 1:47 PM, Octavian Rasnita <orasnita at gmail.com>wrote:

> Hi,
>
> Maybe is a stupid suggestion that might not even be possible to do, but I
> think the syntax would look nicer if would be something like:
>
> get '/secret' => sub {
>    requires_login;
>    ...
> };
>
> get '/beer' => sub {
>    requires_role 'BeerDrinker';
>    ...
> };
>
> get '/beer' => sub {
>    requires_any_role [ 'BeerDrinker', 'VodkaDrinker' ];
>    ...
> };
>
> --Octavian
>
> ----- Original Message ----- From: "David Precious" <davidp at preshweb.co.uk
> >
> To: <dancer-users at dancer.pm>
> Sent: Tuesday, December 11, 2012 1:25 PM
>
> Subject: [dancer-users] Dancer::Plugin::Auth::**Extensible - possible
> backwards-incompatible change
>
>
>
>> Hi all,
>>
>> Whilst I really like the (ab)use of subroutine attributes for denoting
>> which routes require authentication/specific roles, some people (whose
>> opinions I respect) have tried to convince me that this is a Bad Idea,
>> and is likely to be fragile.
>>
>> One particularly good point made is that the current implementation
>> stores the attributes for a given route handler by the refaddr, which
>> could be problematic if run under threads (not sure if anyone really
>> does that, though).  Classes can provide a CLONE method to work around
>> this, but I don't think that'll work in this case.
>>
>> One suggestion was to provide a new keyword, e.g. requires_auth, which
>> would work something like:
>>
>>    get '/secret' => requires_login(sub { .... });
>>
>>    get '/beer'   => requires_role('BeerDrinker', sub { ... });
>>
>> (Something along those lines, at least.)  I'm certain how I would
>> implement it, though - i.e. how requires_login/requires_role would
>> store the fact that the provided sub requires auth, without the same
>> thread safety issues of using refaddr.
>>
>> Perhaps detecting the use of threads and refusing to continue would be
>> one way of dealing with it :)
>>
>> Opinions on this would be very welcome.
>>
>>
>>
>> --
>> David Precious ("bigpresh") <davidp at preshweb.co.uk>
>> http://www.preshweb.co.uk/     www.preshweb.co.uk/twitter
>> www.preshweb.co.uk/linkedin    www.preshweb.co.uk/facebook
>> www.preshweb.co.uk/cpan        www.preshweb.co.uk/github
>>
>>
>> ______________________________**_________________
>> dancer-users mailing list
>> dancer-users at dancer.pm
>> http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
>>
>
> ______________________________**_________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20121211/ad38bff9/attachment.htm>