[dancer-users] Dancer 1 or Dancer 2?

[Jacques Lareau]

That is exactly how I handle auth in all my apps. It's also shown as an
example in the cookbook. Not sure why it's naive.

On Wed, Sep 17, 2014 at 1:29 PM, Mike South <msouth at gmail.com> wrote:

>
>
> On Fri, Sep 12, 2014 at 8:56 AM, Sawyer X <xsawyerx at gmail.com> wrote:
>
>> On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) <
>> racke at linuxia.de> wrote:
>>
>>> On 09/12/2014 02:35 PM, Sawyer X wrote:
>>> > Unfortunately that is a terrible example. The concept of blocking all
>>> requests in a before() hook is... let's say, naive. In reality you would
>>> like to simply block specific requests according to session, a la David
>>> Golden's Auth::Tiny.
>>>
>> [Disclaimer:  I have only ever used Dancer1.  I lurk here specifically so
> that I will know when things are stable enough to start building new stuff
> in Dancer2.  Please pardon my ignorance or just press delete.]
>
> What do you mean by "in reality you would like to simply block specific
> requests according to session"?
>
> I have live code being used in a mission critical and highly sensitive
> project with a before hook (approximately) like this:
>
> hook before => sub {
>     #whitelist /ip route as not needing any auth check
>     return if (request->path_info =~ m{(^/ip$)|});
>
>     my $user =
> Dancer::Plugin::Auth::Extensible::Provider::Redacted->ip_login();
>
>     var user => $user;
>
>     $user or die "no user";
> };
>
> This is very clean design; anyone adding a new route (and the nature of
> the project and team were such that this was happening without me really
> being able to oversee it, and contributions were being made by Dancer
> novices) could not accidentally make that route available without
> authentication.  If they needed an un-authenticated route, they would have
> to go through the before hook.
>
> I'm not sure I'm understanding what you're talking about here (I don't
> know what a "route check" is, for example), but it sounds to me like
> Dancer2 removes this capability?
>
> >
>>> > The before hooks are basically run on every request. Static files are
>>> now served through the File handler. That means it will trigger the before
>>> hooks because it's a normal request.
>>> > I would love to do it using the Static middleware, but then it will
>>> happen before a route check on it, so we can't have that.
>>>
>>> I still disagree with this change of behaviour from Dancer 1 to Dancer
>>> 2. What is the benefit of calling before hook for public files?
>>> Also in a production environment you might deliver static files with
>>> some other software (Nginx, ...) and you loose control on
>>> these public files anyway.
>>>
>>
>>
>> The point is that this is not a selection of behavior. It isn't "we want
>> a before hook on public files", but "because public files are serves as a
>> handler, they will have before hooks called too". It's implicit behavior
>> because of the restructuring of public files as file handlers.
>>
>
> I suppose I could do the same as I have above but put in an exception in
> my before hook allowing through public files--would that be feasible in the
> new architecture?
>
> Rather than considering the cited example naive, I kind of think it's
> naive to think you _wouldn't_ have applications where everything served by
> code is locked down, and all static files are unrestricted.
>
> I would think you really want to have the option of having static files
> served with as little intervention by code as possible.
>
> mike
>
> _______________________________________________
> 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/20140917/2cff822d/attachment.html>