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 IPs such as 127.0.0.1 or ::1, explicitly configured local alias names, or the well-known hostnames localhost, localhost.localdomain, localhost6, and localhost6.localdomain6 can be treated as trusted admin access, while all other requests authenticate through file-backed helper user records.
DNS-rebinding protection: hostnames that merely resolve to loopback addresses via DNS are NOT granted admin trust. Only the well-known local-machine aliases listed above, configured extra_loopback_hosts, and literal loopback IPs are accepted. This prevents an attacker-controlled hostname that resolves to 127.0.0.1 from gaining admin access over a loopback connection.
Helper passwords are stored stretched with PBKDF2-HMAC-SHA256 and each record carries its own scheme label and iteration work factor. Helper records written before stretching was introduced used a single-round salted SHA-256 hash and are still accepted, so tightening the scheme never locks out an established helper user.
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.
host_is_local_alias
Report whether one host value is an explicitly trusted local name for this machine: a numeric loopback literal, a configured local-only alias, or a well-known localhost hostname. The loopback-admin trust check and the web layer's cross-site Origin/Referer defense share this method so both apply identical alias semantics.
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 1Do 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.tRun the focused regression tests that most directly exercise this module's behavior.
Example 3:
HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr tRecheck the module under the repository coverage gate rather than relying on a load-only probe.
Example 4:
prove -lr tPut any module-level change back through the entire repository suite before release.