Provided by: libdata-session-perl_1.18-2_all 
NAME
Data::Session - Persistent session data management
Synopsis
1: A self-contained CGI script (scripts/cgi.demo.cgi):
#!/usr/bin/perl
use CGI;
use Data::Session;
use File::Spec;
# ----------------------------------------------
sub generate_html
{
my($name, $id, $count) = @_;
$id ||= '';
my($title) = "CGI demo for Data::Session";
return <<EOS;
<html>
<head><title>$title</title></head>
<body>
Number of times this script has been run: $count.<br/>
Current value of $name: $id.<br/>
<form id='sample' method='post' name='sample'>
<button id='submit'>Click to submit</button>
<input type='hidden' name='$name' id='$name' value='$id' />
</form>
</body>
</html>
EOS
} # End of generate_html.
# ----------------------------------------------
my($q) = CGI -> new;
my($name) = 'sid'; # CGI form field name.
my($sid) = $q -> param($name);
my($dir_name) = '/tmp';
my($type) = 'driver:File;id:MD5;serialize:JSON';
my($session) = Data::Session -> new
(
directory => $dir_name,
name => $name,
query => $q,
type => $type,
);
my($id) = $session -> id;
# First entry ever?
my($count);
if ($sid) # Not $id, which always has a value...
{
# No. The CGI form field called sid has a (true) value.
# So, this is the code for the second and subsequent entries.
# Count the # of times this CGI script has been run.
$count = $session -> param('count') + 1;
}
else
{
# Yes. There is no CGI form field called sid (with a true value).
# So, this is the code for the first entry ever.
# Count the # of times this CGI script has been run.
$count = 0;
}
$session -> param(count => $count);
print $q -> header, generate_html($name, $id, $count);
# Calling flush() is good practice, rather than hoping 'things just work'.
# In a persistent environment, this call is mandatory...
# But you knew that, because you'd read the docs, right?
$session -> flush;
2: A basic session. See scripts/sqlite.pl:
# The EXLOCK is for BSD-based systems.
my($directory) = File::Temp::newdir('temp.XXXX', CLEANUP => 1, EXLOCK => 0, TMPDIR => 1);
my($data_source) = 'dbi:SQLite:dbname=' . File::Spec -> catdir($directory, 'sessions.sqlite');
my($type) = 'driver:SQLite;id:SHA1;serialize:DataDumper'; # Case-sensitive.
my($session) = Data::Session -> new
(
data_source => $data_source,
type => $type,
) || die $Data::Session::errstr;
3: Using BerkeleyDB as a cache manager. See scripts/berkeleydb.pl:
# The EXLOCK is for BSD-based systems.
my($file_name) = File::Temp -> new(EXLOCK => 0, SUFFIX => '.bdb');
my($env) = BerkeleyDB::Env -> new
(
Home => File::Spec -> tmpdir,
Flags => DB_CREATE | DB_INIT_CDB | DB_INIT_MPOOL,
);
if (! $env)
{
print "BerkeleyDB is not responding. \n";
exit;
}
my($bdb) = BerkeleyDB::Hash -> new(Env => $env, Filename => $file_name, Flags => DB_CREATE);
if (! $bdb)
{
print "BerkeleyDB is not responding. \n";
exit;
}
my($type) = 'driver:BerkeleyDB;id:SHA1;serialize:DataDumper'; # Case-sensitive.
my($session) = Data::Session -> new
(
cache => $bdb,
type => $type,
) || die $Data::Session::errstr;
4: Using memcached as a cache manager. See scripts/memcached.pl:
my($memd) = Cache::Memcached -> new
({
namespace => 'data.session.id',
servers => ['127.0.0.1:11211'],
});
my($test) = $memd -> set(time => time);
if (! $test || ($test != 1) )
{
print "memcached is not responding. \n";
exit;
}
$memd -> delete('time');
my($type) = 'driver:Memcached;id:SHA1;serialize:DataDumper'; # Case-sensitive.
my($session) = Data::Session -> new
(
cache => $memd,
type => $type,
) || die $Data::Session::errstr;
5: Using a file to hold the ids. See scripts/file.autoincrement.pl:
# The EXLOCK is for BSD-based systems.
my($directory) = File::Temp::newdir('temp.XXXX', CLEANUP => 1, EXLOCK => 0, TMPDIR => 1);
my($file_name) = 'autoinc.session.dat';
my($id_file) = File::Spec -> catfile($directory, $file_name);
my($type) = 'driver:File;id:AutoIncrement;serialize:DataDumper'; # Case-sensitive.
my($session) = Data::Session -> new
(
id_base => 99,
id_file => $id_file,
id_step => 2,
type => $type,
) || die $Data::Session::errstr;
6: Using a file to hold the ids. See scripts/file.sha1.pl (non-CGI context):
my($directory) = '/tmp';
my($file_name) = 'session.%s.dat';
my($type) = 'driver:File;id:SHA1;serialize:DataDumper'; # Case-sensitive.
# Create the session:
my($session) = Data::Session -> new
(
directory => $directory,
file_name => $file_name,
type => $type,
) || die $Data::Session::errstr;
# Time passes...
# Retrieve the session:
my($id) = $session -> id;
my($session) = Data::Session -> new
(
directory => $directory,
file_name => $file_name,
id => $id, # <== Look! You must supply the id for retrieval.
type => $type,
) || die $Data::Session::errstr;
7: As a variation on the above, see scripts/cgi.sha1.pl (CGI context but command line program):
# As above (scripts/file.sha1.pl), for creating the session. Then...
# Retrieve the session:
my($q) = CGI -> new; # CGI form data provides the id.
my($session) = Data::Session -> new
(
directory => $directory,
file_name => $file_name,
query => $q, # <== Look! You must supply the id for retrieval.
type => $type,
) || die $Data::Session::errstr;
Also, much can be gleaned from t/basic.t and t/Test.pm. See "Test Code".
Description
Data::Session is typically used by a CGI script to preserve state data between runs of the script. This
gives the end user the illusion that the script never exits.
It can also be used to communicate between 2 scripts, as long as they agree beforehand what session id to
use.
See Data::Session::CGISession for an extended discussion of the design changes between Data::Session and
CGI::Session.
Data::Session stores user data internally in a hashref, and the module reserves key names starting with
'_'.
The current list of reserved keys is documented under "flush()".
Of course, the module also has a whole set of methods to help manage state.
Methods
new()
Calling new() returns a object of type Data::Session, or - if new() fails - it returns undef. For
details see "Trouble with Errors".
new() takes a hash of key/value pairs, some of which might mandatory. Further, some combinations might be
mandatory.
The keys are listed here in alphabetical order.
They are lower-case because they are (also) method names, meaning they can be called to set or get the
value at any time.
But a warning: In some cases, setting them after this module has used the previous value, will have no
effect. All such cases should be documented.
Beginners understandably confused by the quantity of options should consult the "Synopsis" for example
code.
The questions of combinations of options, and which option has priority over other options, are addressed
in the section, "Combinations of Options".
o cache => $cache
Specifies an object of type BerkeleyDB or Cache::Memcached to use for storage.
Only needed if you use 'type' like 'driver:BerkeleyDB ...' or 'driver:Memcached ...'.
See Data::Session::Driver::BerkeleyDB and Data::Session::Driver::Memcached.
Default: '' (the empty string).
o data_col_name => $string
Specifies the name of the column holding the session data, in the session table.
This key is optional.
Default: 'a_session'.
o data_source => $string
Specifies a value to use as the 1st parameter in the call to DBI's connect() method.
A typical value would be 'dbi:Pg:dbname=project'.
This key is optional. It is only used if you do not supply a value for the 'dbh' key.
Default: '' (the empty string).
o data_source_attrs => $hashref
Specify a hashref of options to use as the last parameter in the call to DBI's connect() method.
This key is optional. It is only used if you do not supply a value for the 'dbh' key.
Default: {AutoCommit => 1, PrintError => 0, RaiseError => 1}.
o dbh => $dbh
Specifies a database handle to use to access the session table.
This key is optional.
However, if not specified, you must specify a value for 'data_source', and perhaps also 'username'
and 'password', so that this module can create a database handle.
If this module does create a database handle, it will also destroy it, whereas if you supply a
database handle, you are responsible for destroying it.
o debug => $Boolean
Specifies that debugging should be turned on (1) or off (0) in Data::Session::File::Driver and
Data::Session::ID::AutoIncrement.
When debug is 1, $! is included in error messages, but because this reveals directory names, it is 0
by default.
This key is optional.
Default: 0.
o directory => $string
Specifies the directory in which session files are stored, when each session is stored in a separate
file (by using 'driver:File ...' as the first component of the 'type').
This key is optional.
Default: Your temp directory as determined by File::Spec.
See "Specifying Session Options" for details.
o file_name => $string_containing_%s
Specifies the syntax for the names of session files, when each session is stored in a separate file
(by using 'driver:File ...' as the first component of the 'type').
This key is optional.
Default: 'cgisess_%s', where the %s is replaced at run-time by the session id.
The directory in which these files are stored is specified by the 'directory' option above.
See "Specifying Session Options" for details.
o host => $string
Specifies a host, typically for use with a data_source referring to MySQL.
This key is optional.
Default: '' (the empty string).
o id => $string
Specifies an id to retrieve from storage.
This key is optional.
Default: 0.
Note: If you do not provide an id here, the module calls "user_id()" to determine whether or not an
id is available from a cookie or a form field.
This complex topic is discussed in the section "Specifying an Id".
o id_col_name => $string
Specifies the name of the column holding the session id, in the session table.
This key is optional.
Default: 'id'.
o id_base => $integer
Specifies the base from which to start ids when using the '... id:AutoIncrement ...' component in the
'type'.
Note: The first id returned by Data::Session::ID::AutoIncrement will be id_base + id_step. So, if
id_base is 1000 and id_step is 10, then the lowest id will be 1010.
This key is optional.
Default: 0.
o id_file => $file_path_and_name
Specifies the file path and name in which to store the last used id, as calculated from "id_base +
id_step", when using the '... id:AutoIncrement ...' component in the 'type'.
This value must contain a path because the 'directory' option above is only used for session files
(when using Data::Session::Driver::File).
This key is optional.
Default: File::Spec -> catdir(File::Spec -> tmpdir, 'data.session.id').
o id_step => $integer
Specifies the step size between ids when using the '... id:AutoIncrement ...' component of the
'type'.
This key is optional.
Default: 1.
o name => $string
Specifies the name of the cookie or form field which holds the session id.
This key is optional.
Default: 'CGISESSID'.
Usage of 'name' is discussed in the sections "Specifying an Id" and "user_id()".
o no_flock => $boolean
Specifies (no_flock => 1) to not use flock() to obtain a lock on a session file before processing it,
or (no_flock => 0) to use flock().
This key is optional.
Default: 0.
This value is used in these cases:
o type => 'driver:File ...'
o type => '... id:AutoIncrement ...'
o no_follow => $boolean
Influences the mode to use when calling sysopen() on session files.
'Influences' means the value is bit-wise ored with O_RDWR for reading and with O_WRONLY for writing.
This key is optional.
Default: eval { O_NOFOLLOW } || 0.
This value is used in this case:
o type => 'driver:File ...'
o password => $string
Specifies a value to use as the 3rd parameter in the call to DBI's connect() method.
This key is optional. It is only used if you do not supply a value for the 'dbh' key.
Default: '' (the empty string).
o pg_bytea => $boolean
Specifies that you're using a Postgres-specific column type of 'bytea' to hold the session data, in
the session table.
This key is optional, but see the section, "Combinations of Options" for how it interacts with the
pg_text key.
Default: 0.
Warning: Columns of type bytea can hold null characters (\x00), whereas columns of type text cannot.
o pg_text => $boolean
Specifies that you're using a Postgres-specific column type of 'text' to hold the session data, in
the session table.
This key is optional, but see the section, "Combinations of Options" for how it interacts with the
pg_bytea key.
Default: 0.
Warning: Columns of type bytea can hold null characters (\x00), whereas columns of type text cannot.
o port => $string
Specifies a port, typically for use with a data_source referring to MySQL.
This key is optional.
Default: '' (the empty string).
o query => $q
Specifies the query object.
If not specified, the next option - 'query_class' - will be used to create a query object.
Either way, the object will be accessible via the $session -> query() method.
This key is optional.
Default: '' (the empty string).
o query_class => $class_name
Specifies the class of query object to create if a value is not provided for the 'query' option.
This key is optional.
Default: 'CGI'.
o socket => $string
Specifies a socket, typically for use with a data_source referring to MySQL.
The reason this key is called socket and not mysql_socket is in case other drivers permit a socket
option.
This key is optional.
Default: '' (the empty string).
o table_name => $string
Specifies the name of the table holding the session data.
This key is optional.
Default: 'sessions'.
o type => $string
Specifies the type of Data::Session object you wish to create.
This key is optional.
Default: 'driver:File;id:MD5;serialize:DataDumper'.
This complex topic is discussed in the section "Specifying Session Options".
o umask => $octal_number
Specifies the mode to use when calling sysopen() on session files.
This value is used in these cases:
o type => 'driver:File ...'
o type => '... id:AutoIncrement ...'
Default: 0660 (octal).
o username => $string
Specifies a value to use as the 2nd parameter in the call to DBI's connect() method.
This key is optional. It is only used if you do not supply a value for the 'dbh' key.
Default: '' (the empty string).
o verbose => $integer
Print to STDERR more or less information.
Typical values are 0, 1 and 2.
This key is optional.
Default: 0, meaings nothing is printed.
See "dump([$heading])" for what happens when verbose is 2.
Specifying Session Options
See also "Case-sensitive Options".
The default 'type' string is 'driver:File;id:MD5;serialize:DataDumper'. It consists of 3 optional
components separated by semi-colons.
Each of those 3 components consists of 2 fields (a key and a value) separated by a colon.
The keys:
o driver
This specifies what type of persistent storage you wish to use for session data.
Values for 'driver':
o BerkeleyDB
Use BerkeleyDB for storage. In this case, you must pass an object of type BerkeleyDB to new() as
the value of the 'cache' option.
See Data::Session::Driver::BerkeleyDB.
o File
The default, 'File', says sessions are each stored in a separate file.
The directory for these files is specified with the 'directory' option to new().
If a directory is not specified in that way, File::Spec is used to find your temp directory.
The names of the session files are generated from the 'file_name' option to new().
The default file name (pattern) is 'cgisess_%s', where the %s is replaced by the session id.
See Data::Session::Driver::File.
o Memcached
Use "memcached" for storage. In this case, you must pass an object of type Cache::Memcached to
new() as the value of the 'cache' option.
See Data::Session::Driver::Memcached.
o mysql
This says each session is stored in a separate row of a database table using the DBD::mysql
database server.
These rows have a unique primary id equal to the session id.
See Data::Session::Driver::mysql.
o ODBC
This says each session is stored in a separate row of a database table using the DBD::ODBC
database connector.
These rows have a unique primary id equal to the session id.
See Data::Session::Driver::ODBC.
o Oracle
This says each session is stored in a separate row of a database table using the DBD::Oracle
database server.
These rows have a unique primary id equal to the session id.
See Data::Session::Driver::Oracle.
o Pg
This says each session is stored in a separate row of a database table using the DBD::Pg database
server.
These rows have a unique primary id equal to the session id.
See Data::Session::Driver::Pg.
o SQLite
This says each session is stored in a separate row of a database table using the SQLite database
server.
These rows have a unique primary id equal to the session id.
The advantage of SQLite is that a client and server are shipped with all recent versions of Perl.
See Data::Session::Driver::SQLite.
o id
This specifies what type of id generator you wish to use.
Values for 'id':
o AutoIncrement
This says ids are generated starting from a value specified with the 'id_base' option to new(),
and the last-used id is stored in the file name given by the 'id_file' option to new().
This file name must include a path, since the 'directory' option to new() is not used here.
When a new id is required, the value in the file is incremented by the value of the 'id_step'
option to new(), with the new value both written back to the file and returned as the new session
id.
The default value of id_base is 0, and the default value of id_step is 1. Together, the first id
available as a session id is id_base + id_step = 1.
The sequence starts when the module cannot find the given file, or when its contents are not
numeric.
See Data::Session::ID::AutoIncrement.
o MD5
The default, 'MD5', says ids are to be generated by Digest::MD5.
See Data::Session::ID::MD5.
o SHA1
This says ids are to be generated by Digest::SHA, using a digest algorithm of 1.
See Data::Session::ID::SHA1.
o SHA256
This says ids are to be generated by Digest::SHA, using a digest algorithm of 256.
See Data::Session::ID::SHA256.
o SHA512
This says ids are to be generated by Digest::SHA, using a digest algorithm of 512.
See Data::Session::ID::SHA512.
o Static
This says that the id passed in to new(), as the value of the 'id' option, will be used as the
session id for every session.
Of course, this id must have a true value. Data::Session dies on all values Perl regards as
false.
See Data::Session::ID::Static.
o UUID16
This says ids are to be generated by Data::UUID, to generate a 16 byte long binary UUID.
See Data::Session::ID::UUID16.
o UUID34
This says ids are to be generated by Data::UUID, to generate a 34 byte long string UUID.
See Data::Session::ID::UUID34.
o UUID36
This says ids are to be generated by Data::UUID, to generate a 36 byte long string UUID.
See Data::Session::ID::UUID36.
o UUID64
This says ids are to be generated by Data::UUID, to generate a 24 (sic) byte long, base-64
encoded, UUID.
See Data::Session::ID::UUID64.
See scripts/digest.pl which prints the length of each type of digest.
o serialize
The specifies what type of mechanism you wish to use to convert the in-memory session data into a
form appropriate for your chosen storage type.
Values for 'serialize':
o DataDumper
Use Data::Dumper to freeze/thaw sessions.
See Data::Session::Serialize::DataDumper.
o FreezeThaw
Use FreezeThaw to freeze/thaw sessions.
See Data::Session::Serialize::FreezeThaw.
o JSON
Use JSON to freeze/thaw sessions.
See Data::Session::Serialize::JSON.
o Storable
Use Storable to freeze/thaw sessions.
See Data::Session::Serialize::Storable.
Warning: Storable should be avoided until this problem is fixed:
<http://rt.cpan.org/Public/Bug/Display.html?id=36087>.
o YAML
Use YAML::Tiny to freeze/thaw sessions.
See Data::Session::Serialize::YAML.
Case-sensitive Options
Just to emphasize: The names of drivers, etc follow the DBD::* (or similar) style of case-sensitivity.
The following classes for drivers, id generators and serializers, are shipped with this package.
Drivers:
o Data::Session::Driver::BerkeleyDB
This name comes from BerkeleyDB.
And yes, the module uses BerkeleyDB and not DB_File.
o Data::Session::Driver::File
o Data::Session::Driver::Memcached
This name comes from Cache::Memcached even though the external program you run is called memcached.
o Data::Session::Driver::mysql
o Data::Session::Driver::ODBC
o Data::Session::Driver::Oracle
o Data::Session::Driver::Pg
o Data::Session::Driver::SQLite
ID generators:
o Data::Session::ID::AutoIncrement
o Data::Session::ID::MD5
o Data::Session::ID::SHA1
o Data::Session::ID::SHA256
o Data::Session::ID::SHA512
o Data::Session::ID::Static
o Data::Session::ID::UUID16
o Data::Session::ID::UUID34
o Data::Session::ID::UUID36
o Data::Session::ID::UUID64
Serializers:
o Data::Session::Serialize::DataDumper
o Data::Session::Serialize::FreezeThaw
o Data::Session::Serialize::JSON
o Data::Session::Serialize::Storable
Warning: Storable should be avoided until this problem is fixed:
<http://rt.cpan.org/Public/Bug/Display.html?id=36087>
o Data::Session::Serialize::YAML
Specifying an Id
"user_id()" is called to determine if an id is available from a cookie or a form field.
There are several cases to consider:
o You specify an id which exists in storage
You can check this with the call $session -> is_new, which will return 0.
$session -> id will return the old id.
o You do not specify an id
The module generates a new session and a new id.
You can check this with the call $session -> is_new, which will return 1.
$session -> id will return the new id.
o You specify an id which does not exist in storage
You can check this with the call $session -> is_new, which will return 1.
$session -> id will return the old id.
So, how to tell the difference between the last 2 cases? Like this:
if ($session -> id == $session -> user_id)
{
# New session using user-supplied id.
}
else
{
# New session with new id.
}
Combinations of Options
See also "Specifying Session Options", for options-related combinations.
o dbh
If you don't specify a value for the 'dbh' key, this module must create a database handle in those
cases when you specify a database driver of some sort in the value for 'type'.
To create that handle, we needs a value for 'data_source', and that in turn may require values for
'username' and 'password'.
When using SQLite, just specify a value for 'data_source'. The default values for 'username' and
'password' - empty strings - will work.
o file_name and id_file
When using new(type => 'driver:File;id:AutoIncrement;...'), then file_name is ignored and id_file is
used.
If id_file is not supplied, it defaults to File::Spec -> catdir(File::Spec -> tmpdir,
'data.session.id').
When using new(type => 'driver:File;id:<Not AutoIncrement>;...'), then id_file is ignored and
file_name is used.
If file_name is not supplied, it defaults to 'cgisess_%s'. Note the mandatory %s.
o pg_bytea and pg_text
If you set 'pg_bytea' to 1, then 'pg_text' will be set to 0.
If you set 'pg_text' to 1, then 'pg_bytea' will be set to 0.
If you set them both to 0 (i.e. the default), then 'pg_bytea' will be set to 1.
If you set them both to 1, 'pg_bytea' will be left as 1 and 'pg_text' will be set to 0.
This choice was made because you really should be using a column type of 'bytea' for a_session in the
sessions table, since the type 'text' does not handle null (\x00) characters.
atime([$atime])
The [] indicates an optional parameter.
Returns the last access time of the session.
By default, the value comes from calling Perl's time() function, or you may pass in a time, which is then
used to set the last access time of the session.
This latter alternative is used by "load_session()".
See also "ctime()", "etime()" and "ptime()".
check_expiry()
Checks that there is an expiry time set for the session, and, if (atime + etime) < time():
o Deletes the session
See "delete()" for precisely what this means.
o Sets the expired flag
See "expired()".
This is used when the session is loaded, when you call "http_header([@arg])", and by scripts/expire.pl.
clear([$name])
The [] indicates an optional parameter.
Returns 1.
Specifies that you wish to delete parameters stored in the session, i.e. stored by previous calls to
param().
$name is a parameter name or an arrayref of parameter names.
If $name is not specified, it is set to the list of all unreserved keys (parameter names) in the session.
See "param([@arg])" for details.
cookie([@arg])
The [] indicates an optional parameter.
Returns a cookie, or '' (the empty string) if the query object does not have a cookie() method.
Use the @arg parameter to pass any extra parameters to the query object's cookie() method.
Warning: Parameters which are handled by Data::Session, and hence should not be passed in, are:
o -expires
o -name
o -value
See "http_header([@arg])" and scripts/cookie.pl.
ctime()
Returns the creation time of the session.
The value comes from calling Perl's time() function when the session was created.
This is not the creation time of the session object, except for new sessions.
See also "atime()", "etime()" and "ptime()".
delete()
Returns the result of calling the driver's remove() method.
Specifies that you want to delete the session. Here's what it does:
o Immediately deletes the session from storage
o Calls clear()
This deletes all non-reserved parameters from the session object, and marks it as modified.
o Marks the session object as deleted
The latter step means that when (or if) the session object goes out of scope, it will not be flushed to
storage.
Likewise, if you call flush(), the call will be ignored.
Nevertheless, the session object is still fully functional - it just can't be saved or retrieved.
See also "deleted()" and "expire([@arg])".
deleted()
Returns a Boolean (0/1) indicating whether or not the session has been deleted.
See also "delete()" and "expire([@arg])".
dump([$heading])
The [] indicates an optional parameter.
Dumps the session's contents to STDERR, with a prefix of '# '.
The $heading, if any, is written first, on a line by itself, with the same prefix.
This is especially useful for testing, since it fits in with the Test::More method diag().
When verbose is 2, dump is called at these times:
o When a session is flushed
o As soon as a session is loaded
o As soon as expiry is checked on a just-loaded session
o As soon as parameter expiry is checked on a just-loaded session
etime()
Returns the expiry time of the session.
This is the same as calling $session -> expiry(). In fact, this just calls $session -> etime.
See also "atime()", "ctime()" and "ptime()".
expire([@arg])
The [] indicates an optional parameter.
Specifies that you wish to set or retrieve the session's expiry time, or set the expiry times of session
parameters.
Integer time values ($time below) are assumed to be seconds. The value may be positive or 0 or negative.
These expiry times are relative to the session's last access time, not the session's creation time.
In all cases, a time of 0 disables expiry.
This affects users of Cache::Memcached. See below and Data::Session::Driver::Memcached.
When a session expires, it is deleted from storage. See "delete()" for details.
The test for whether or not a session has expired only takes place when a session is loaded from storage.
When a session parameter expires, it is deleted from the session object. See "clear([$name])" for
details.
The test for whether or not a session parameter has expired only takes place when a session is loaded
from storage.
o $session -> expire()
Use $session -> expire() to return the session's expiry time. This just calls $session -> etime.
The default expiry time is 0, meaning the session will never expire. Likewise, by default, session
parameters never expire.
o $session -> expire($time)
Use $session -> expire($time) to set the session's expiry time.
Use these suffixes to change the interpretation of the integer you specify:
+-----------+---------------+
| Suffix | Meaning |
+-----------+---------------+
| s | Second |
| m | Minute |
| h | Hour |
| d | Day |
| w | Week |
| M | Month |
| y | Year |
+-----------+---------------+
Hence $session -> expire('2h') means expire the session in 2 hours.
expire($time) calls validate_time($time) to perform the conversion from '2h' to seconds, so
"validate_time($time)" is available to you too.
If setting a time like this, expire($time) returns 1.
Note: The time set here is passed as the 3rd parameter to the storage driver's store() method (for
all types of storage), and from there as the 3rd parameter to the set() method of Cache::Memcached.
Of course, this doesn't happen immediately - it only happens when the session is saved.
o $session -> expire($key_1 => $time_1[, $key_2 => $time_2...])
Use $session -> expire($key_1 => $time_1[, $key_2 => $time_2...]) to set the expiry times of session
parameters.
Special cases:
o To expire the session immediately, call delete()
o To expire a session parameter immediately, call clear($key)
See also "atime()", "ctime()", "etime()", "delete()" and "deleted()".
expired()
Returns a Boolean (0/1) indicating whether or not the session has expired.
See "delete()".
flush()
Returns 1.
Specifies that you want the session object immediately written to storage.
If you have previously called delete(), the call to flush() is ignored.
If the object has not been modified, the call to flush() is ignored.
Warning: With persistent environments, you object may never go out of scope that way you think it
does.See "Trouble with Exiting" for details.
These reserved session parameters are included in what's written to storage:
o _SESSION_ATIME
The session's last access time.
o _SESSION_CTIME
The session's creation time.
o _SESSION_ETIME
The session's expiry time.
A time of 0 means there is no expiry time.
This affect users of Cache::Memcached. See "expire([@arg])" and Data::Session::Driver::Memcached.
o _SESSION_ID
The session's id.
o _SESSION_PTIME
A hashref of session parameter expiry times.
http_header([@arg])
The [] indicate an optional parameter.
Returns a HTTP header. This means it does not print the header. You have to do that, when appropriate.
Unlike CGI::Session, Data::Session does not force the document type to be 'text/html'.
You must pass in a document type to http_header(), as "$session -> http_header('-type' => 'text/html')",
or use the query object's default.
Both CGI and CGI::Simple default to 'text/html'.
Data::Session handles the case where the query object does not have a cookie() method, by calling
$session -> cookie() to generate either a cookie, or '' (the empty string).
The @arg parameter, if any, is passed to the query object's header() method, after the cookie parameter,
if any.
id()
Returns the id of the session.
is_new()
Returns a Boolean (0/1).
Specifies you want to know if the session object was created from scratch (1) or was retrieved from
storage (0).
load_param([$q][, $name])
The [] indicate optional parameters.
Returns $q.
Loads (copies) all non-reserved parameters from the session object into the query object.
"save_param([$q][, $name])" performs the opposite operation.
$q is a query object, and $name is a parameter name or an arrayref of names.
If the query object is not specified, generates one by calling $session -> load_query_class, and stores
it in the internal 'query' attribute.
If you don't provide $q, use undef, don't just omit the parameter.
If $name is specified, only the session parameters named in the arrayref are processed.
If $name is not specified, copies all parameters belonging to the query object.
load_query_class()
Returns the query object.
This calls $session -> query_class -> new if the session object's query object is not defined.
load_session()
Returns a session.
Note: This method does not take any parameters, and hence does not function in the same way as load(...)
in CGI::Session.
Algorithm:
o If user_id() returns a session id, try to load that session
If that succeeds, return the session.
If it fails, generate a new session, and return it.
You can call is_new() to tell the difference between these 2 cases.
o If user_id() returns 0, generate a new session, and return it
modified()
Returns a Boolean (0/1) indicating whether or not the session's parameters have been modified.
However, changing a value from one form of not-defined, e.g. undef, to another form of not-defined, e.g.
0, is ignored, meaning the modified flag is not set. In such cases, you could set the flag yourself.
Note: Loading a session from storage changes the session's last access time, which means the session has
been modified.
If you wish to stop the session being written to storage, without deleting it, you can reset the modified
flag with $session -> modified(0).
param([@arg])
The [] indicates an optional parameter.
Specifies that you wish to retrieve data stored in the session, or you wish to store data in the session.
Data is stored in the session object as in a hash, via a set of $key => $value relationships.
Use $session -> param($key_1 => $value_1[, $key_2 => $value_2...]) to store data in the session.
If storing data, param() returns 1.
The values stored in the session may be undef.
Note: If the value being stored is the same as the pre-existing value, the value in the session is not
updated, which means the last access time does not change.
Use $session -> param() to return a sorted list of all keys.
That call returns a list of the keys you have previously stored in the session.
Use $session -> param('key') to return the value associated with the given key.
See also "clear([$name])".
ptime()
Returns the hashref of session parameter expiry times.
Keys are parameter names and values are expiry times in seconds.
These expiry times are set by calling "expire([@arg])".
See also "atime()", "ctime()" and "etime()".
save_param([$q][, $name])
The [] indicate optional parameters.
Returns 1.
Loads (copies) all non-reserved parameters from the query object into the session object.
"load_param([$q][, $name])" performs the opposite operation.
$q is a query object, and $name is a parameter name or an arrayref of names.
If the query object is not specified, generates one by calling $session -> load_query_class, and stores
it in the internal 'query' attribute. This means you can retrieve it with $session -> query.
If you don't provide $q, use undef, don't just omit the parameter.
If $name is specified, only the session parameters named in the arrayref are processed.
If $name is not specified, copies all parameters.
traverse($sub)
Returns 1.
Specifies that you want the $sub called for each session id found in storage, with one (1) id as the only
parameter in each call.
Note: traverse($sub) does not load the sessions, and hence has no effect on the session's last access
time.
See scripts/expire.pl.
user_id()
Returns either a session id, or 0.
Algorithm:
o If $session -> id() returns a true value, return that
E.g. The user supplied one in $session -> new(id => $id).
Return this id.
o Try to recover an id from the cookie object or the query object.
If the query object supports the cookie method, call $self -> query -> cookie and (if that doesn't
find an id), $self -> query -> param.
If the query object does not support the cookie method, just call $self -> query -> param.
Return any id found, or 0.
Note: The name of the cookie, and the name of the CGI form field, is passed to new() by the 'name'
option.
validate_options()
Cross-check a few things.
E.g. When using type => '... id:Static ...', you must supply a (true) id to new(id => ...').
validate_time($time)
Dies for an invalid time string, or returns the number of seconds corresponding to $time, which may be
positive or negative.
See "expire([@arg])" for details on the time string format.
Test Code
t/basic.ini and t/bulk.ini contain DSNs for BerkeleyDB, File, Memcache, MySQL, Pg and SQLite. Actually,
they're the same file, just with different DSNs activated.
So, you can use t/basic.t to run minimal tests (with only File and SQLite activated) like this:
perl -Ilib t/basic.t
or you can edit t/bulk.ini as desired, and pass it in like this:
perl -Ilib t/basic.t t/bulk.ini
Simple instructions for installing BerkeleyDB (Oracle and Perl) are in Data::Session::Driver::Berkeley.
Simple instructions for installing Cache::Memcached and memcached are in
Data::Session::Driver::Memcached.
FAQ
Guidelines re Sources of Confusion
This section discusses various issues which confront beginners:
o 1: Both Data::Session and CGI::Snapp have a param() method
Let's say your CGI script sub-classes CGI::Application or it's successor CGI::Snapp.
Then inside your sub-class's methods, this works:
$self -> param(a_key => 'a_value');
Time passes...
my($value) = $self -> param('a_key');
because those 2 modules each implement a method called param(). Basically, you're storing a value
(via 'param') inside $self.
But when you store an object of type Data::Session using param(), it looks like this:
$self -> param(session => Data::Session -> new(...) );
Now, Data::Session itself also implements a method called param(). So, to store something in the
session (but not in $self), you must do:
$self -> param('session') -> param(a_key => 'a_value');
Time passes...
my($value) = $self -> param('session') -> param('a_key');
It should be obvious that confusion can arise here because the 2 objects represented by $self and
$self -> param('session') both have param() methods.
o 2: How exactly should a CGI script save a session?
The first example in the Synopsis shows a very simple CGI script doing the right thing by calling
flush() just before it exits.
Alternately, if you sub-class CGI::Snapp, the call to flush() is best placed in your teardown()
method, which is where you override "teardown()" in CGI::Snapp. The point here is that your
teardown() is called automatically at the end of each run mode.
This important matter is also discussed in "General Questions" below.
o 3: Storing array and hashes
Put simply: Don't do that!
This will fail:
$self -> param('session') -> param(my_hash => %my_hash);
Time passes...
my(%my_hash) = $self -> param('session') -> param('my_hash');
Likewise for an array instead of a hash.
But why? Because the part 'param(my_hash => %my_hash)' is basically assigning a list (%my_hash) to a
scalar (my_hash). Hence, only 1 element of the list (the 'first' key in some unknown order) will be
assigned.
So, when you try to restore the hash with 'my(%my_hash) ...', all you'll get back is a scalar, which
will generate the classic error message 'Odd number of elements in hash assignment...'.
The solution is to use arrayrefs and hashrefs:
$self -> param('session') -> param(my_hash => {%my_hash});
Time passes...
my(%my_hash) = %{$self -> param('session') -> param('my_hash')};
Likewise for an array:
$self -> param('session') -> param(my_ara => [@my_ara]);
Time passes...
my(@my_ara) = @{$self -> param('session') -> param('my_ara')};
General Questions
o My sessions are not getting written to disk!
This is because you haven't stored anything in them. You're probably thinking sessions are saved just
because they exist.
Actually, sessions are only saved if they have at least 1 parameter set. The session id and
access/etc times are not enough to trigger saving.
Just do something like $session -> param(ok => 1); if you want a session saved just to indicate it
exists. Code like this sets the modified flag on the session, so that flush() actually does the save.
Also, see "Trouble with Exiting", below, to understand why flush() must be called explicitly in
persistent environments.
o Why don't the test scripts use Test::Database?
I decided to circumvent it by using DBIx::Admin::DSNManager and adopting the wonders of nested
testing. But, since V 1.11, I've replaced that module with Config::Tiny, to reduce dependencies, and
hence to make it easier to get Data::Session into Debian.
See t/basic.t, and in particular this line: subtest $driver => sub.
o Why didn't you use OSSP::uuid as did CGI::Session::ID::uuid?
Because when I tried to build that module (under Debian), ./configure died, saying I had set 2
incompatible options, even though I hadn't set either of them.
o What happens when 2 processes write sessions with the same id?
The last-to-write wins, by overwriting what the first wrote.
o Params::Validate be adopted to validate parameters?
Not yet.
Troubleshooting
Trouble with Errors
When object construction fails, new() sets $Data::Session::errstr and returns undef. This means you can
use this idiom:
my($session) = Data::Session -> new(...) || process_error($Data::Session::errstr);
However, when methods detect errors they die, so after successful object construction, you can do:
use Try::Tiny;
try
{
$session -> some_method_which_may_die;
}
catch
{
process_error($_); # Because $_ holds the error message.
};
Trouble with Exiting
If the session object's clean-up code is called, in DESTROY(), the session data is automatically flushed
to storage (except when it's been deleted, or has not been modified).
However, as explained below, there can be problems with your code (i.e. not with Data::Session) such that
this clean-up code is not called, or, if called, it cannot perform as expected.
The general guideline, then, is that you should explicitly call "flush()" on the session object before
your program exits.
Common traps for beginners:
o Creating 2 CGI-like objects
If your code creates an object of type CGI or similar, but you don't pass that object into
Data::Session via the 'query' parameter to new(), this module will create one for you, which can be
very confusing.
The solution is to always create such a object yourself, and to always pass that into Data::Session.
In the case that the user of a CGI script runs your code for the first time, there will be no session
id, either from a cookie or from a form field.
In such a case, Data::Session will do what you expect, which is to generate a session id.
o Letting your database handle go out of scope too early
When your script is exiting, and you're trying to save session data to storage via a database handle,
the save will fail if the handle goes out of scope before the session data is flushed to storage.
So, don't do that.
o Assuming your session object goes out of scope when it doesn't
In persistent environments such as Plack, FastCGI and mod_perl, your code exits as expected, but the
session object does not go out of scope in the normal way.
In cases like this, it is mandatory for you to call flush() on the session object before your code
exits, since persistent environments operate in such a way that the session object's clean-up code
does not get called. This means that flush() is not called automatically by DESTROY() as you would
expect, because DESTROY() is not being called.
o Creating circular references anywhere in your code
In these cases, Perl's clean-up code may not run to completion, which means the session object may
not have its clean-up code called at all. As above, flush() may not get called.
If you must create circular references, it's vital you debug the exit logic using a module such as
Devel::Cycle before assuming the fault is with Data::Session.
o Using signal handlers
Write your code defensively, if you wish to call the session object's flush() method when a signal
might affect program exit logic.
Trouble with IDs
The module uses code like if (! $self -> id), which means ids must be (Perl) true values, so undef, 0 and
'' will not work.
Trouble with UUID16
While testing with UUID16 as the id generator, I got this message: ... invalid byte sequence for encoding
"UTF8" ...
That's because when I create a database (in Postgres) I use "create database d_name owner d_owner
encoding 'UTF8';" and UUID16 simply produces a 16 byte binary value, which is not guaranteed to be or
contain a valid UTF8 character.
This also means you should never try to use 'driver:File;id:UUID16 ...', since the ids generated by this
module would rarely if ever be valid as a part of a file name.
Trouble with UUID64
While testing with UUID64 as the id generator, I got this message: ... Session ids cannot contain \ or /
...
That's because I was using a File driver, and UUID's encoded in base 64 can contain /.
So, don't do that.
Version Numbers
Version numbers < 1.00 represent development versions. From 1.00 up, they are production versions.
Repository
<https://github.com/ronsavage/Data-Session.git>
Support
LBugs should be reported via the CPAN bug tracker at
<https://github.com/ronsavage/Data-Session/issues>
Thanks
Many thanks are due to all the people who contributed to both Apache::Session and CGI::Session.
Likewise, many thanks to the implementors of nesting testing. See Test::Simple.
Author
Data::Session was written by Ron Savage <ron@savage.net.au> in 2010.
Home page: <http://savage.net.au/index.html>.
Copyright
Australian copyright (c) 2010, Ron Savage.
All Programs of mine are 'OSI Certified Open Source Software';
you can redistribute them and/or modify them under the terms of
The Artistic License, a copy of which is available at:
http://www.opensource.org/licenses/index.html
perl v5.36.0 2023-02-14 Data::Session(3pm)