The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

Catalyst::Plugin::Session - Generic Session plugin - ties together server side storage and client side state required to maintain session data.

SYNOPSIS

    # To get sessions to "just work", all you need to do is use these plugins:

    use Catalyst qw/
      Session
      Session::Store::FastMmap
      Session::State::Cookie
      /;

        # you can replace Store::FastMmap with Store::File - both have sensible
        # default configurations (see their docs for details)

        # more complicated backends are available for other scenarios (DBI storage,
        # etc)


    # after you've loaded the plugins you can save session data
    # For example, if you are writing a shopping cart, it could be implemented
    # like this:

    sub add_item : Local {
        my ( $self, $c ) = @_;

        my $item_id = $c->req->param("item");

        # $c->session is a hash ref, a bit like $c->stash
        # the difference is that it' preserved across requests

        push @{ $c->session->{items} }, $item_id;

        $c->forward("MyView");
    }

    sub display_items : Local {
        my ( $self, $c ) = @_;

        # values in $c->session are restored
        $c->stash->{items_to_display} =
          [ map { MyModel->retrieve($_) } @{ $c->session->{items} } ];

        $c->forward("MyView");
    }

DESCRIPTION

The Session plugin is the base of two related parts of functionality required for session management in web applications.

The first part, the State, is getting the browser to repeat back a session key, so that the web application can identify the client and logically string several requests together into a session.

The second part, the Store, deals with the actual storage of information about the client. This data is stored so that the it may be revived for every request made by the same client.

This plugin links the two pieces together.

RECCOMENDED BACKENDS

Session::State::Cookie

The only really sane way to do state is using cookies.

Session::Store::File

A portable backend, based on Cache::File.

Session::Store::FastMmap

A fast and flexible backend, based on Cache::FastMmap.

METHODS

sessionid

An accessor for the session ID value.

session

Returns a hash reference that might contain unserialized values from previous requests in the same session, and whose modified value will be saved for future requests.

This method will automatically create a new session and session ID if none exists.

session_expires
session_expires $reset

This method returns the time when the current session will expire, or 0 if there is no current session. If there is a session and it already expired, it will delete the session and return 0 as well.

If the $reset parameter is true, and there is a session ID the expiry time will be reset to the current time plus the time to live (see "CONFIGURATION"). This is used when creating a new session.

flash

This is like Ruby on Rails' flash data structure. Think of it as a stash that lasts for longer than one request, letting you redirect instead of forward.

The flash data will be cleaned up only on requests on which actually use $c->flash (thus allowing multiple redirections), and the policy is to delete all the keys which haven't changed since the flash data was loaded at the end of every request.

    sub moose : Local {
        my ( $self, $c ) = @_;

        $c->flash->{beans} = 10;
        $c->response->redirect( $c->uri_for("foo") );
    }

    sub foo : Local {
        my ( $self, $c ) = @_;

        my $value = $c->flash->{beans};

        # ...

        $c->response->redirect( $c->uri_for("bar") );
    }

    sub bar : Local {
        my ( $self, $c ) = @_;

        if ( exists $c->flash->{beans} ) { # false
        
        }
    }
keep_flash @keys

If you wawnt to keep a flash key for the next request too, even if it hasn't changed, call keep_flash and pass in the keys as arguments.

delete_session REASON

This method is used to invalidate a session. It takes an optional parameter which will be saved in session_delete_reason if provided.

session_delete_reason

This accessor contains a string with the reason a session was deleted. Possible values include:

  • address mismatch

  • session expired

session_expire_key $key, $ttl

Mark a key to expire at a certain time (only useful when shorter than the expiry time for the whole session).

For example:

    __PACKAGE__->config->{session}{expires} = 1000000000000; # forever

    # later

    $c->session_expire_key( __user => 3600 );

Will make the session data survive, but the user will still be logged out after an hour.

Note that these values are not auto extended.

INTERNAL METHODS

setup

This method is extended to also make calls to check_session_plugin_requirements and setup_session.

check_session_plugin_requirements

This method ensures that a State and a Store plugin are also in use by the application.

setup_session

This method populates $c->config->{session} with the default values listed in "CONFIGURATION".

prepare_action

This methoid is extended.

It's only effect is if the (off by default) flash_to_stash configuration parameter is on - then it will copy the contents of the flash to the stash at prepare time.

finalize

This method is extended and will extend the expiry time, as well as persist the session data if a session exists.

initialize_session_data

