<div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 1:29 PM, Mike South <span dir="ltr"><<a href="mailto:msouth@gmail.com" target="_blank">msouth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Sep 12, 2014 at 8:56 AM, Sawyer X <span dir="ltr"><<a href="mailto:xsawyerx@gmail.com" target="_blank">xsawyerx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) <span dir="ltr"><<a href="mailto:racke@linuxia.de" target="_blank">racke@linuxia.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 09/12/2014 02:35 PM, Sawyer X wrote:<br>
> 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.<br></span></blockquote></span></div></div></div></blockquote></span><div>[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.]</div><div><br></div><div>What do you mean by "in reality you would like to simply block specific requests according to session"?</div><div><br></div><div>I have live code being used in a mission critical and highly sensitive project with a before hook (approximately) like this:</div><div><br></div><div>hook before => sub {</div><div> #whitelist /ip route as not needing any auth check</div><div> return if (request->path_info =~ m{(^/ip$)|});</div><div><br></div><div> my $user = Dancer::Plugin::Auth::Extensible::Provider::Redacted->ip_login();</div><div><br></div><div> var user => $user;</div><div><br></div><div> $user or die "no user";</div><div>}; </div><div><br></div><div>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.</div><div><br></div><div>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?</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
><br>
> 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.<br>
> 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.<br>
<br>
</span>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?<br>
Also in a production environment you might deliver static files with some other software (Nginx, ...) and you loose control on<br>
these public files anyway.<br></blockquote><div><br></div><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>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?</div><div><br></div><div>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.</div><div><br></div><div>I would think you really want to have the option of having static files served with as little intervention by code as possible.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>mike</div></font></span></div></div></div>
<br>_______________________________________________<br>
dancer-users mailing list<br>
<a href="mailto:dancer-users@dancer.pm">dancer-users@dancer.pm</a><br>
<a href="http://lists.preshweb.co.uk/mailman/listinfo/dancer-users" target="_blank">http://lists.preshweb.co.uk/mailman/listinfo/dancer-users</a><br>
<br></blockquote></div><br></div>