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

Re: [dancer-users] Dancer2::Plugin::Auth::Extensible with DB
by Nathan Bailey 23 Nov '17

23 Nov '17

And in support of Andy's comments below - I put a debug warn statement at the start of each sub in Extensible.pm and Database.pm to work out where things weren't working. Also turn up your logging to get the 'debug' level reports from DPAE into your logs. On 23 November 2017 at 22:10, Andrew Beverley <andy(a)andybev.com> wrote: > On Thu, 23 Nov 2017 10:28:31 +0000 Clive Eisen wrote: > > However the login is failing and I am just returned to the login screen > > with the banner set to LOGIN FAILED > > > > There is no indication WHAT is failing - can anyone suggest either what > > is wrong or where I can add debug - I have tried with and without roles. > > I would start by hacking some debug statements directly into the > authenticate_user() subroutine in Provider/Database.pm > > That function should be called by DPAE, so you can check firstly that > it's actually being called, and secondly if/what/why it's returning a > failure (assuming it is). > > Andy > _______________________________________________ > dancer-users mailing list > dancer-users(a)dancer.pm > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >

2 2

Re: [dancer-users] Dancer2::Plugin::Auth::Extensible with DB
by Nathan Bailey 23 Nov '17

23 Nov '17

As far as I can tell, the module is actually incomplete. Try the following patch: --- /Library/Perl/5.18/Dancer2/Plugin/Auth/Extensible/Provider/Database.pm 2016-11-04 20:50:52.000000000 +1100 +++ Database.pm 2017-11-23 22:37:21.000000000 +1100 @@ -375,7 +375,8 @@ unless defined $username; # Get our database handle and find out the table and column names: - my $database = $self->database; + #my $database = $self->database; + my $database = $self->plugin_database($self->db_connection_name); # Per https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Datab… # Look up the user, my $user = $database->quick_select( @@ -389,6 +390,28 @@ } } +sub get_user_by_code { + my ($self, $code) = @_; + croak "code must be defined" + unless defined $code; + + # Get our database handle and find out the table and column names: + #my $database = $self->database; + my $database = $self->plugin_database($self->db_connection_name); # Per https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Datab… + + # Get just the username of the user with the matching pw_reset_code + my $user = $database->quick_lookup( + $self->users_table, { 'pw_reset_code' => $code }, 'email' + ); + + if (!$user) { + $self->plugin->app->log("debug", "No such code $code"); + return; + } else { + return $user; + } +} + =head2 get_user_roles $username =cut @@ -396,7 +419,8 @@ sub get_user_roles { my ($self, $username) = @_; - my $database = $self->database; + #my $database = $self->database; + my $database = $self->plugin_database($self->db_connection_name); # Per https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Datab… # Get details of the user first; both to check they exist, and so we have # their ID to use. cheers, Nathan On 23 November 2017 at 22:10, Andrew Beverley <andy(a)andybev.com> wrote: > On Thu, 23 Nov 2017 10:28:31 +0000 Clive Eisen wrote: > > However the login is failing and I am just returned to the login screen > > with the banner set to LOGIN FAILED > > > > There is no indication WHAT is failing - can anyone suggest either what > > is wrong or where I can add debug - I have tried with and without roles. > > I would start by hacking some debug statements directly into the > authenticate_user() subroutine in Provider/Database.pm > > That function should be called by DPAE, so you can check firstly that > it's actually being called, and secondly if/what/why it's returning a > failure (assuming it is). > > Andy > _______________________________________________ > dancer-users mailing list > dancer-users(a)dancer.pm > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >

1 0

Dancer2::Plugin::Auth::Extensible with DB
by Clive Eisen 23 Nov '17

23 Nov '17

