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 <[email protected]> wrote: > > > On Fri, Sep 12, 2014 at 8:56 AM, Sawyer X <[email protected]> wrote: > >> On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) < >> [email protected]> 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 > [email protected] > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users > >
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
