{"id":28614206,"url":"https://github.com/perldancer/dancer2-plugin-auth-extensible-provider-database","last_synced_at":"2026-05-13T13:51:20.763Z","repository":{"id":56830978,"uuid":"55142526","full_name":"PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Database","owner":"PerlDancer","description":"Dancer2::Plugin::Database provider for Dancer2-Plugin-Auth-Extensible","archived":false,"fork":false,"pushed_at":"2019-02-28T11:15:12.000Z","size":397,"stargazers_count":2,"open_issues_count":4,"forks_count":2,"subscribers_count":13,"default_branch":"master","last_synced_at":"2025-06-12T01:13:35.935Z","etag":null,"topics":["dancer2","database"],"latest_commit_sha":null,"homepage":null,"language":"Perl","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/PerlDancer.png","metadata":{"files":{"readme":"README","changelog":"Changes","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-03-31T10:37:47.000Z","updated_at":"2019-03-03T16:46:37.000Z","dependencies_parsed_at":"2022-09-09T16:23:56.365Z","dependency_job_id":null,"html_url":"https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Database","commit_stats":null,"previous_names":[],"tags_count":21,"template":false,"template_full_name":null,"purl":"pkg:github/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Database","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PerlDancer%2FDancer2-Plugin-Auth-Extensible-Provider-Database","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PerlDancer%2FDancer2-Plugin-Auth-Extensible-Provider-Database/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PerlDancer%2FDancer2-Plugin-Auth-Extensible-Provider-Database/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PerlDancer%2FDancer2-Plugin-Auth-Extensible-Provider-Database/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/PerlDancer","download_url":"https://codeload.github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Database/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PerlDancer%2FDancer2-Plugin-Auth-Extensible-Provider-Database/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279017499,"owners_count":26086085,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-13T02:00:06.723Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dancer2","database"],"created_at":"2025-06-12T01:13:25.217Z","updated_at":"2025-10-14T01:42:02.139Z","avatar_url":"https://github.com/PerlDancer.png","language":"Perl","funding_links":[],"categories":[],"sub_categories":[],"readme":"NAME\n\n    Dancer2::Plugin::Auth::Extensible::Provider::Database - authenticate\n    via a database\n\nDESCRIPTION\n\n    This class is an authentication provider designed to authenticate users\n    against a database, using Dancer2::Plugin::Database to access a\n    database.\n\n    Crypt::SaltedHash is used to handle hashed passwords securely; you\n    wouldn't want to store plain text passwords now, would you? (If your\n    answer to that is yes, please reconsider; you really don't want to do\n    that, when it's so easy to do things right!)\n\n    See Dancer2::Plugin::Database for how to configure a database\n    connection appropriately; see the \"CONFIGURATION\" section below for how\n    to configure this authentication provider with database details.\n\n    See Dancer2::Plugin::Auth::Extensible for details on how to use the\n    authentication framework, including how to pick a more useful\n    authentication provider.\n\nCONFIGURATION\n\n    This provider tries to use sensible defaults, so you may not need to\n    provide much configuration if your database tables look similar to\n    those in the \"SUGGESTED SCHEMA\" section below.\n\n    The most basic configuration, assuming defaults for all options, and\n    defining a single authentication realm named 'users':\n\n        plugins:\n            Auth::Extensible:\n                realms:\n                    users:\n                        provider: 'Database'\n\n    You would still need to have provided suitable database connection\n    details to Dancer2::Plugin::Database, of course; see the docs for that\n    plugin for full details, but it could be as simple as, e.g.:\n\n        plugins:\n            Auth::Extensible:\n                realms:\n                    users:\n                        provider: 'Database'\n            Database:\n                driver: 'SQLite'\n                database: 'test.sqlite'\n                on_connect_do: ['PRAGMA foreign_keys = ON']\n                dbi_params:\n                    PrintError: 0\n                    RaiseError: 1\n\n    A full example showing all options:\n\n        plugins:\n            Auth::Extensible:\n                realms:\n                    users:\n                        provider: 'Database'\n                        # optionally set DB connection name to use (see named\n                        # connections in Dancer2::Plugin::Database docs)\n                        db_connection_name: 'foo'\n    \n                        # Optionally disable roles support, if you only want to check\n                        # for successful logins but don't need to use role-based access:\n                        disable_roles: 1\n    \n                        # optionally specify names of tables if they're not the defaults\n                        # (defaults are 'users', 'roles' and 'user_roles')\n                        users_table: 'users'\n                        roles_table: 'roles'\n                        user_roles_table: 'user_roles'\n    \n                        # optionally set the column names (see the SUGGESTED SCHEMA\n                        # section below for the default names; if you use them, they'll\n                        # Just Work)\n                        users_id_column: 'id'\n                        users_username_column: 'username'\n                        users_password_column: 'password'\n                        roles_id_column: 'id'\n                        roles_role_column: 'role'\n                        user_roles_user_id_column: 'user_id'\n                        user_roles_role_id_column: 'roles_id'\n\n    See the main Dancer2::Plugin::Auth::Extensible documentation for how to\n    configure multiple authentication realms.\n\nSUGGESTED SCHEMA\n\n    If you use a schema similar to the examples provided here, you should\n    need minimal configuration to get this authentication provider to work\n    for you.\n\n    The examples given here should be MySQL-compatible; minimal changes\n    should be required to use them with other database engines.\n\n users table\n\n    You'll need a table to store user accounts in, of course. A suggestion\n    is something like:\n\n        CREATE TABLE users (\n            id       INTEGER     AUTO_INCREMENT PRIMARY KEY,\n            username VARCHAR(32) NOT NULL       UNIQUE KEY,\n            password VARCHAR(40) NOT NULL\n        );\n\n    You will quite likely want other fields to store e.g. the user's name,\n    email address, etc; all columns from the users table will be returned\n    by the logged_in_user keyword for your convenience.\n\n roles table\n\n    You'll need a table to store a list of available roles in (unless\n    you're not using roles - in which case, disable role support (see the\n    \"CONFIGURATION\" section).\n\n        CREATE TABLE roles (\n            id    INTEGER     AUTO_INCREMENT PRIMARY KEY,\n            role  VARCHAR(32) NOT NULL\n        );\n\n user_roles table\n\n    Finally, (unless you've disabled role support) you'll need a table to\n    store user \u003c-\u003e role mappings (i.e. one row for every role a user has;\n    so adding extra roles to a user consists of adding a new role to this\n    table). It's entirely up to you whether you use an \"id\" column in this\n    table; you probably shouldn't need it.\n\n        CREATE TABLE user_roles (\n            user_id  INTEGER  NOT NULL,\n            role_id  INTEGER  NOT NULL,\n            UNIQUE KEY user_role (user_id, role_id)\n        );\n\n    If you're using InnoDB tables rather than the default MyISAM, you could\n    add a foreign key constraint for better data integrity; see the MySQL\n    documentation for details, but a table definition using foreign keys\n    could look like:\n\n        CREATE TABLE user_roles (\n            user_id  INTEGER, FOREIGN KEY (user_id) REFERENCES users (id),\n            role_id  INTEGER, FOREIGN KEY (role_id) REFERENCES roles (id),\n            UNIQUE KEY user_role (user_id, role_id)\n        ) ENGINE=InnoDB;\n\nATTRIBUTES\n\n dancer2_plugin_database\n\n    Lazy-loads the correct instance of Dancer2::Plugin::Database which\n    handles the following methods:\n\n      * plugin_database\n\n      This corresponds to the database keyword from\n      Dancer2::Plugin::Database.\n\n database\n\n    The connected \"plugin_database\" using \"db_connection_name\".\n\n db_connection_name\n\n    Optional.\n\n users_table\n\n    Defaults to 'users'.\n\n users_id_column\n\n    Defaults to 'id'.\n\n users_username_column\n\n    Defaults to 'username'.\n\n users_password_column\n\n    Defaults to 'password'.\n\n roles_table\n\n    Defaults to 'roles'.\n\n roles_id_column\n\n    Defaults to 'id'.\n\n roles_role_column\n\n    Defaults to 'role'.\n\n user_roles_table\n\n    Defaults to 'user_roles'.\n\n user_roles_user_id_column\n\n    Defaults to 'user_id'.\n\n user_roles_role_id_column\n\n    Defaults to 'role_id'.\n\nMETHODS\n\n authenticate_user $username, $password\n\n create_user\n\n get_user_details $username\n\n get_user_roles $username\n\n set_user_details\n\n set_user_password\n\nCOOKBOOK\n\n Handle locked or disabled user accounts\n\n    (contributed by PerlDuck, Borodin and simbabque via Stack Overflow\n    \u003chttps://stackoverflow.com/questions/46746864\u003e)\n\n    It's a good practice to not delete certain data, like user accounts.\n    But what do you do when you want to get rid of a user? Maybe an\n    employee left or was temporary suspended, or a user did not pay their\n    subscription fee. In those cases you would want the user data to stay\n    around, but they should not be able to log in any more.\n\n    Let's say there is a column disabled in an already existing user table.\n    It might hold a timestamp for when the user was disabled, and be NULL\n    if the user is active. By default, Dancer2::Plugin::Auth::Extensible\n    will give you this information as part of the user data, but to check\n    if the user is allowed to proceed would happen after the password has\n    been checked and they have already been logged in.\n\n    The following sections will describe two different ways of implementing\n    this. The first one is easier to implement, but only allows read\n    operations on the user table, while the second one requires a little\n    more effort, but will allow almost all operations to work. If you need\n    even more flexibility you will have to subclass and add a bit more\n    logic.\n\n  ... without changing any code\n\n    An easy way to achieve this is by adding a new view to your database\n    that only shows active users. Let's look at the following example\n    database.\n\n        -- user table\n        CREATE TABLE users (\n            id       INTEGER     PRIMARY KEY AUTOINCREMENT,\n            username VARCHAR(32) NOT NULL UNIQUE,\n            password VARCHAR(40) NOT NULL,\n            disabled TIMESTAMP   NULL\n        );\n    \n        -- active user view\n        CREATE VIEW active_users (id, username, password) AS\n            SELECT id, username, password FROM users WHERE disabled IS NULL;\n    \n        -- some data\n        INSERT INTO users ( username, password, disabled )\n        VALUES  ( 'Alice', 'test', null),\n                ( 'Bob', 'test', '2017-10-01 10:10:10');\n\n    Now all you need to do is change the \"users_table\" setting to point to\n    active_users instead of users.\n\n        # config.yml\n        plugins:\n            Auth::Extensible:\n                realms:\n                    users:\n                        provider: 'Database'\n                        users_table: 'active_users'\n\n    That's it. Your application will now only let active users log in,\n    because it has no way of knowing about the others. Only Alice will be\n    able to log in, but Bob has been disabled and the application will not\n    allow him to log in.\n\n    But be aware that this comes with a few drawbacks. If you want to use\n    Dancer2::Plugin::Auth::Extensible to also update user information, this\n    is now no longer possible because in most database engines you cannot\n    write data into a view.\n\n  ... by creating a subclass of this database provider\n\n    The alternative is to subclass this provider to add a little bit of\n    logic. You can add code to exclude users directly when the user data is\n    fetched, even before Dancer2::Plugin::Auth::Extensible verifies the\n    password. This way, inactive users can easily be discarded.\n\n    The following code is an example implementation specifically for the\n    user table outlined in the alternative solution above.\n\n        package Provider::Database::ActiveOnly;\n    \n        use Moo;\n        extends 'Dancer2::Plugin::Auth::Extensible::Provider::Database';\n    \n        around 'get_user_details' =\u003e sub {\n            my $orig = shift;\n            my $self = shift;\n    \n            # do nothing if we there was no user\n            my $user = $self-\u003e$orig(@_) or return;\n    \n            # do nothing if the user is disabled\n            return if $user-\u003e{disabled};\n    \n            return $user;\n        };\n    \n        1;\n\n    The code uses an around modifier from Moo to influence the\n    get_user_details method, so users that are disabled are never found.\n\n    To enable this new provider, you need to change the provider setting in\n    your configuration.\n\n        # config.yml\n        plugins:\n            Auth::Extensible:\n                realms:\n                    users:\n                        provider: 'Provider::Database::ActiveOnly'\n                        users_table: 'users'  # this is the default\n\n    With this custom subclass your application will be able to perform\n    write operations on active users, including making them inactive.\n    However, inactive users will be invisible to\n    Dancer2::Plugin::Auth::Extensible, so you cannot use this to turn\n    inactive users back on.\n\n    If you want that functionality, you will have to add a bit more logic\n    to your subclass. A possible approach could be to replace the\n    \"authenticate_user\" method.\n\nAUTHOR\n\n    David Precious, \u003cdavidp at preshweb.co.uk\u003e\n\n    Dancer2 port of Dancer::Plugin::Auth::Extensible by:\n\n    Stefan Hornburg (Racke), \u003cracke at linuxia.de\u003e\n\n    Conversion to Dancer2's new plugin system in 2016 by:\n\n    Peter Mottram (SysPete), \u003cpeter at sysnix.com\u003e\n\nBUGS / FEATURE REQUESTS\n\n    This is an early version; there may still be bugs present or features\n    missing.\n\n    This is developed on GitHub - please feel free to raise issues or pull\n    requests against the repo at:\n    https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible-Provider-Database\n\nACKNOWLEDGEMENTS\n\n    From Dancer2::Plugin::Auth::Extensible:\n\n    Valuable feedback on the early design of this module came from many\n    people, including Matt S Trout (mst), David Golden (xdg), Damien\n    Krotkine (dams), Daniel Perrett, and others.\n\n    Configurable login/logout URLs added by Rene (hertell)\n\n    Regex support for require_role by chenryn\n\n    Support for user_roles looking in other realms by Colin Ewen (casao)\n\n    LDAP provider added by Mark Meyer (ofosos)\n\n    Documentation fix by Vince Willems.\n\n    Henk van Oers (GH #8, #13).\n\n    Andrew Beverly (GH #6, #7, #10, #17, #22, #24, #25, #26). This includes\n    support for creating and editing users and manage user passwords.\n\n    Gabor Szabo (GH #11, #16, #18).\n\n    Evan Brown (GH #20, #32).\n\n    Jason Lewis (Unix provider problem, typo fix).\n\n    Yanick Champoux (typo fix).\n\nLICENSE AND COPYRIGHT\n\n    Copyright 2012-16 David Precious. Copyright 2017-19 Stefan Hornburg\n    (Racke).\n\n    This program is free software; you can redistribute it and/or modify it\n    under the terms of either: the GNU General Public License as published\n    by the Free Software Foundation; or the Artistic License.\n\n    See http://dev.perl.org/licenses/ for more information.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fperldancer%2Fdancer2-plugin-auth-extensible-provider-database","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fperldancer%2Fdancer2-plugin-auth-extensible-provider-database","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fperldancer%2Fdancer2-plugin-auth-extensible-provider-database/lists"}