/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::Auth

NAME

Developer::Dashboard::Auth - local auth and trust-tier handling

SYNOPSIS

my $auth = Developer::Dashboard::Auth->new(files => $files, paths => $paths);
my $user = $auth->verify_user(username => 'mvu', password => 'example-pass-123');

DESCRIPTION

This module implements the local-first trust model for Developer Dashboard. Loopback requests using loopback-local hosts such as 127.0.0.1, localhost, or configured local alias names can be treated as trusted admin access, while other requests authenticate through file-backed helper user records.

METHODS

new

Construct an auth manager.

trust_tier, add_user, verify_user, get_user, list_users, remove_user, login_page, helper_users_enabled

Manage trust decisions, helper users, and login UI.

PURPOSE

This module owns helper-user authentication. It stores helper users in the runtime, verifies passwords, renders login-page state, and applies the access rules that distinguish local admin access from helper-user access for non-loopback clients.

WHY IT EXISTS

It exists because authentication policy should not be scattered across route code. Centralizing helper-user verification and login-page behavior keeps the auth boundary explicit and makes it possible to test the outsider-versus-helper rules directly.

WHEN TO USE

Use this file when changing helper password requirements, login-page messaging, user storage, or the verification logic that decides whether a submitted helper login is valid.

HOW TO USE

Construct it with the runtime file and path registries, then use methods such as add_user, verify_user, list_users, and login_page. Route handlers should call into this module instead of parsing auth data themselves.

WHAT USES IT

It is used by the web app login flow, by CLI helper-user administration commands, by session/bootstrap logic that decides whether outsider access should be challenged, and by focused auth regression tests.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::Auth -e 1

Do a direct compile-and-load check against the module from a source checkout.

Example 2:

prove -lv t/03-web-app.t t/08-web-update-coverage.t

Run the focused regression tests that most directly exercise this module's behavior.

Example 3:

HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t

Recheck the module under the repository coverage gate rather than relying on a load-only probe.

Example 4:

prove -lr t

Put any module-level change back through the entire repository suite before release.