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

How to work with Dancer2 ?
by Celogeek 27 Dec '12

27 Dec '12

Hi, I have start hacking Dancer2 project. I have multiple question : - I know people are busy, but how long take a patch to be merge after 2 validations and 3 weeks still waiting ? I'm waiting to see if the project is still active to add futher patches. - I want to update my Dancer::Plugins::Redis, but I'm a little bit lost on the right way to do it. How to be compatible with v1 and v2 ? - Is they an equivalent website as perldancer.org for perldancer2 ? - I have start writing App::Dancer2 (already push on cpan), based on the Dancer2 mainline git repository example. Is they a doc somewhere to do stuff more complicated ? - is they a list of Dancer2 already patched module ? I think a website like " https://www.djangoproject.com/" or " http://rubyonrails.org/" or "http://perldancer.org" could be great to speed up the passage from v1 to v2. Having a good tutorial to start a Dancer2 project, and to create some awesome Dancer2::Plugins is essential. A place where all of this can be found. What do you think ? I was thinking of a kind of wordpress website (like mine :) http://blog.celogeek.com ) to push our discover, our tutorial ... Any contributor could push their discover. Something : Starting a new Dancer2 project Starting a new Dancer2 Plugins How to upgrade your Dancer1 plugins to be compatible with Dancer2 How to create a Dancer1 / Dancer2 plugin Hacking Dancer2, how to post your patches Our IRC ... If anyone is interested, I can work on it and take the perldancer2.org domains if needs. Please tell me, I'm motivated. Thanks.

4 4

dancer_major_version
by damien krotkine 27 Dec '12

27 Dec '12

Hi, As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that. People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2. int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added : dancer_major_version, which returns what's on the left of the dot in the version number. Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword) What's the best solution ? In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all 2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins. 3/ any idea ? As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change. In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is dams.

6 9

DANCER_CONFFILE support with test
by Jens Rehsack 27 Dec '12

27 Dec '12

Hi everybody, some time ago I initiated a discussion at irc.perl.org/#dancer regarding the config file name (always the same, what might create conflicts when installing multiple Dancer based applications into a same file-system prefix). This conflict can currently only resolved by creating sub-directory for config.yml for each application, what is a waste of i-nodes and reduces clear arrangement of configurations. Attached is a patch which allows operators of Dancer based applications to choose individual names for the configuration file depending on operation and/or developer guidelines. Happy New Year, everyone! -- Jens Rehsack

1 0

Dancer::Plugin::Auth::Basic on Windows
by Jesse Thompson 26 Dec '12

26 Dec '12

I'm attempting to port a Dancer app to Windows. So far, all of the dependencies have installed fine, but cpanm fails to install Dancer::Plugin::Auth::Basic Building and testing Dancer-Plugin-Auth-Basic-0.02 Can't open README.pod for writing: Permission denied at C:\Users\zjt\.cpanm\work\1355758680.3396\Dancer-Plugin-Auth-Basic-0.02\_build\lib/My/Builder.pm line 11. It appears that the path .../My/Builder.pm is assuming the OS is *nix. Anyone know if a way to fix this? Jesse

4 6

Patch to fix exception serialization under JSON/XML (https://github.com/PerlDancer/Dancer/issues/877)
by Rik Brown 24 Dec '12

24 Dec '12

Hi all, I just raised this bug, and made a patch for it. Details are at https://github.com/PerlDancer/Dancer/issues/877 - but in short, Dancer::Error passes the Dancer::Exception::* object through to the serializer, which then explodes because (certainly for JSON/XML) it is not configured to support serialising objects (and probably shouldn't be!). The patch removes sending this exception through. In the case of JSON/XML, this never worked, but for non-object exceptions (i.e. die "some string"), it changes the response from having identical 'error' and 'exception' keys to having only an 'error' key. I'd appreciate any feedback on the (2 line!) patch - this is my first time contributing to Dancer so I may not be following procedure properly :-). Cheers - and have a great Christmas everyone! -- Rik Brown http://www.rikbrown.co.uk

1 0

Introducing Dancer::Plugin::Auth::Tiny
by David Golden 19 Dec '12

19 Dec '12

Hi, everyone. The fascinating DPAE discussion prompted me to write a Tiny auth plugin with some similar concepts. Because I already have user authentication working -- and because I think that logic should live in the model, not in the controller -- the "wrap routes" feature of DPAE was great sugar, but I didn't want the authentication backends or the default login/logout handlers. So... I wrote just the sugar part, and left all the actual authentication up to the user. Here's the synopsis -- note the 'needs login' in the '/private' route handler line: use Dancer::Plugin::Auth::Tiny; get '/private' => needs login => sub { ... }; get '/login' => sub { # put 'return_url' in a hidden form field template 'login' => { return_url => params->{return_url} }; }; post '/login' => sub { if ( _is_valid( params->{user}, params->{password} ) ) { session user => params->{user}, return redirect params->{return_url} || '/'; } else { template 'login' => { error => "invalid username or password" }; } }; sub _is_valid { ... } # this is up to you Plus, it's extensible, if you want to replace the 'login' wrapper with your own, or if you want to add additional wrappers for your own needs. I'd love to hear feedback, so please check it out: https://metacpan.org/module/Dancer::Plugin::Auth::Tiny David -- David Golden <xdg(a)xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

1 0

Dancer::Plugin::Auth::Extensible - removing sub attributes - ready to try out
by David Precious 19 Dec '12

19 Dec '12

Hi all, Following the recent discussion on the list regarding DPAE's use of subroutine attributes to declare which routes need auth/specific roles and a before handler to check for them, the general consensus seems to be that, whilst the attributes-based approach is quite clean, it's not necessary solid enough to rely upon. (Multiple people whose opinions I respect advised me that there are likely to be issues with it - some potential problems include thread safety, and problems I've seen at work when running under the debugger / Devel::Cover etc.) For that reason, whilst DPAE is still young and not widely used (as far as I'm aware :) ), I've decided it would make sense to take the approach recommended by multiple people, and replace sub attributes with keywords which wrap the route handler coderef and perform the required checks before executing it. The changes are in a remove_attributes branch - the refactor commit is: https://github.com/bigpresh/Dancer-Plugin-Auth-Extensible/commit/32844b7c3c… From a user's point of view, the changes are in how you define that a route needs login / specific roles. Previously, you would say: get '/secret' => sub :RequiresLogin { ... }; Now, you'd say: get '/secret' => requires_login sub { ... }; And to require specific roles: get '/beer' => requires_role BeerDrinker => sub { ... }; Opinions on this would be warmly welcomed. Also, if you've been using DPAE and have a moment to try out your code with these changes, that would be awesome. DPAE passes all its tests after the changes, so I'm reasonably convinced that it's working correctly, but will perform more testing before this hits CPAN. Cheers 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

5 9

Global keywords still in Dancer 2?
by gvim 18 Dec '12

18 Dec '12

I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace. I'm coming to Dancer from CGI::Application where we have a persistent $c object, as with Catalyst. Is this approach built into Dancer 2 or is it still using the same global namespace approach? I'd like to be able to be able to: my $d = new Dancer; OR my $d = Dancer->new(); ...... $d->session(); $d->template(); etc. gvim

6 8

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