/ 
Developer-Dashboard-2.20
/ Developer::Dashboard::SessionStore

NAME

Developer::Dashboard::SessionStore - file-backed browser sessions

SYNOPSIS

my $sessions = Developer::Dashboard::SessionStore->new(paths => $paths);
my $session  = $sessions->create(username => 'mvu');

DESCRIPTION

This module stores helper login sessions on disk so the web application can persist authenticated helper access between requests.

METHODS

Construct and manage session records.

PURPOSE

This module stores helper login sessions with remote-address binding and expiry metadata. It is the persistence layer behind helper login cookies and the helper-only browser access model.

WHY IT EXISTS

It exists because helper authentication needs durable session state with explicit security rules. By keeping that state in one store, login, logout, and request-auth checks all validate the same session contract.

WHEN TO USE

Use this file when changing helper session lifetime, binding rules, or the stored session record shape.

HOW TO USE

Construct it with the active path registry and use its session create/load/delete methods from the auth-aware web routes instead of reading session files directly.

WHAT USES IT

It is used by the web app login/logout flow, by auth tests that verify expiry and remote binding, and by helper-access integration smoke.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::SessionStore -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.