I intended to comment sooner and forgot to do so.... so late to the party but here are some things that I think might be helpful:

One of the overarching goals of a MVC framework is to keep the controller as thin as possible. You want to push environmental decisions to configuration that can be decided at build time, business logic into the model, and leave in your application just startup decisions, and routes with thin controllers that just wire end points to the model, while passing the results through to the appropriate views.

In your application there's an opportunity to simplify your controller subs (the hybrid route / controller subs) by abstracting the business logic into its own module that can be accessed through a helper. I prefer to have helpers for physical resources such as storage, database, etc, that get instantiated at startup, and other helpers for business logic that, when instantiated, have the physical resource objects injected through their constructors. Dependency injection. That allows testing to happen in isolation of various components. But the biggest win is that by keeping the controllers thin, you can to a large degree look upon the framework as just one way of presenting your model. If next week you decided that you wanted to go with CGI or Catalyst or Dancer, the model shouldn't have to change at all.

A small reference app that demonstrates this might be something like:

#!/usr/bin/env perl
use Mojolicious::Lite;
use Time::HiRes 'time';
use FindBin qw($Bin);
use lib "$Bin/lib";

my $startup = time;

plugin Config => {file => "$Bin/my-hello-app.beta.conf"};

helper storage => sub {
    # instantiate a storage class; filesystem, database, or in-memory 
+based on config...
    # As long as the present the same interface, it doesn't matter.
};

helper useragent => sub {return state $ua = Mojo::UserAgent->new;};

helper myhello => sub {
    my $c = shift;

    return state $hello_obj = do {
        require Model::Hello;
        Model::Hello->new(
            storage     => $c->storage,
            ua          => $c->useragent,
        );
    };
};

get '/hello' => sub {
    my $c = shift;
    $c->render(json => $c->myhello->hello);
};

get '/_live' => sub { shift->render( json => { alive_since => (time - 
+$startup) } ) };

app->start;
[download]

This does not demonstrate an actual Model class.

Now look how small your controller subs have become. Of course this is just a hello, but the controller can pass to the model calls whatever stash / param values it needs to. The application doesn't deal directly with storage, either, making the model and the application easier to test.

The other things I wanted to mention: Mojolicious comes with a user agent. No need to bring in LWP::UserAgent. And it includes its own testing framework:

#!/usr/bin/env perl

use Test::More;
use Test::Mojo;
use FindBin qw($Bin);
use lib "$Bin/../lib";

my $t = Test::Mojo->new(Mojo::File->new("$Bin/../hello"));

$t->get_ok('/_live')
    ->status_is(200)
    ->json_has('/alive_since');

$t->get_ok('/hello')
    ->status_is(200)
    ->json_is({success => 1, code => 200, message => 'OK'});

done_testing();
[download]

Greetings! And paraphrasing a famous quote: For those about to web (with Mojolicious) - we salute you!

First of all, as of common good practices of programming, you should avoid duplicate code. You have three chunks in your code that do the same thing - shows "401 unauthorised" and do some logging about it. So, make it in one place. Like this:

helper deny_with_message => sub {
  my $self = shift;
  my $message = shift;
  $self->app->log->warn($message);
  $self->render(
    status => 401,
    text   => 'unauthorized',
  );
};
[download]

And then you could invoke it like this:

And then about under... People already told you to use under, I could only support this in some usual cases, though, in my opinion, in your particular case using under will not make your code readable or more logical - it will be sugar for sugar. Using under is great when you have usual web application with login page and many many pages that is under one and the same check (like, "do we have a cookie?"). Your case is different - there's one page that checks IP, login and password, and another page that checks session cookie. So you'll have to use two under subs which, again, will not make your code ligher or more readable.

I'm using under myself, both in session-cookie-based apps and in JWT-based apps, and it's great in apps with whole lot of pages that could be viewed after one same check, but I'm doubt that your code will be better if you rewrite your app with under. So just refactor your code to not repeat itself and you'll be fine.

