view release on metacpan or  search on metacpan

README  view on Meta::CPAN

 db_connection_name

    Optional.

 users_table

    Defaults to 'users'.

 users_id_column

    Defaults to 'id'.

 users_username_column

    Defaults to 'username'.

 users_password_column

    Defaults to 'password'.

 roles_table

    Defaults to 'roles'.

 roles_id_column

    Defaults to 'id'.

 roles_role_column

    Defaults to 'role'.

 user_roles_table

    Defaults to 'user_roles'.

 user_roles_user_id_column

    Defaults to 'user_id'.

 user_roles_role_id_column

    Defaults to 'role_id'.

METHODS

 authenticate_user $username, $password

 create_user

 get_user_details $username

 get_user_roles $username

 set_user_details

 set_user_password

COOKBOOK

 Handle locked or disabled user accounts

    (contributed by PerlDuck, Borodin and simbabque via Stack Overflow
    <https://stackoverflow.com/questions/46746864>)

    It's a good practice to not delete certain data, like user accounts.
    But what do you do when you want to get rid of a user? Maybe an
    employee left or was temporary suspended, or a user did not pay their
    subscription fee. In those cases you would want the user data to stay
    around, but they should not be able to log in any more.

    Let's say there is a column disabled in an already existing user table.
    It might hold a timestamp for when the user was disabled, and be NULL
    if the user is active. By default, Dancer2::Plugin::Auth::Extensible
    will give you this information as part of the user data, but to check
    if the user is allowed to proceed would happen after the password has
    been checked and they have already been logged in.

    The following sections will describe two different ways of implementing
    this. The first one is easier to implement, but only allows read
    operations on the user table, while the second one requires a little
    more effort, but will allow almost all operations to work. If you need
    even more flexibility you will have to subclass and add a bit more
    logic.

  ... without changing any code

    An easy way to achieve this is by adding a new view to your database
    that only shows active users. Let's look at the following example
    database.

        -- user table
        CREATE TABLE users (
            id       INTEGER     PRIMARY KEY AUTOINCREMENT,
            username VARCHAR(32) NOT NULL UNIQUE,
            password VARCHAR(40) NOT NULL,
            disabled TIMESTAMP   NULL
        );
    
        -- active user view
        CREATE VIEW active_users (id, username, password) AS
            SELECT id, username, password FROM users WHERE disabled IS NULL;
    
        -- some data
        INSERT INTO users ( username, password, disabled )
        VALUES  ( 'Alice', 'test', null),
                ( 'Bob', 'test', '2017-10-01 10:10:10');

    Now all you need to do is change the "users_table" setting to point to
    active_users instead of users.

        # config.yml
        plugins:
            Auth::Extensible:
                realms:
                    users:
                        provider: 'Database'
                        users_table: 'active_users'

    That's it. Your application will now only let active users log in,
    because it has no way of knowing about the others. Only Alice will be