require_login - require the user to be logged in

    get '/dashboard' => require_login sub { .... };

If the user is not logged in, they will be redirected to the login page URL to log in. The default URL is "/login" - this may be changed with the "login_page" option.

require_role - require the user to have a specified role

    get '/beer' => require_role BeerDrinker => sub { ... };

Requires that the user be logged in as a user who has the specified role. If the user is not logged in, they will be redirected to the login page URL. If they are logged in, but do not have the required role, they will be redirected to the access denied URL.

If "disable_roles" configuration option is set to a true value then using "require_role" will cause the application to croak on load.

require_any_role - require the user to have one of a list of roles

    get '/drink' => require_any_role [qw(BeerDrinker VodaDrinker)] => sub {
        ...
    };

Requires that the user be logged in as a user who has any one (or more) of the roles listed. If the user is not logged in, they will be redirected to the login page URL. If they are logged in, but do not have any of the specified roles, they will be redirected to the access denied URL.

If "disable_roles" configuration option is set to a true value then using "require_any_role" will cause the application to croak on load.

require_all_roles - require the user to have all roles listed

    get '/foo' => require_all_roles [qw(Foo Bar)] => sub { ... };

Requires that the user be logged in as a user who has all of the roles listed. If the user is not logged in, they will be redirected to the login page URL. If they are logged in but do not have all of the specified roles, they will be redirected to the access denied URL.

If "disable_roles" configuration option is set to a true value then using "require_all_roles" will cause the application to croak on load.

login_template

If you are using "login_without_redirect" and assuming you are using Template::Toolkit then your custom login page should be something like this:

    <h1>Login Required</h1>

    <p>You need to log in to continue.</p>

    [%- IF login_failed -%]
        <p>LOGIN FAILED</p>
    [%- END -%]

    <form method="post">
        <label for="username">Username:</label>
        <input type="text" name="__auth_extensible_username" id="username">
        <br />
        <label for="password">Password:</label>
        <input type="password" name="__auth_extensible_password" id="password">
        <br />
        <input type="submit" value="Login">
    </form>

    [%- IF reset_password_handler -%]
    <form method="post" action="[% login_page %]">
        <h2>Password reset</h2>
        <p>Enter your username to obtain an email to reset your password</p>
        <label for="username_reset">Username:</label>
        <input type="text" name="username_reset" id="username_reset">
        <input type="submit" name="submit_reset" value="Submit">
    </form>
    [%- END -%]

If you are not using "login_without_redirect" and assuming you are using Template::Toolkit then your custom login page should be something like this:

    <h1>Login Required</h1>

    <p>You need to log in to continue.</p>

    [%- IF login_failed -%]
        <p>LOGIN FAILED</p>
    [%- END -%]

    <form method="post">
        <label for="username">Username:</label>
        <input type="text" name="username" id="username">
        <br />
        <label for="password">Password:</label>
        <input type="password" name="password" id="password">
        <br />
        <input type="submit" value="Login">

        [%- IF return_url -%]
            <input type="hidden" name="return_url" value="[% return_url %]">
        [%- END -%]

        [%- IF reset_password_handler -%]
            <h2>Password reset</h2>
            <p>Enter your username to obtain an email to reset your password</p>
            <label for="username_reset">Username:</label>
            <input type="text" name="username_reset" id="username_reset">
            <input type="submit" name="submit_reset" value="Submit">
        [%- END -%]

    </form>

Replacing the default " /login " and " /login/denied " routes

    plugins:
      Auth::Extensible:
        login_page_handler: 'My::App::login_page_handler'
        permission_denied_page_handler: 'My::App::permission_denied_page_handler'

Then in your code you might simply use a template:

    sub login_page_handler {
        my $return_url = query_parameters->get('return_url');
        template
            'account/login',
            { title => 'Sign in',
              return_url => $return_url,
            },
            { layout => 'login.tt',
            };
    }

    sub permission_denied_page_handler {
        template 'account/login';
    }