P.S.: If you're didn't saw this already, I recommend you to see Mojocasts.

I unfortunately don't have the time to dig into this in detail right now, so for now just a few short comments: I posted an example Mojo app with login support here (which I expanded on a bit here), it shows the use of under as suggested by the AM - I also strongly recommend you refactor your authentication code out of the handlers, that'll make for a better design. Also, don't use Basic Authentication, at least use Digest Authentication; there's Mojolicious::Plugin::DigestAuth but I haven't tried this myself yet. More of my Mojo examples are on my scratchpad.

Thanks Anonymous Monk for the hint,

I looked at Under and it seems powerful, maybe a bit too much framew-orcish at the moment. Or, if you prefere, too much sugar for my taste. Surely for my ignorance but when I see my $foo = $r->under('/foo')->to('foo#baz'); I cannot see immediately what is passing on.

But anyway thanks for the hint; something to study.

But, if I dont misunderstand myself, I have not duplicated code in the actual code: the IP check and the authentication only happens in get_first while in get_second only a cookie is checked, no?

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

But, if I dont misunderstand myself, I have not duplicated code in the actual code: the IP check and the authentication only happens in get_first while in <c>get_second only a cookie is checked, no?

Well yes, but since http is stateless, what happens if get_second gets called first?

I'm developing some Mojolicious::Lite apps at the time, and my layout is as follows

#!/usr/bin/perl

use Mojolicious::Lite;
use Foo::Blargh; # yadda yadda, other usefull stuff

get "/login" => sub {
    my $c = shift; # $c is the controller object
    $c->render('login'); # renders templates/login.html.ep
};

# this sub checks username and password
post "/login" => sub {
    validate_user(shift); # the sub gets the controller
};

get "/logout" => sub {
    my $c = shift;
    $c->cookie(MySession => 'none'); # unset cookie
    $c->redirect_to("/login");
};

# with the following, all following routes require 
# a logged-in user and a proper cookie

under sub {
    validate_cookie(shift);
};

# more routes
get "/foo" => sub {
    my $c = shift;
    ...
    $c->render($whatever);
};
get "/bar" => sub {
    my $c = shift;
    ...
    $c->render($something_else);
};

# all set up, start the application;
app->start;

###
##
# subs

sub validate_cookie {
    my $c = shift;
    my $cookie = $c->cookie('MySession');
    if (! $cookie) {
        $c->redirect_to('/login');
        return; # important!
    } else {
        # more checks to see if cookie is valid
        ...
    }
    1;
}

sub validate_user {
    my $c = shift;
    my $u = $c->param('user');
    my $p = $c->param('pass');
    if ( login($u,$p) ) {
        # set cookie. Multiple cookies can be set by calling
        # $c->cookie() with other key/value pairs more than 1 time
        $c->cookie(MySession => generate_cookie() );
        $c->redirect_to('/foo'); # whatever is appropriate
        return;
    }
    $c->stash(error => 'wrong user or password'); # gets rendered in /
+login
    $c->render('login');
    return;
}

sub login {
    # validate user and password: database, ldap, ...
    # returns 1 on success, nothing on failure
}

sub generate_cookie {
    my $n = shift || 42;
    my @chars = ('A'..'Z','a'..'z',0..9,'+','/' ); # we use the BASE64
+ chars
    join '', map{ $chars[rand @chars] }1..$n; # session ID
}
[download]

Works for me ;-)

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Hi Discipulus,

I have really looked forward to assisting you in some trivial matter because of the MAJOR enlightenment and joy you add to Perlmonks!!

You really need to look at under because it is exactly what you want, I'm pretty sure!

I'll try to provide some code specific to your example, but this is from a small web site (like 200 occasional users)

my $onlyLoggedIn = $r->under('/admin' => \&loggedIn);
$onlyLoggedIn->post('uploadFile')->to('files#insert');
$onlyLoggedIn->delete('files')->to('files#delete');

