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

[Daniel Perrett]

Perhaps I'm missing something but...

"how requires_login/requires_role would store the fact that the provided 
sub requires auth"

Simple implementation:

# given has_role is calculable 

sub requires_role { 
        my ($role, $code, $handle_exception) = @_;
        return sub {
                if (has_role($role)){
                        $code->(@_);
                }
                else{
                        if (defined $handle_exception){
                                $handle_exception->($role, @_)
                        }
                        else {
                                default_403_no_role($role, @_)
                        }
                }
        }
}

Complex implementation:

requires_login and requires_role return objects which have metadata about 
their requirements and exception handling which can be changed easily, but 
that overload as coderefs to something like the code above.




From:   David Precious <davidp at preshweb.co.uk>
To:     dancer-users at dancer.pm
Date:   11/12/2012 11:25
Subject:        [dancer-users] Dancer::Plugin::Auth::Extensible - possible 
backwards-incompatible change
Sent by:        dancer-users-bounces at dancer.pm




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20121211/842060cf/attachment.htm>