- dancer-users - lists.preshweb.co.uk

Dancer::Plugin::Auth::Extensible - possible backwards-incompatible change
by David Precious 14 Dec '12

14 Dec '12

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(a)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

9 13

Problem with D::P::A::E::Provider::Base.pm
by Rick Bragg 13 Dec '12

13 Dec '12

Hi everyone! I really like what I see in Dancer::Plugin::Auth::Extensible, however, there is a real problem in the Provider::Base.pm match_password() sub, and the solution would probably break some current (poorly implemented) sites. First, it is hard coded to use "Crypt::SaltedHash->validate($correct, $given)" for validation, (not to mention It does not even let you set the salt length so it defaults to 4) then to my horror, if that fails, it tries to match it in plain text! Yikes! The reason this is really bad is that at the back end where user validation is concerned, there should be NO guessing and helping from the scrip! This sub should not try to help out at all. I would argue there should be no option for plain text period. You should also have to specify the hashing module you want (i.e. Dancer::Plugin::Passphrase; Crypt::SaltedHash; etc... (in case one is compromised, or just outdated you could switch to another at will) And you should have to specify the algorithm to use. There should never be defaults here. It should just fail if this stuff is not specified period. One thing I like to be able to do is set the password in a user's account to '', or '1' or '0' or anything as a really quick way to force the user to reset their password because they would NEVER be able to log in with that. The way it is now, you have to set a random string and hash it or something crazy... I'm willing to help out however I can because I'm re-writing a fairly large site (from Interchange) and I don't want to write lots of patch code on top when things should be done at the modules. My time is short, and I'm really hurting for cash, but let me know if there is anything I can do to help. Again, I really like what I'm seeing in D::P::A::E and in Dancer overall!! Thanks! Rick Bragg

4 5

Can I write own config in config.yml?
by chenlin rao 11 Dec '12

11 Dec '12

I try to write my own elasticsearch config in config.yml: ElasticSearch: servers: "10.10.10.33:9200" transport: "httplite" max_requests: 10000 trace_calls: 0 no_refresh: 0 But after I got the right `config->{ElasticSearch}` in my lib/DancerApp/A.pm, I got `config->{ElasticSearch}` in my lib/DancerApp/B.pm returns only one line as 'trace_calls:0'. I try to got config->{appdir} at multi sub and got right result everywhere. Why??

3 2

Re: [dancer-users] dancer-users Digest, Vol 34, Issue 3
by chenlin rao 10 Dec '12

10 Dec '12

config.yml: > ElasticSearch: > servers: "10.10.10.33:9200" > transport: "httplite" > max_requests: 10000 > trace_calls: 0 > no_refresh: 0 lib/App.pm: >use lib "$Bin/../lib"; >use App::A; >use App::B; lib/App/A.pm: >use Dancer ':syntax'; >use ElasticSearch; >my $elsearch = ElasticSearch->new( config->{ElasticSearch} ); >prefix '/a'; >get '/config' => sub { return Dumper $elsearch }; lib/App/B.pm: >use Dancer ':syntax'; >use ElasticSearch; >my $elsearch = ElasticSearch->new( config->{ElasticSearch} ); >prefix '/b'; >get '/config' => sub { return Dumper $elsearch }; Then `get http://localhost:3000/a/config` show that servers: " 10.10.10.33:9200" but `get http://localhost:3000/b/config` show that servers: "127.0.0.1:9200" which is the default setting of ElasticSearch module. 2012/12/10 <dancer-users-request(a)dancer.pm> > Send dancer-users mailing list submissions to > dancer-users(a)dancer.pm > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users > or, via email, send a message with subject or body 'help' to > dancer-users-request(a)dancer.pm > > You can reach the person managing the list at > dancer-users-owner(a)dancer.pm > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dancer-users digest..." > > > Today's Topics: > > 1. Can I write own config in config.yml? (chenlin rao) > 2. Re: Can I write own config in config.yml? (David Precious) > 3. Re: Can I write own config in config.yml? (David Precious) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Dec 2012 16:56:46 +0800 > From: chenlin rao <rao.chenlin(a)gmail.com> > Subject: [dancer-users] Can I write own config in config.yml? > To: dancer-users(a)perldancer.org > Message-ID: > <CABwsoohczVCJwVxZcFUqPaS2KdxsK8-rE-V0= > TeJEmDEPr4r5w(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I try to write my own elasticsearch config in config.yml: > > ElasticSearch: > servers: "10.10.10.33:9200" > transport: "httplite" > max_requests: 10000 > trace_calls: 0 > no_refresh: 0 > > But after I got the right `config->{ElasticSearch}` in my > lib/DancerApp/A.pm, I got `config->{ElasticSearch}` in my > lib/DancerApp/B.pm returns only one line as 'trace_calls:0'. > > I try to got config->{appdir} at multi sub and got right result everywhere. > > Why?? >

2 2

Test, please ignore (testing old list address forwarding)
by David Precious 05 Dec '12

05 Dec '12

Just checking that mails to the old list address arrive via the new list as they should. -- David Precious ("bigpresh") <davidp(a)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

1 0

Advent Calendar : Request for volunteers
by Alexis Sukrieh 05 Dec '12

05 Dec '12

Hello fellow Dancers! As you may know, we're running for the third consecutive year the Perl Dancer Advent Calendar: http://advent.perldancer.org/ It's being very well received (almost 300% traffic growth compared to last year) and each day we reach more than 500 unique visitors. It's a very good opportunity for us to showcase Dancer. That's great but there is a problem Houston! We don't have enough contributions! I'm requesting your help: if you want to contribute to the effort, you're more than welcome! Contributions are pretty easy to do: Fork and clone the repo at https://github.com/PerlDancer/advent-calendar And add your article in the pending directory then send a pull request. We'll do the rest. Your article doesn't need to be long, many things are possible: a Plugin you're using and how, a use case of Dancer at work, at home, what you like in Dancer, why did you use Dancer... Thanks a lot!

2 2

Re: [dancer-users] [Dancer-users] Dancer2 best practices
by Alexis Sukrieh 05 Dec '12

05 Dec '12

Actually, regarding the scaffolding of an app, it's exactly the same. Take a look at the Advent Calendar app, it's Dancer2! Nothing new here, 100% the same as Dancer 1 except that you can use any config file format instead of being forced to YAML. The only change you have to do is about TT's defaut markers (they are [% and %] in D2) and also, the config hierarchy for engines which is now: engines: $type: $name: ... Whereas with D1 there was no "$type" level. Appart from that, everything works just like the same. 2012/11/29 Maurice Mengel <mauricemengel(a)gmail.com> > Somebody point me to an article or two that might make sense, please. > Thanks! > > On Thu, Nov 29, 2012 at 1:15 PM, sawyer x <xsawyerx(a)gmail.com> wrote: > >> that, yes! >> > > > _______________________________________________ > Dancer-users mailing list > Dancer-users(a)perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users > >

1 0

What do you think of Dancer? ( & Advent calendar posts needed!)
by David Precious 05 Dec '12

05 Dec '12

Hi all, We still have spots left for more posts on the Dancer advent calendar, so if anyone fancies contributing a post, don't be shy, let us know! Also, I'm thinking a good idea for a post might be a set of testimonial-type paragraphs from Dancer users, explaining what they use Dancer for, what they like about Dancer, and what they'd like to see in the future etc. So, if you use Dancer, and have a moment to spare to provide us a quote, please mail me with, say, 1-5 paragraphs - as above, good things to include would be what you use Dancer for, what you like about Dancer, what you'd like to see in future from Dancer etc. (These may also be used on the testimonials page on the site, which could do with an update.) Also, if you have a Dancer-powered site which isn't yet featured on the dancefloor page ( www.dancer.pm/dancefloor ) and you'd like it to be, please let me know! Cheers all Dave P -- David Precious ("bigpresh") <davidp(a)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

1 0

Problem with Dancer::Test, forward and session
by Marco Pessotto 03 Dec '12

03 Dec '12

Hello all! I think, but not sure, I've hit a bug in Dancer::Test. This is the minimal example: #### cut here ##### package DancerMelmothBug; use Dancer ':syntax'; post '/login' => sub { if (params->{username} and params->{password}) { session 'auth' => 1; } }; get '/login' => sub { return "login screen"; }; post '/works' => sub { return redirect '/login' unless session->{auth}; warn "works!"; return "it works"; }; post '/first' => sub { return redirect '/login' unless session->{auth}; warn "forwarding\n"; forward '/second'; }; post '/second' => sub { return redirect '/login' unless session->{auth}; warn "done\n"; return "OK"; }; 1; ###### cut here ########## This is the test script ##### cut here ##### use Test::More tests => 2; use DancerMelmothBug; use Dancer::Test; use Data::Dumper; use HTTP::Headers; my $login_creds = { username => "tester", password => "provaprova", }; my $loggingin = dancer_response (POST => '/login', { params => $login_creds }); my $sessionkey = $loggingin->header('Set-Cookie'); if ($sessionkey =~ m/(dancer\.session=.*?;)/) { $sessionkey = $1; print "Got the session key $sessionkey\n"; } my $loggedinheader = HTTP::Headers->new( cookie => $sessionkey ); my $response; $response = dancer_response(POST => "/works", { params => {}, headers => $loggedinheader, }); ok($response->content); $response = dancer_response(POST => "/first", { params => {}, headers => $loggedinheader, }); ok($response->content); ##### cut here #### Running the test yields: perl test.t 1..2 Got the session key dancer.session=4079393373042855076725642369476525; works! at DancerMelmothBug.pm line 17. ok 1 forwarding not ok 2 # Failed test at test.t line 42. # Looks like you failed 1 test of 2. So, it looks like it fails to get the session after the forwarding. It also seems that the bug is present only in the testing environment, because the running app is reacting properly. Best wishes and thanks in advance. -- Marco

1 0

Dancer::Test + Devel::Cover + subroutine attributes == PAIN
by David Cantrell 29 Nov '12

29 Nov '12

We're using subroutine attributes on our route handlers for authentication. eg, things like ... get '/phonecall/:from/:to/:datetime/download_mp3' => sub :Auth( Government TabloidPress ) { ... }; and have a 'before' hook that checks that only logged in users who have the 'Government' or 'TabloidPress' role can listen in on other peoples' phone calls. This works nicely, both when we run the application and when we test it using Dancer::Test. However, we'd quite like to get some metrics of how good our tests are, and Devel::Cover is the tool for that. Trouble is, something is breaking, and the attributes are going missing somewhere. I've boiled it down to a *really* minimal app and tests, which are appended to this 'ere email. If I run the app, it works: $ ./app.pl & [1] 314 ... $ GET http://localhost:3000/plato I can Philosophise and if I run the tests without Devel::Cover, they work too: $ PERL5LIB=lib prove -rv ./t/test-devel-cover.t .. 1..4 ok 1 - GET /plato - status OK ok 2 - content looks good for /plato ok 3 - GET /leonardo - status OK ok 4 - content looks good for /leonardo ok All tests successful. but throw Devel::Cover into the mix too, and it all gone done buggerup: $ PERL5OPT=-MDevel::Cover PERL5LIB=lib prove -rv ./t/test-devel-cover.t .. 1..4 Use of uninitialized value in concatenation (.) or string at lib/TestApp.pm line 35, <DATA> line 998. ok 1 - GET /plato - status OK Use of uninitialized value in concatenation (.) or string at lib/TestApp.pm line 35, <DATA> line 998. not ok 2 - content looks good for /plato ... I can see (by inserting some print statements!) that the attributes are getting stored, but something is happening to prevent them from being pulled back out again. Has anyone else worked with Dancer and Devel::Cover and got any tips for me, or am I going to have to delve into the lump of pure concentrated EVIL that is the Devel::Cover source? $ cat app.pl #!/usr/bin/env perl use strict; use warnings; use lib 'lib'; use Dancer; use TestApp; dance; $ cat lib/TestApp.pm package TestApp; use strict; use warnings; use Dancer qw(:syntax); use Attribute::Handlers; my %attrs; sub Auth :ATTR(CODE) { my ($package, $symbol, $referent, $attr, $data) = @_; if(!ref($data)) { $data =~ s/^\s+|\s+$//g; $data = [split(/\s+/, $data)]; } $attrs{$attr}->{$referent} = $data; } sub get_attribs { my $class = shift; my $sub = shift; my $type = shift; return @{$attrs{$type}->{$sub} || []}; } hook 'before' => sub { my $handler = shift->code(); var('route_roles', __PACKAGE__->get_attribs($handler, 'Auth')); return; }; get '/plato' => sub :Auth(Philosophise) { "I can ".var('route_roles') }; get '/leonardo' => sub :Auth(Engineer) { "I can ".var('route_roles') }; 1; $ cat t/test-devel-cover.t use strict; use warnings; use TestApp; use Dancer::Test; use Test::More tests => 4; foreach my $tuple ( [ '/plato', 200, 'Philosophise' ], [ '/leonardo', 200, 'Engineer' ], ) { my ($url, $status, $lookfor) = @{$tuple}; response_status_is [GET => $url], $status, "GET $url - status OK"; response_content_like [GET => $url], qr/$lookfor/, "content looks good for $url"; } -- David Cantrell | Nth greatest programmer in the world NANOG makes me want to unplug everything and hide under the bed -- brian d foy

2 2