sub loggedIn {
    my $c = shift;
    if ($c->session('login')) {
        return 1;
    }
    $c->render(
        template => 'login',
        title => 'website title',
        status => 401,
    );
    return 0;
};

# elsewhere

sub login {
    my $self = shift;
    my $name = $self->param('user');
    my $password = $self->param('password');
    my $responseCode = 401;

        # Pretty sure this hashes the param and checks it against the 
+hashed database entry
    if (Something::Model::Users::login($name,$password)) {
        # $self->signed_cookie(loggedIn => 1);
        $self->session(expiration => 60*60*10);
        $self->session(login => $name);
        $responseCode = 200;
        $self->app->log->warn("$name logged in.");
    } else {
        $self->app->log->warn("Invalid login - '$name'");
    }
    $self->render(data => '',status => $responseCode);
}
[download]

So we have all urls /admin/whatever for only authenticated users.

Something I recently learned

    $self->helper( onlyauth => sub {
        my ($c,$block) = @_;
        if ($c->session('login')) {
            return $block->() if $block;
        }
    });
[download]

So I can use this in my templates!! I have an admin bar at the top of every regular page that only logged in users see

%= onlyauth begin
    %= include 'adminbar'
% end
[download]

#!/usr/bin/env perl
#server.pl
use strict;
use warnings;

use Mojolicious::Lite;

plugin 'ClientIP';
plugin 'basic_auth_plus';

# sample data for authentication
my %accepted_IPs = ( '10.0.0.3' => 1 );
my %users        = ( usr1      => 'pwd1', usr2 => 'pwd2' );

# sample data to send back to client
my $text_a = 'Né più mai toccherò le sacre sponde';
my $text_b = 'ove il mio corpo fanciulletto giacque,';

# I expect all non specified routes to answer 404, right?

sub checkUserPW {
    my $self = shift;
    my ($href, $auth_ok) = $self->basic_auth(
        realm => sub { 
            if ( exists $users{$_[0]} and  $users{$_[0]} eq $_[1]){
                return 1;
            }
            return 0;
    });
}

sub checkIP {
    my $c = shift;
    my $remote_IP = $c->client_ip;
    if (exists $accepted_IPs{$remote_IP}) {
        return 1;
    }
    return 0;
}

sub checkCreds {
    my $c = shift;
    return 1 if ( checkIP($c) && checkUserPW($c) );
    return 0;
}

under sub {
    my $c = shift;
    return 1 if checkCreds($c);
    $c->render(status => 401, text => 'not ok');
    return undef;
};

get 'get_first' => sub {
    my $c = shift;
    return $c->render(text => $text_a);
};

get 'get_second' => sub {
    my $c = shift;
    return $c->render(text => $text_b);
};

app->start;
[download]

./client.pl
FIRST REQUEST

[2020-06-16 22:30:43.75375] [7657] [debug] [siQnjFJG] GET "/get_first"
[2020-06-16 22:30:43.75403] [7657] [debug] [siQnjFJG] Routing to a cal
+lback
[2020-06-16 22:30:43.75436] [7657] [debug] [siQnjFJG] Routing to a cal
+lback
[2020-06-16 22:30:43.75466] [7657] [debug] [siQnjFJG] 200 OK (0.000877
+s, 1140.251/s)
HTTP/1.1 200 OK
Date: Wed, 17 Jun 2020 03:30:43 GMT
Server: Mojolicious (Perl)
Content-Length: 38
Content-Type: text/html;charset=UTF-8
Client-Date: Wed, 17 Jun 2020 03:30:43 GMT
Client-Peer: 10.0.0.3:3000
Client-Response-Num: 1

Né più mai toccherò le sacre sponde
SECOND REQUEST