Hi Apologies for the length of this but I wanted to include everything I have tried. I have been using Dancer2::Plugin::Auth::Extensible <http://search.cpan.org/perldoc?Dancer2%3A%3APlugin%3A%3AAuth%3A%3AExtensible> for a while - all good. I am now trying to use Dancer2::Plugin::Auth::Extensible::Provider::Database <http://search.cpan.org/perldoc?Dancer2%3A%3APlugin%3A%3AAuth%3A%3AExtensibl…> thus session: Cookie template: template_toolkit engines: template: template_toolkit: start_tag: '<%' stop_tag: '%>' session: Cookie: secret_key: thisisverysecret! default_duration: 604800 plugins: Auth::Extensible: disable_roles: 1 realms: users: provider: 'Database' users_table: ot_users # roles_table: ot_roles # user_roles_table: ot_user_roles Database: dsn: "dbi:Informix:ehive_support2012" #driver: 'Informix' #database: 'ehive_support2012' username: ******* password: ******* log_queries: 1 on_connect_do: ['set explain on'] dbi_params: PrintError: 0 RaiseError: 1 AutoCommit: 1 Once I got past the db connection errors I added and entry in the ot_users table for me using create_user username => "clive", email => 'clive(a)hildebrand.co.uk', email_welcome => 0; and user_password username => 'clive', new_password => 'secret'; And indeed I can manually run SELECT * FROM "ot_users" WHERE "username”=‘clive’ and it works In addition the following test program also works #!/usr/bin/env perl use DBI; use Data::Dumper; my $dbh_support = DBI-> connect("dbi:Informix:ehive_support2012", ‘*******' , ‘*******', { RaiseError=> 0, AutoCommit => 1, PrintError => 1, PrintWarn => 1}) or die("Connect failed $DBI::errstr"); $sel = $dbh_support->prepare(qq(SELECT * FROM "ot_users" WHERE "username"=?)); $sel->execute('clive'); my $a = $sel->fetchrow_hashref; print Dumper($a); producing $VAR1 = { 'password' => '{SSHA512}Jr34UXRpsaCQSWsJJE/Qq84fpq6RBVi', 'email' => 'clive(a)hildebrand.co.uk', 'pw_reset_code' => 'Ct1FIiUkwdiLSRVYUQCOyQYEquSV5RRe', 'username' => 'clive', 'id' => '3', 'hid' => undef }; However the login is failing and I am just returned to the login screen with the banner set to LOGIN FAILED There is no indication WHAT is failing - can anyone suggest either what is wrong or where I can add debug - I have tried with and without roles. [otweb:22772] core @2017-11-23 10:10:22> looking for post /login in /root/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/Dancer2/Core/App.pm l. 35 [otweb:22772] core @2017-11-23 10:10:22> Entering hook core.app.before_request in (eval 718) l. 1 [otweb:22772] core @2017-11-23 10:10:22> Entering hook plugin.auth_extensible.before_authenticate_user in (eval 718) l. 1 [otweb:22772] debug @2017-11-23 10:10:22> Attempting to authenticate clive against realm users in /root/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/Dancer2/Core/Route.pm l. 140 [otweb:22772] core @2017-11-23 10:10:22> Entering hook plugin.database.database_connected in (eval 718) l. 1 [otweb:22772] debug @2017-11-23 10:10:22> Executing SELECT query SELECT * FROM "ot_users" WHERE "username"=? with params clive in /root/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/Dancer2/Plugin.pm l. 532 [otweb:22772] core @2017-11-23 10:10:22> Entering hook plugin.auth_extensible.after_authenticate_user in (eval 718) l. 1 [otweb:22772] core @2017-11-23 10:10:22> looking for get /login in /root/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/Dancer2/Core/App.pm l. 35 [otweb:22772] core @2017-11-23 10:10:22> Entering hook core.app.before_request in (eval 718) l. 1 [otweb:22772] debug @2017-11-23 10:10:22> app has no login template defined in /root/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/Dancer2/Plugin/Auth/Extensible.pm l. 283 [otweb:22772] core @2017-11-23 10:10:22> Entering hook core.app.after_request in (eval 718) l. 1 -- Clive Eisen GPG: 3818B5F1

2 1

Template::Tiny vs ForkedTiny
by Gabor Szabo 17 Nov '17

17 Nov '17

Hi again, I am still into the templating systems of Dancer. It seems Dancer2 requires Template::Tiny in its cpanfile but it never uses it. Instead there is a re-implementation of it at https://metacpan.org/pod//Dancer2::Template::Implementation::ForkedTiny I am wondering why not use Template::Tiny? And if it isn't in use then why require it? regards Gabor

2 1

Dancer 1 FCGI deployment quandry
by Joel Roth 16 Nov '17

16 Nov '17

