A Simple Login/Authorization system using Dancer and Postgres - perl

As a newbie to Perl I'm struggling to find a simple way to do this. I've created a very simple table in my database:
CREATE TABLE users (
id SERIAL NOT NULL PRIMARY KEY,
username TEXT NOT NULL,
password TEXT NOT NULL);
So far I used a simple login system that has a hard coded username and password that I found online:
package Example;
use Dancer ':syntax';
our $VERSION = '0.1';
set session => "Simple";
get '/' => sub {
# template 'index',{},{layout => 0};
template 'index';
};
before sub {
if (! session('user') && request->path_info !~ m{^/login}) {
var requested_path => request->path_info;
request->path_info('/login');
}
};
get '/login' => sub {
# Display a login page; the original URL they requested is available as
# vars->{requested_path}, so could be put in a hidden field in the form
template 'login', { path => vars->{requested_path} }, {layout => 0};
};
post '/login' => sub {
# Validate the username and password they supplied
if (params->{user} eq 'user' && params->{pass} eq 'letmein') {
session user => params->{user};
redirect params->{path} || '/';
} else {
redirect printf 'login failed';
}
};
get '/logout' => sub {
session->destroy;
redirect '/';
};
How do I get started with linking the database and then matching what the user inputs with what's in the database? And also when do I implement the hashing of the passwords? Any tutorials will be greatly appreciated - I've been using metacpan but it's not providing as much detail as I need!

Dancer::Plugin::Auth::Extensible takes care of a lot of boilerplate code for you. You can get a simple login system up and running without having to write any of your own /login routes as follows.
Configure Dancer::Plugin::Auth::Extensible
Install Dancer::Plugin::Database and Dancer::Plugin::Auth::Extensible::Provider::Database and add this to config.yml:
session: "YAML"
plugins:
Auth::Extensible:
realms:
users:
provider: 'Database'
disable_roles: 1
Configure database connection
Configure your database connection in environments/development.yml so that you can have different configurations for dev and production. This is what the configuration looks like for MySQL, with the connection credentials (database name, host, username, and password) stored in a separate options file database.cfg:
plugins:
Database:
dsn: 'dbi:mysql:;mysql_read_default_file=/path/to/database.cfg'
dbi_params:
RaiseError: 1
AutoCommit: 1
For Postgres, you should use a .pgpass file to store your connection credentials. Make sure the file is not world readable. See this Stack Overflow post for an example. Test that your credentials file works on the command line and that your webserver can read it.
Your existing table appears to conform to the suggested schema in the docs, but even if it doesn't, you can adjust the table and column names in the configuration.
Lock down your routes
Add the require_login keyword to a route you want to protect. A /login route will be generated automatically with a basic login form, although you can create your own if you like.
lib/MyApp.pm
package MyApp;
use Dancer ':syntax';
use Dancer::Plugin::Auth::Extensible;
our $VERSION = '0.1';
get '/' => require_login sub {
template 'index';
};
true;
(Yes, that really is all the code you have to write. I told you it takes care of a lot of boilerplate.)
Crypt::SaltedHash is used to hash passwords automatically. Note that you should never store plaintext passwords in your database; when you add a user to your database, you should generate a hash of the password and store the hash.
Note that roles are disabled in this example. If you enable roles, you can do other nifty things like only allow users with the admin role to view admin pages.

The simplest way:
Dancer::Plugin::Authorize::Credentials::PostgreSQL
Here is a good write up how to do it properly: http://perlmaven.com/storing-passwords-in-a-an-easy-but-secure-way
post '/login' => sub {
# Validate the username and password they supplied
if (!params->{user} or !params->{pass}){
redirect printf 'login failed';
}
# use your own encryption
my $auth = auth($login, encrypt($password));
# login successful
if ($auth) {
session user => params->{user};
redirect params->{path} || '/';
} else {
redirect printf 'login failed';
}
};
Regards,
Andras

Related

How to access session data from test?

