NAME

Catalyst::Authentication::Store - All about authentication stores

MULTIPLE BACKENDS

NOTE This is documentation for the old store system used in versions of Catalyst::Plugin::Authentication prior to 0.10. This is NOT how the new realm-based stores work. This is here for reference only.

WRITING A BACKEND

This method should accept an arbitrary list of parameters (determined by you or the credential verifyer), and return an object inheriting Catalyst::Authentication::User.

For introspection purposes you can also define the user_supports method. See below for optional features. This is not necessary, but might be in the future.

Integrating with Catalyst::Plugin::Session

If your users support sessions, your store should also define the from_session method. When the user object is saved in the session the for_session method is called, and that is used as the value in the session (typically a user id). The store is also saved in the hash. If <$user-store>> returns something registered, that store's name is used. If not, the user's class is used as if it were a store (and must also support from_session).

Optional Features

Each user has the supports method. For example:

$user->supports(qw/password clear/);

should return a true value if this specific user has a clear text password.

This is on a per user (not necessarily a per store) basis. To make assumptions about the store as a whole,

$store->user_supports(qw/password clear/);

is supposed to be the lowest common denominator.

The standardization of these values is to be goverened by the community, typically defined by the credential verification plugins.

Stores implying certain credentials

Sometimes a store is agnostic to the credentials (DB storage, for example), but sometimes it isn't (like an Htpasswd file).