and your account/login.tt template might look like:

    [% IF vars.login_failed %]
    <div class="alert alert-danger">
        <strong>Login Failed</strong> Try again
        <button type="button" class="close" data-dismiss="alert" aria-label="Close">
            <span aria-hidden="true">&times;</span>
        </button>
    </div>
    [% END %]

    <form method = "post" lpformnum="1" class="form-signin">
        <h2 class="form-signin-heading">Please sign in</h2>
        <label for="username" class="sr-only">Username</label>
        <input type="text" name="username" id="username" class="form-control" placeholder="User name" required autofocus>
        <label for="password" class="sr-only">Password</label>
        <input type="password" name="password" id="password" class="form-control" placeholder="Password" required>
        <button class="btn btn-lg btn-primary btn-block" type="submit">Sign in</button>
        <br>
        <input type="hidden" name="return_url" value="[% return_url %]">
    </form>

If the user is logged in, but tries to access a route which requires a specific role they don't have, they will be redirected to the "permission denied" page URL, which defaults to "/login/denied" but may be changed using the "denied_page" option.

Again, by default a route is added to respond to that URL with a default page; again, you can disable this by setting "no_default_pages" and creating your own.

This would still leave the routes "post '/login'" and "any '/logout'" routes in place. To disable them too, set the option "no_login_handler" to a true value. In this case, these routes should be defined by the user, and should do at least the following:

    post '/login' => sub {
        my ($success, $realm) = authenticate_user(
            params->{username}, params->{password}
        );
        if ($success) {
            # change session ID if we have a new enough D2 version with support
            # (security best practice on privilege level change)
            app->change_session_id
                if app->can('change_session_id');
            session logged_in_user => params->{username};
            session logged_in_user_realm => $realm;
            # other code here
        } else {
            # authentication failed
        }
    };
    
    any '/logout' => sub {
        app->destroy_session;
    };

If you want to use the default "post '/login'" and "any '/logout'" routes you can configure them. See below.

The default routes also contain functionality for a user to perform password resets. See the "PASSWORD RESETS" documentation for more details.

logged_in_user

The details you get back will depend upon the authentication provider in use.

get_user_details

The details you get back will depend upon the authentication provider in use.

user_has_role

By default, the currently-logged-in user will be checked, so you need only name the role you're looking for:

    if (user_has_role('BeerDrinker')) { pour_beer(); }

You can also provide the username to check;

    if (user_has_role($user, $role)) { .... }

If "disable_roles" configuration option is set to a true value then using "user_has_role" will cause the application to croak at runtime.

user_roles

By default, roles for the currently-logged-in user will be checked; alternatively, you may supply a username to check.

Returns a list or arrayref depending on context.

If "disable_roles" configuration option is set to a true value then using "user_roles" will cause the application to croak at runtime.

authenticate_user

For example:

    if (authenticate_user($username, $password)) {
        ...
    }

If you are using multiple authentication realms, by default each realm will be consulted in turn. If you only wish to check one of them (for instance, you're authenticating an admin user, and there's only one realm which applies to them), you can supply the realm as an optional third parameter.

In boolean context, returns simply true or false; in list context, returns "($success, $realm)".

logged_in_user_lastlogin

To enable this functionality, set the configuration key "record_lastlogin" to a true value. The backend provider must support write access for a user and have lastlogin functionality implemented.

update_user

In order to update the user's details, the keyword should be called with the username to be updated, followed by a hash of the values to be updated. Note that whilst the password can be updated using this method, any new value will be stored directly into the provider as-is, not encrypted. It is recommended to use "user_password" instead.

If only one realm is configured then this will be used to search for the user. Otherwise, the realm must be specified with the realm key.

    # Update user, only one realm configured
    update_user "jsmith", surname => "Smith"

    # Update a user's username, more than one realm
    update_user "jsmith", realm => "dbic", username => "jjones"

The updated user's details are returned, as per logged_in_user.

update_current_user

    # Update user, only one realm configured
    update_current_user surname => "Smith"

The updated user's details are returned, as per logged_in_user.

create_user

This function works in the same manner as update_user, except that the username key is mandatory. As with update_user, it is recommended not to set a password directly using this method, otherwise it will be stored in plain text.

The realm to use must be specified with the key "realm" if there is more than one realm configured.

    # Create new user
    create_user username => "jsmith", realm => "dbic", surname => "Smith"

    # Create new user and send welcome email
    create_user username => "jsmith", email => "john@you.com", email_welcome => 1

