[dancer-users] Dancer 1 or Dancer 2?

[Mike South]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20140917/a703f8ed/attachment.html>