The Mojolicious framework states next:
Any aspect of the application (helpers, plugins, routes, etc.) can be introspected from Test::Mojo through the application object.
But when helper, for example, $c->current_user deals with session it fails.
The session data is not available and I can not access it from test:
$t->app->session # {}
Thus $t->app->current_user fails too.
How to access session data from test?
UPD The test
use Mojo::Base -strict;
use Mojolicious::Lite;
use Test::More;
use Test::Mojo;
get '/set_session' => sub {
my $c = shift;
$c->session->{ user_id } = 1;
$c->render( text => $c->session->{ user_id } );
};
get '/get_session' => sub {
my $c = shift;
$c->render( text => $c->session->{ user_id } );
};
my $t = Test::Mojo->new;
$t->get_ok( '/set_session' )->status_is(200);
is $t->app->session->{ user_id }, 1, 'Session available from test script';
$t->get_ok( '/get_session' )->status_is(200)
->content_is( 1 );
done_testing();
UPD test result
ok 1 - GET /set_session
ok 2 - 200 OK
not ok 3 - Session available from test script
# Failed test 'Session available from test script'
# at t/session.t line 22.
# got: undef
# expected: '1'
ok 4 - GET /get_session
ok 5 - 200 OK
ok 6 - exact match for content
1..6
# Looks like you failed 1 test of 6.
UPD
It seems that Mojo::Test object should save session object in addition to the request and response objects from the previous transaction
To test helpers in context of last request I write next role:
package Test::Mojo::Role::Helper;
use Mojo::Base -role;
sub helper {
my( $t ) = #_;
$t->tx->req->cookies( #{ $t->tx->res->cookies } );
$t->app->build_controller( $t->tx );
}
1;
Then use it as next:
use Test::Mojo;
my $t = Test::Mojo->with_roles( '+Helper' )->new( 'MyApp' );
$t->post_ok( '/login', json => { contact => $user_c, password => $user_p } )
->status_is( 200 );
is $t->helper->uid, 1, "Authorized user has identificator";
is $t->helper->role, 'user', "Authorized user has 'user' privilege";
UPD More robust solution
package Test::Mojo::Role::Helper;
use Mojo::Base -role;
my $req_context; # Here is controller object
sub helper { $req_context }
sub hook_context {
my( $t ) = #_;
$t->app->hook( after_dispatch => sub{ $req_context = shift });
$t;
}
1;
The testing is same with next small difference. When application is constructed we should hook to after_dispatch event:
my $t = Test::Mojo
->with_roles( '+Helper' )
->new( 'App' )
->hook_context;
The Test::Mojo class does not give you direct access to the session contents. The test class represents a client of your Mojolicious application, and the client does not have direct access to the session cookie either (well, it's just base64-encoded JSON so it's not exactly secret, but still …).
The “proper” way to test the session is to check that the app behaves correctly regarding the session, not just to check that the session was set to some value. That's effectively what your /get_session endpoint does. Of course you shouldn't just add such an endpoint for testing, but consider how the session fits into your requirements. E.g. as a BDD-style scenario:
Feature: the secret page
there is a secret page that should be only visible to logged-in users.
Background:
Given a user "test:test123"
Given a new client
Scenario: users cannot see the page when they are not logged in
When I visit the /secret page
Then I get a 404 response
Scenario: users can see the page after logging in
Given I log in as "test:test123"
When I visit the /secret page
Then I see "this is the secret"
The $t->app->session does not contain the session because the session data is loaded into the controller's stash. This only exists for the duration of the request. In particular app->session is merely a helper that delegates to the current controller, not a primary method of the application.
If you really need to peek into the session cookie, this might be the least insane way to do it, short of inflating a controller object:
my ($session) = grep { $_->name eq $t->app->sessions->cookie_name } $t->ua->cookie_jar->all->#*;
$session = $session->value =~ s/--[^-]+$//r; # strip signature
$session =~ tr/-/=/;
$session = $t->app->sessions->deserialize->(Mojo::Util::b64_decode $session);

Perl Dancer and defining routes with named parameters and nested prefixes

Recently I have been working with Dancer to create a application, but I am having difficulties figuring out how to define the routes.
package MyApp;
use Dancer ':syntax';
our $VERSION = '0.1';
# Base for routing of requests
# Match against /:validate
any '/:validate' => sub {
# This assumes we can stop the routing here
# validate the request param in the url string
# against a regex and 'pass' the request to a
# specific route with the 'var' option
var validate => params->{validate};
.....
# Validation works and dancer passes successfully
pass();
};
# This is the part that is not working
prefix '/info' => sub {
..... # does stuff
}; ## back to the root
In the dancer logs for the pass:
[25561] core #0.001133> [hit #1]Last matching route passed! in
/usr/local/share/perl5/Dancer/Route.pm l. 216
In the dancer logs for anything after the pass:
[25781] core #0.001524> [hit #4]Trying to match 'GET /11121/info/'
against /^/info$/ (generated from '/info') in
/usr/local/share/perl5/Dancer/Route.pm l. 84 [25781] core #0.002041>
[hit #4]response: 404 in /usr/local/share/perl5/Dancer/Handler.pm l.
179
It is probably something simple I am missing, but I have not had any luck so far. Any help is greatly appreciated.
EDIT I did notice I was using prefix incorrectly so I fixed that and I apologize for the bad explanation. In a nut shell the first part of the url localhost:3000/12/ for example is a database record. All routes are build on that record being the first part of the url string so I want to validate it prior to going any further into the routes.
I was able to setup a before hook which grabs it and can work with the params hash, but it is getting a 500 error on non-matching patterns currently.
hook before => sub {
my $route_handler = shift;
var record => params->{record};
my $record = var 'record';
while ($record !~ m/^ID[\-]\d{3,6}$/) { # Check for valid ID
if ($record =~ m/^\d{3,6}$/) { # Works currently
$record = 'ID-'.$record;
}else {forward "/error"}; # this = 500 ISE error
}
};
I tried a forward and send_error but both generate an ISE and Dancer reports this on the last entry in the log:
29661] core #0.001048> [hit #2]entering before hook in
/usr/local/share/perl5/Dancer/Hook.pm l. 58
Any help is greatly appreciated, also an edit to make my question more clear is welcomed.
That is not what prefix does. Prefix is used to declare the prefix of the routes in the current package.
prefix '/users';
get '/' => sub { ... }; # matches /users
post '/add' => sub { ... }; # matches /users/add
get '/view/:id' => sub { ... }; # matches /users/view/123
I haven't worked with Dancer at all, but from the Dancer::Introduction docs, it looks like you also have to define a route inside the prefix /info. Try with:
# This is the part that is not working
prefix '/info' => sub {
get '/' => sub {
..... # does stuff
}
}; ## back to the root

Making Register Plus Redux work with Nextend Google Connect

I'm trying to make two popular WordPress plug-ins work well together. Hopefully this question isn't too specific to my setup -- I think enough people use these plug-ins to make it a common issue.
I'm using Register Plus Redex (RPR) to require user registration to be accepted (by admin) before a user can log-in. Alone, this works fine.
I'm also using Nextend Google Connect (NGC) to allow users to log-in with Google. Those also need to be approved before they can log-in.
When NGC creates a new user in the database, it correctly has the "not activated" flag set. However, the user is still logged in. This allows them to see some blog pages that are protected by "Members Only" (another plug-in). I could maybe update Members Only or other areas to avoid this, but I would rather these users see the same behavior a normal user would see, one that just logs in with user/password, not Google. They get a nice "Your account has not been activated yet" message.
RPR has this code to authenticate, I think I need to use it from NGC some way:
public /*.object.*/ function rpr_authenticate( /*.object.*/ $user, /*.string.*/ $username, /*.string.*/ $password) {
if ( !empty($user) && !is_wp_error( $user ) ) {
if ( NULL !== get_role( 'rpr_unverified' ) && in_array( 'rpr_unverified', $user->roles ) ) {
return null;
}
}
return $user;
}
I think this is the section of NGC code I need to modify:
$secure_cookie = is_ssl();
$secure_cookie = apply_filters('secure_signon_cookie', $secure_cookie, array());
global $auth_secure_cookie; // XXX ugly hack to pass this to wp_authenticate_cookie
$auth_secure_cookie = $secure_cookie;
wp_set_auth_cookie($ID, true, $secure_cookie);
$user_info = get_userdata($ID);
do_action('wp_login', $user_info->user_login, $user_info);
do_action('nextend_google_user_logged_in', $ID, $u, $oauth2);
update_user_meta($ID, 'google_profile_picture', 'https://profiles.google.com/s2/photos/profile/' . $u['id']);
The NGC code uses what I think is a "hacked" method of log-in. It doesn't use any of the methods I have seen recommended online, like the new wp_signon or older wp_login functions.
Is what I'm trying to do a major project? If so, is there another combination of plug-ins (or a single one) that will handle the following:
Require users to be logged in to see any pages (what Members Only does)
Require admin to moderate/approve new users (what RPR does)
Support log-in via Facebook, Twitter, and Google (what the Nextend Connect plug-ins do)
Update:
I changed the NGC code to this, and now it doesn't log the user in, but it just leaves them on the log-in page with no error message. I'm not sure how I can add an error message to the default log-in page, everything I find online is related to custom log-in pages.
if ($ID) { // Login
$user_info = get_userdata($ID);
if ( !empty($user_info) && !is_wp_error( $user_info ) ) {
if ( NULL !== get_role( 'rpr_unverified' ) && in_array( 'rpr_unverified', $user_info->roles ) ) {
// TODO - How to add error message to log-in page?
return;
}
}
$secure_cookie = is_ssl();
$secure_cookie = apply_filters('secure_signon_cookie', $secure_cookie, array());
global $auth_secure_cookie; // XXX ugly hack to pass this to wp_authenticate_cookie
$auth_secure_cookie = $secure_cookie;
wp_set_auth_cookie($ID, true, $secure_cookie);
//
do_action('wp_login', $user_info->user_login, $user_info);
do_action('nextend_google_user_logged_in', $ID, $u, $oauth2);
update_user_meta($ID, 'google_profile_picture', 'https://profiles.google.com/s2/photos/profile/' . $u['id']);
}
I'm sure there is a better way to do this, one that will not be undone anytime I update the plug-in, but for now this works for me.
I updated nextend-google-connect.php, part of the Nextend Google Connect plug-in, and changed the Login code (starting around line 230 depending on your version) to this:
if ($ID) { // Login
$user_info = get_userdata($ID);
if ( !empty($user_info) && !is_wp_error( $user_info ) ) {
if ( NULL !== get_role( 'rpr_unverified' ) && in_array( 'rpr_unverified', $user_info->roles ) ) {
wp_redirect('wp-login.php?checkemail=registered');
exit;
}
}
$secure_cookie = is_ssl();
$secure_cookie = apply_filters('secure_signon_cookie', $secure_cookie, array());
global $auth_secure_cookie; // XXX ugly hack to pass this to wp_authenticate_cookie
$auth_secure_cookie = $secure_cookie;
wp_set_auth_cookie($ID, true, $secure_cookie);
do_action('wp_login', $user_info->user_login, $user_info);
do_action('nextend_google_user_logged_in', $ID, $u, $oauth2);
update_user_meta($ID, 'google_profile_picture', 'https://profiles.google.com/s2/photos/profile/' . $u['id']);
}
By redirecting to that special URL, the Redux plug-in already has code to display a nice message to the user letting them know the admin needs to verify the account.

How to do it in Mojolicious ? =>Username, Password, Salting, Encrypting, Hash - How does it all work

I am working with Mojolicious web framework to build a small site. I am aiming for strong security. The first step is to secure login information mainly username and password. I want to implement the logic given by the asker of this post Username, Password, Salting, Encrypting, Hash - How does it all work? . The username and password must be at least salted and hashed in a user's browser before they are sent to Mojolicious web server over the internet. I think the best way is to use embedded perl to manipulate the form values and then reassign them so that when 'submit' button is pressed only salted and hashed username,passwords are received inside the controller: The logic in mojolicious would be like(copied from Mojolicious website. MyUsers.pm handles login validation on server and I will tweak it to handle salted and hashed strings.)
#!/usr/bin/env perl
use Mojolicious::Lite;
use lib 'lib';
use MyUsers;
# Helper to lazy initialize and store our model object
helper users => sub { state $users = MyUsers->new };
# /?user=sri&pass=secr3t
any '/' => sub {
my $self = shift;
$self->render('login');
};
any '/' => sub {
my $self = shift;
$self->render('login');
};
any 'check_login' => sub {
my $self = shift;
# Query parameters
my $user = $self->param('user') || '';
my $pass = $self->param('pass') || '';
# Check password
return $self->render(text => "Welcome $user.")
if $self->users->check($user, $pass);
# Failed
$self->render(text => 'Wrong username or password.');
};
app->start;
__DATA__
## login.html.ep
% title 'Login Page.';
<form name="input" action="check_login" method="post">
User: <input type="text" name="user"><div>
Pass: <input type="password" name="pass"><div>
<!-- DO SOMETHING HERE to salt and hash $user and $pass before post -->
<input type="submit" value="Submit">
</form>
Finally got the solution in this excellent article link. However please be aware that there are many javascript md5 libraries. By mistake I downloaded a different md5 library than the one mentioned in the article. I wasted lot of time figuring out that the hash function did not work because I had a different md5 library. The article uses md5 lib from this link

How do I stack Plack authentication handlers?

I would like to have my Plack app try several different means of authorizing the user. Specifically, check if the user is already authorized via a session cookie, then check for Digest authentication and then fall back to Basic.
I figured I could just enable a bunch of Auth handlers in the order I wanted them to be checked (Session, Digest, Basic). Unfortunately, the way that Plack::Middleware::Auth::Digest and Plack::Middleware::Auth::Basic are written they both return 401 if digest or basic auth doesn't exist, respectively.
How is this normally dealt with in Plack?
I do not have an implementation but I think I have the approach. You can do this "in-line" with Plack::Middleware::Conditional. So it would look like this but you'll have to fill in the missing conditions/tests. I didn't see an easy/obvious way but I suspect you might. Since you have the $env to pass around you should be able to set/check HTTP_/session stuff in the order you want and keep the state for the next handler to know if it should be enabled or not.
use Plack::Builder;
my $app = sub {
[ 200,
[ "Content-Type" => "text/plain" ],
[ "O HAI, PLAK!" ]
];
};
builder {
enable "Session::Cookie";
enable_if { my $env = shift;
# I don't know...
} "Auth::Digest",
realm => "Secured", secret => "BlahBlah",
authenticator => sub { $_[0] eq $_[1] };
enable_if { my $env = shift;
# I don't know...
} "Auth::Basic",
authenticator => sub { $_[0] eq $_[1] };
$app;
};
I think you are going to need to write your own middleware, since ideally (based on a very quick read of RFC 2617) when not authenticated you would return a WWW-Authenticate header with both Basic and Digest challenges (with Basic first, for user agents that only understand Basic).