On success, the created user's details are returned, as per logged_in_user.

The text sent in the welcome email can be customised in 2 ways, in the same way as password_reset_send:

welcome_send

This can be used to specify a subroutine that will be called to perform the entire message construction and email sending. Note that it must be a fully-qualified sub such as "My::App:email_welcome_send". The subroutine will be passed the dsl as the first parameter, followed by a hash with the keys "code", "email" and "user", which contain the generated reset code, user email address, and user hashref respectively. For example:

    sub reset_send_handler {
        my ($dsl, %params) = @_;
        my $user_email = $params{email};
        my $reset_code = $params{code};
        # Send email
        return $result;
    }
    

welcome_text

This can be used to generate the text for the welcome email, with this module sending the actual email itself. It must be a fully-qualified sub, as per the previous option. It will be passed the same parameters as welcome_send, and should return a hash with the same keys as password_reset_send_email.

password_reset_send

The function must be called with the key "username" and a value that is the username. The username specified will be sent an email with a link to reset their password. Note that the provider being used must return the email address in the key "email", which in the case of a database will normally require that column to exist in the user's table. The provider must be able to write values to the user in order for this function to store the generated code.

If the username is not found, a value of 0 is returned. If the username is found and the email is sent successfully, 1 is returned. Otherwise undef is returned. Note: if you are displaying a success message, and you do not want people to be able to check the existance of a user on your system, then you should check for the return value being defined, not true. For example:

    say "Success" if defined password_reset_send username => username;

Note that this still leaves the possibility of checking the existance of a user if the email send mechanism is failing.

The realm can also be specified using the key realm:

    password_reset_send username => 'jsmith', realm => 'dbic'

Default text for the email is automatically produced and emailed. This can be customized with one of 2 config parameters:

password_reset_send_email

This can be used to specify a subroutine that will be called to perform the entire message construction and email sending. Note that it must be a fully-qualified sub such as "My::App:reset_send_handler". The subroutine will be passed the dsl as the first parameter, followed by a hash with the keys "code" and "email", which contain the generated reset code and user email address respectively. For example:

    sub reset_send_handler {
        my ($dsl, %params) = @_;
        my $user_email = $params{email};
        my $reset_code = $params{code};
        # Send email
        return $result;
    }
    

password_reset_text

This can be used to generate the text for the email, with this module sending the actual email itself. It must be a fully-qualified sub, as per the previous option. It will be passed the same parameters as password_reset_send_email, and should return a hash with the following keys:

    sub reset_text_handler {
        my ($dsl, %params) = @_;
        return (
            from    => '"My name" <myapp@example.com',
            subject => 'the subject',
            plain   => "reset here: $params{code}",
        );
    }

    Auth::Extensible:
        mailer:
            module: Mail::Message # Module to send email with
            options:              # Module options
                via: sendmail
        mail_from: '"My app" <myapp@example.com>'
        password_reset_text: MyApp::reset_send

user_password

By default, the user to update is the currently logged-in user. A specific user can be specified with the key "username" for a certain username, or "code" for a previously sent reset code. Using these parameters on their own will return the username if it is a valid request.

If the above parameters are specified with the additional parameter "new_password", then the password will be set to that value, assuming that it is a valid request.

The realm can be optionally specified with the keyword "realm".

Examples:

Check the logged-in user's password:

    user_password password => 'mysecret'

Check a specific user's password:

    user_password username => 'jsmith', password => 'bigsecret'

Check a previously sent reset code:

    user_password code => 'XXXX'

Reset a password with a previously sent code:

    user_password code => 'XXXX', new_password => 'newsecret'

Change a user's password (username optional)

    user_password username => 'jbloggs', password => 'old', new_password => 'secret'

Force set a specific user's password, without checking existing password:

    user_password username => 'jbloggs', new_password => 'secret'

logged_in_user_password_expired