Hi List, I have a web application at Dreamhost.com that I'm trying to convert to fastcgi. Under CGI, the application runs via perlbrew using a self-compiled perl. In the Apache 2 error log, I'm getting [Mon Nov 13 13:31:53 2017] [error] [client 98.150.189.73] Premature end of script headers: dispatch.fcgi When I run the script dispatch.fcgi, it brings up the Dancer HTTP server: HTTP::Server::PSGI: Accepting connections at http://0:5000/ >From the Dreamhost docs[1,2] and using the supplied test script, I don't need to modify the Apache configuration. The only changes I made to the original dispatch.cgi -- gleaned from Dancer::Deployment -- were updating the script name and mod_rewrite rule. File listings that make up my deployment follow. I don't grok is how running dispatch.fcgi, which ends in an 'exec', relates to an existing, persistent Dancer process. Perhaps Plack::Runner->run() should receive a coderef rather than a filename? I tried, but received the same the error message. I greatly welcome any suggestions! 1. https://help.dreamhost.com/hc/en-us/articles/217298967-FastCGI-overview 2. https://help.dreamhost.com/hc/en-us/articles/216512598-Perl-overview cd dev.childspacemethod.com ls -l -rwxrwxr-x 1 childspace pg2527812 81 Nov 13 13:33 dispatch.fcgi -rw-r--r-- 1 childspace pg2527812 157 Nov 13 12:40 .htaccess -rwxrwxr-x 1 childspace pg2527812 155 Nov 13 12:47 plack_runner.pl cat .htaccess # BEGIN dancer application htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule (.*) dispatch.fcgi/$1 # END dancer application htaccess cat dispatch.fcgi #!/bin/sh source ~/.bashrc perlbrew use 5.16.3 exec `dirname $0`/plack_runner.pl cat plack_runner.pl #!/usr/bin/env perl use Modern::Perl; use Plack::Runner; use autodie; chdir '/home/childspace/dev'; Plack::Runner->run('dance.psgi'); cat /home/childspace/dev/dance.psgi #!/usr/bin/env perl BEGIN { push @ARGV, qw(--environment=production) } use Modern::Perl; use Dancer; load_app 'Training::Resources'; dance; -- Joel Roth

1 1

Dancer2::Template::Simple features
by Gabor Szabo 15 Nov '17

15 Nov '17

Hi, reading the source code and then looking at the tests reveal that https://metacpan.org/pod/Dancer2::Template::Simple support both variable interpolation <% var1 %> and conditional statement: <% if var %> true <% else %> false <% end %> The latter however is not documented. Is it because it has not been documented or because this feature is not recommended at all? regards Gabor

1 0

Writing an Auth plugin for SSL client certificates
by perlduck 13 Nov '17

13 Nov '17

Hello, TL;DR I'd like to write an authentication plugin that behaves like Dancer2::Plugin::Auth::Extensible but does NOT require a user's password but instead relies on the SSL variables SSL_CLIENT_VERIFY and SSL_CLIENT_S_DN_Email. Background: I have a Dancer2 application and currently using Dancer2::Plugin::Auth::Extensible to authenticate my users with username/password. I'm currently using two providers (realms), Config and Database. Config is mainly for testing purpose but I like the idea of multiple realms. I also need the concept of roles, so DPAE is just great and everything works like a charm. Now I want to switch to client certificate authentication. I have set up an Apache as a proxy to the plackup server. Apache handles the SSL stuff, sets the variables <Location /> RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s" RequestHeader set SSL_CLIENT_S_DN_Email "%{SSL_CLIENT_S_DN_Email}s" </Location> and then redirects to my Dancer2 app (at 127.0.0.1:5000). Within my routes I can access those variables with my $client_verify = request->env->{'HTTP_SSL_CLIENT_VERIFY'} // ''; my $username = request->env->{'HTTP_SSL_CLIENT_S_DN_EMAIL'} // ''; This works. Apache sets HTTP_SSL_CLIENT_VERIFY to 'SUCCESS' if the authentication worked. What I now want to achieve is: IFF $client_verify eq 'SUCCESS' THEN let the user $username in. Don't show a /login page. Pick the user's details from the database (or whatever realm(s) is/are configured). Don't show a /logout page. In short: allow everything what Dancer2::Plugin::Auth::Extensible allows but without ever asking for a password or redirecting to a /login page if the two variables are set (and, of course, $username can be found in the DB). A very naive first approach was to use a "before" hook to set the "logged_in_user" value: hook before => sub { my $client_verify = request->env->{'HTTP_SSL_CLIENT_VERIFY'} // ''; my $username = request->env->{'HTTP_SSL_CLIENT_S_DN_EMAIL'} // ''; if ($client_verify eq 'SUCCESS' and $username) { session logged_in_user => $username; } }; This seems to work but looks very dirty to me. So I thought I'd better write a plugin that behaves like a Dancer2::Plugin::Auth::Extensible plugin but doesn't require a password and rather uses the two environment variables instead. Is Dancer2::Plugin::Auth::Extensible even the right place (base) for such a plugin? Cheers

3 4