[2020-06-16 22:30:46.76167] [7657] [debug] [rq4czVSf] GET "/get_second
+"
[2020-06-16 22:30:46.76195] [7657] [debug] [rq4czVSf] Routing to a cal
+lback
[2020-06-16 22:30:46.76231] [7657] [debug] [rq4czVSf] 401 Unauthorized
+ (0.000614s, 1628.664/s)
HTTP/1.1 401 Unauthorized
Date: Wed, 17 Jun 2020 03:30:46 GMT
Server: Mojolicious (Perl)
WWW-Authenticate: Basic realm="realm"
Content-Length: 6
Content-Type: text/html;charset=UTF-8
Client-Date: Wed, 17 Jun 2020 03:30:46 GMT
Client-Peer: 10.0.0.3:3000
Client-Response-Num: 1

not ok

ATTENTION: next should fail..

[2020-06-16 22:30:49.77717] [7657] [debug] [DknpCqhV] GET "/get_second
+"
[2020-06-16 22:30:49.77744] [7657] [debug] [DknpCqhV] Routing to a cal
+lback
[2020-06-16 22:30:49.77780] [7657] [debug] [DknpCqhV] 401 Unauthorized
+ (0.000613s, 1631.321/s)
HTTP/1.1 401 Unauthorized
Date: Wed, 17 Jun 2020 03:30:49 GMT
Server: Mojolicious (Perl)
WWW-Authenticate: Basic realm="realm"
Content-Length: 6
Content-Type: text/html;charset=UTF-8
Client-Date: Wed, 17 Jun 2020 03:30:49 GMT
Client-Peer: 10.0.0.3:3000
Client-Response-Num: 1

not ok
[download]

I tested with  morbo server.pl. A small prod deployment server.pl daemon -m production -l http://ip:port. The string MfmL-Zeg is per HTTP request I believe. So you can track through a complicated HTTP session that spawns a bunch of requests.

Hello trippledubs and many thanks for your full, tested example,

it is not exactly the cleaner replication of mine: infact i suspect that you used the client I proposed in the original post, and if so, the client does not send username and password in the second request because it received back a valid cookie. You never get ove il mio corpo fanciulletto giacque, printed. My get_second only checks this cookie, not credentials. The third request made by the client was there only to check the cookie corectly expired, so it has to fail. But these are details and your code is clean and a good example to show.

About under : it shows to be a powerful tecnique but, if I'm permitted, even too much. I mean: the code will result shorter and cleaner and very DRY, but imagine what happens if you have two or three screenful of routes: then after one month you get back at the code to review route_105 which is affected by under one but you dont see it.. Is the typical situation I will hate, like a no warnings put in the middle of a long code, with global effect..

So I'd probably go for something like (DRY code at the cost of WET comments.. ;)

# see UNDER above
get 'get_first' => sub {
    my $c = shift;
    return $c->render(text => $text_a);
};

# see UNDER above
get 'get_second' => sub {
    my $c = shift;
    return $c->render(text => $text_b);
};
[download]

Or put them in a group like shown in the tutorial:

# Admin section
group {

  # Local logic shared only by routes in this group
  under '/admin' => sub {
    my $c = shift;
    return 1 if $c->req->headers->header('X-Awesome');
    $c->render(text => "You're not awesome enough.");
    return undef;
  };

  # GET /admin/dashboard
  get '/dashboard' => {text => 'Nothing to see here yet.'};
};
[download]

But the last example raise another question in my mind: why the comment # GET /admin/dashboard ?? Is not /dashboard the route defined? Or... under means: all routes logically under the specified one ( like in under '/admin' ) and, if not specified logically under the root like under '/'?

If the above assumption is correct I'd really like to know where it is explained.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

why the comment # GET /admin/dashboard ??

Under is a superset of nested routing. Nested routes create prefixes (with / prefix implicit), but under also runs code after matching the prefix but before dispatching the request further down the chain.

?? using LWP::UserAgent ??

:D

perl -Mojo -e " print g(q{http://user:pass@10.0.0.1/get_first})->to_st
+ring "
[download]