Ron Savage

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.

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 youself.

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.

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.

Support

Log a bug on RT: https://rt.cpan.org/Public/Dist/Display.html?Name=Data-Session.

The CGI::Application mailing list often discusses issues relating to CGI::Session, and the author of Data::Session monitors that list, so that is another forum available to you.

See http://www.erlbaum.net/mailman/listinfo/cgiapp for details.

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



Hosting generously
sponsored by Bytemark