This method will initialize the internal structure of the session, and is called by the session method if appropriate.

create_session_id

Creates a new session id using generate_session_id if there is no session ID yet.

validate_session_id SID

Make sure a session ID is of the right format.

This currently ensures that the session ID string is any amount of case insensitive hexadecimal characters.

generate_session_id

This method will return a string that can be used as a session ID. It is supposed to be a reasonably random string with enough bits to prevent collision. It basically takes session_hash_seed and hashes it using SHA-1, MD5 or SHA-256, depending on the availibility of these modules.

session_hash_seed

This method is actually rather internal to generate_session_id, but should be overridable in case you want to provide more random data.

Currently it returns a concatenated string which contains:

  • A counter

  • The current time

  • One value from rand.

  • The stringified value of a newly allocated hash reference

  • The stringified value of the Catalyst context object

In the hopes that those combined values are entropic enough for most uses. If this is not the case you can replace session_hash_seed with e.g.

    sub session_hash_seed {
        open my $fh, "<", "/dev/random";
        read $fh, my $bytes, 20;
        close $fh;
        return $bytes;
    }

Or even more directly, replace generate_session_id:

    sub generate_session_id {
        open my $fh, "<", "/dev/random";
        read $fh, my $bytes, 20;
        close $fh;
        return unpack("H*", $bytes);
    }

Also have a look at Crypt::Random and the various openssl bindings - these modules provide APIs for cryptographically secure random data.

finalize_session

Clean up the session during finalize.

This clears the various accessors after saving to the store.

dump_these

See "dump_these" in Catalyst - ammends the session data structure to the list of dumped objects if session ID is defined.

USING SESSIONS DURING PREPARE

The earliest point in time at which you may use the session data is after Catalyst::Plugin::Session's prepare_action has finished.

State plugins must set $c->session ID before prepare_action, and during prepare_action Catalyst::Plugin::Session will actually load the data from the store.

        sub prepare_action {
                my $c = shift;

                # don't touch $c->session yet!

                $c->NEXT::prepare_action( @_ );

                $c->session;  # this is OK
                $c->sessionid; # this is also OK
        }

CONFIGURATION

    $c->config->{session} = {
        expires => 1234,
    };

All configuation parameters are provided in a hash reference under the session key in the configuration hash.

expires

The time-to-live of each session, expressed in seconds. Defaults to 7200 (two hours).

verify_address

When true, <$c-request->address>> will be checked at prepare time. If it is not the same as the address that initiated the session, the session is deleted.

flash_to_stash

This option makes it easier to have actions behave the same whether they were forwarded to or redirected to. On prepare time it copies the contents of flash (if any) to the stash.

SPECIAL KEYS

The hash reference returned by $c->session contains several keys which are automatically set:

__expires

This key no longer exists. Use session_expires instead.

__updated

The last time a session was saved to the store.

__created

The time when the session was first created.

__address

The value of $c->request->address at the time the session was created. This value is only populated if verify_address is true in the configuration.

CAVEATS

Round the Robin Proxies

verify_address could make your site inaccessible to users who are behind load balanced proxies. Some ISPs may give a different IP to each request by the same client due to this type of proxying. If addresses are verified these users' sessions cannot persist.

To let these users access your site you can either disable address verification as a whole, or provide a checkbox in the login dialog that tells the server that it's OK for the address of the client to change. When the server sees that this box is checked it should delete the __address sepcial key from the session hash when the hash is first created.

Race Conditions

In this day and age where cleaning detergents and dutch football (not the american kind) teams roam the plains in great numbers, requests may happen simultaneously. This means that there is some risk of session data being overwritten, like this:

  1. request a starts, request b starts, with the same session id

  2. session data is loaded in request a

  3. session data is loaded in request b

  4. session data is changed in request a

  5. request a finishes, session data is updated and written to store

  6. request b finishes, session data is updated and written to store, overwriting changes by request a

If this is a concern in your application, a soon to be developed locking solution is the only safe way to go. This will have a bigger overhead.

For applications where any given user is only making one request at a time this plugin should be safe enough.

AUTHORS

Andy Grundman
Christian Hansen
Yuval Kogman, nothingmuch@woobling.org (current maintainer)
Sebastian Riedel

And countless other contributers from #catalyst. Thanks guys!

COPYRIGHT & LICENSE

        Copyright (c) 2005 the aforementioned authors. All rights
        reserved. This program is free software; you can redistribute
        it and/or modify it under the same terms as Perl itself.