1Catalyst::Plugin::SessiUosne:r:SCtoonrter(i3b)uted PerlCDaotcaulmyesntt:a:tPiloungin::Session::Store(3)
2
3
4

NAME

6       Catalyst::Plugin::Session::Store - Base class for session storage
7       drivers.
8

SYNOPSIS

10           package Catalyst::Plugin::Session::Store::MyBackend;
11           use base qw/Catalyst::Plugin::Session::Store/;
12

DESCRIPTION

14       This class doesn't actually provide any functionality, but when the
15       "Catalyst::Plugin::Session" module sets up it will check to see that
16       "YourApp->isa("Catalyst::Plugin::Session::Store")". When you write a
17       session storage plugin you should subclass this module for this reason.
18       This documentation is intended for authors of session storage plugins,
19       not for end users.
20

WRITING STORE PLUGINS

22       All session storage plugins need to adhere to the following interface
23       specification to work correctly:
24
25   Required Methods
26       get_session_data $key
27       store_session_data $key, $data
28           Retrieve or store session data by key.
29
30           $data is currently either a hash reference (for most keys) or an
31           integer value (for expires), but all value types should be
32           supported.
33
34           Keys are in the format "prefix:id", where "prefix" is "session",
35           "expires", or "flash", and "id" is always the session ID. Plugins
36           such as Catalyst::Plugin::Session::PerUser store extensions to this
37           format, such as "user:username".
38
39           It is suggested that the store should split on the colon and store
40           the data more efficiently - the API should remain stable, with the
41           possible addition of new prefixes in the future.
42
43           For example, "Store::DBI" maps "expires:id" a column of
44           "session:id" by special-casing "get_session_data" and
45           "store_session_data" for that key format, in order to ease the
46           implementation of "delete_expired_sessions".
47
48           The only assurance stores are required to make is that given
49
50               $c->store_session_data( $x, $y );
51
52           for any $x,
53
54               $y == $c->get_session_data( $x )
55
56           will hold.
57
58       store_session_data ( $key, $data )
59           Store a session whose KEY is the first parameter and data is the
60           second parameter in storage.
61
62           The second parameter is a hash reference, which should normally be
63           serialized (and later deserialized by "get_session_data").
64
65       delete_session_data ( $key )
66           Delete the session whose KEY is the parameter.
67
68       delete_expired_sessions
69           This method is not called by any code at present, but may be called
70           in the future, as part of a Catalyst-specific maintenance script.
71
72           If you are wrapping around a backend which manages its own auto
73           expiry you can just give this method an empty body.
74
75   Error handling
76       All errors should be thrown using Catalyst::Exception. Return values
77       are not checked, and are assumed to be OK. Missing values are not
78       errors.
79
80   Auto-Expiry on the Backend
81       Storage plugins are encouraged to use "$c->session_expires",
82       "$c->config('Plugin::Session' => { expires => $val })", or the storage
83       of the "expires:$sessionid" key to perform more efficient expiration,
84       but only for the key prefixes "session", "flash" and "expires".
85
86       If the backend chooses not to do so, Catalyst::Plugin::Session will
87       detect expired sessions as they are retrieved and delete them if
88       necessary.
89
90       Note that session store that use this approach may leak disk space,
91       since nothing will actively delete an expired session. The
92       "delete_expired_sessions" method is there so that regularly scheduled
93       maintenance scripts can give your backend the opportunity to clean up.
94
95   Early Finalization
96       By default the main session plugin will finalize during body
97       finalization which ensures that all controller code related to the
98       session has completed.  However some storage plugins may wish to
99       finalize earlier, during header finalization.  For example a storage
100       that saved state in a client cookie would wish this.  If a storage
101       plugin wants to finalize early it should set
102       $c->_needs_early_session_finalization to true.  Please note that if you
103       do this in a storage plugin, you should warn users not to attempt to
104       change or add session keys if you use a streaming or socket interface
105       such as $c->res->write, $c->res->write_fh or $c->req->io_fh.
106
107
108
109perl v5.30.0                      2019-07-26Catalyst::Plugin::Session::Store(3)
Impressum