Note that this functionality does not prevent the user accessing any protected pages, even if the password has expired. This is so that the developer can still leave some protected routes available, such as a page to change the password. Therefore, if using this functionality, it is suggested that a check is done in the "before" hook:

    hook before => sub {
        if (logged_in_user_password_expired)
        {
            # Redirect to user details page if password expired, but only if that
            # is not the currently request page to prevent redirect loops
            redirect '/password_update' unless request->uri eq '/password_update';
        }
    }

PASSWORD RESETS

When utilising this functionality, it is wise to only allow passwords to be reset with a POST request. This is because some email scanners "open" links before delivering the email to the end user. With only a single-use GET request, this will result in the link being "used" by the time it reaches the end user, thus rendering it invalid.

Password reset functionality is also built-in to the default route handlers. To enable this, set the configuration value "reset_password_handler" to a true value (having already configured the mail handler, as per the keyword documentation above). Once this is done, the default login page will contain additional form controls to allow the user to enter their username and request a reset password link.

By default, the default handlers will generate a random 8 character password using Session::Token. To use your own function, set "password_generator" in your configuration. See the "SAMPLE CONFIGURATION" for an example.

If using "login_page_handler" to replace the default login page, you can still use the default password reset handlers. Add 2 controls to your form for submitting a password reset request: a text input called username_reset for the username, and submit_reset to submit the request. Your login_page_handler is then passed the following additional params:

new_password

Contains the new automatically-generated password, once the password reset has been performed successfully.

reset_sent

Is true when a password reset has been emailed to the user.

password_code_valid

Is true when a valid password reset code has been submitted with a GET request. In this case, the user should be given the chance to confirm with a POST request, with a form control called "confirm_reset".

For a full example, see the default handler in this module's code.

SAMPLE CONFIGURATION

    session: simple
    plugins:
        Auth::Extensible:
            # Set to 1 if you want to disable the use of roles (0 is default)
            # If roles are disabled then any use of role-based route decorators
            # will cause app to croak on load. Use of 'user_roles' and
            # 'user_has_role' will croak at runtime.
            disable_roles: 0
            # Set to 1 to use the no-redirect login functionality
            login_without_redirect: 0
            # Set the view name for a custom login page, defaults to 'login'
            login_template: login
            # After /login: If no return_url is given: land here ('/' is default)
            user_home_page: '/user'
            # After /logout: If no return_url is given: land here (no default)
            exit_page: '/'

            # Mailer options for reset password and welcome emails
            mailer:
                module: Mail::Message # Email module to use
                options:              # Options for module
                    via: sendmail     # Options passed to $msg->send
            mail_from: '"App name" <myapp@example.com>' # From email address

            # Set to true to enable password reset code in the default handlers
            reset_password_handler: 1
            password_generator: My::App::random_pw # Optional random password generator

            # Set to a true value to enable recording of successful last login times
            record_lastlogin: 1

            # Password reset functionality
            password_reset_send_email: My::App::reset_send # Customise sending sub
            password_reset_text: My::App::reset_text # Customise reset text

            # create_user options
            welcome_send: My::App::welcome_send # Customise welcome email sub
            welcome_text: My::App::welcome_text # Customise welcome email text

            # List each authentication realm, with the provider to use and the
            # provider-specific settings (see the documentation for the provider
            # you wish to use)
            realms:
                realm_one:
                    priority: 3 # Defaults to 0. Realms are checked in descending order
                    provider: Database
                        db_connection_name: 'foo'
                realm_two:
                    priority: 0 # Will be checked after realm_one
                    provider: Config

Please note that you must have a session provider configured. The authentication framework requires sessions in order to track information about the currently logged in user. Please see Dancer2::Core::Session for information on how to configure session management within your application.

auth_provider($dsl, $realm)

before_authenticate_user

Receives a hash reference of "username", "password" and "realm".

after_authenticate_user

Receives a hash reference of "username", "password", "realm", "errors" and "success".

"realm" is the realm that the user authenticated against of undef if auth failed.

The value of "errors" is an array reference of any errors thrown by authentication providers (if any).

The value of "success" is either 1 or 0 to show whether or not authentication was successful.

before_create_user

Receives a hash reference of the arguments passed to "create_user".

after_create_user

Receives the requested username, the created user (or undef) and an array reference of any errors from the main method or from the provider.

login_required

permission_denied

after_reset_code_success

after_login_success

before_logout