Catalyst::Plugin::Session::PSGI - minimal configuration access to PSGI/Plack session

This is a module I wrote a few weeks ago and intended to share sooner for feedback, suggestions and guidance.

The module was born out of my discovery that although there’s PSGI support in recent versions of Catalyst the session’s are discrete entities. As I was experimenting with mounting multiple PSGI apps, pretending to be one, I didn’t want to have to manage multiple sessions, or worst still, keep multiple session configurations in sync.

The initial release, documented below, does work in the cases that are relevant to me. I’m concerned that I’ve abused some methods or taken some bad design choices to solve the problem as I percieve it. I’m worried that there are sharp edges and stupid bugs in places I simply haven’t considered yet.

I’m always happy to receive feedback, constructive criticism and patches on my modules and I’d really like to get some feedback, better solutions and tests so that I feel more comfortable dropping the experimental warning in the future.

The project’s home is on github and I’m quite receptive to pull requests that don’t cause me pain and increase the quality of the module.

I’ve included the current POD below. The most-up-to-date version can be found by viewing Catalyst::Plugin::Session::PSGI on MetaCPAN


Catalyst::Plugin::Session::PSGI - minimal configuration access to PSGI/Plack session (EXPERIMENTAL)


version 0.0.1


When running under PSG/Plack with Session middeware enabled you can use the PSGI session as follows:

use Catalyst qw/


This distribution should be considered experimental. Although functional, it may break in currently undiscovered use cases.


If you are running your Catalyst application in a Plack/PSGI environment and using Plack::Middleware::Session you might want to consider using the session information in the PSGI environment.

The Catalyst::Plugin::Session::State::PSGI and Catalyst::Plugin::Session::Store::PSGI modules access the psgix.session.options and psgix.session data to provide the Catalyst session.


As this is an early, experimental release I thought it only fair to share the glaring areas of concern:

  • session expiry

I currently believe that it should be the responsibility of the Plack middleware to expire and clear session data. As far as possible this functionality is unimplemented and unsupported in this distribution.

  • session expiry value initialisation

There was a problem with the session expiry value being unset in the Catalyst related code. This led to sessions always being deleted/expired and never working properly.

There are a couple of dubious areas to resolve this.

sub get_session_data {
    # ...

    # TODO: work out correct place to initialise this
        ||= $c->get_session_expires;

    # ...

is almost certainly the wrong time and place to be initialising this value, but it works and I’m open to clue-sticks and patches.

sub get_session_expires {
    my $c = shift;
    my $expires = $c->_session_plugin_config->{expires} || 0;
    return time() + $expires;

worries me because I cahve no idea where the value for $c-sessionplugin_config->{expires}> is being initialised. I’m concerned that this may become 0 when you least expect it and start expiring all sessions.

  • (lack of) test coverage

Other than basic sanity tests provided by Dist::Zilla this distribution has no tests!

I haven’t found the time to mock up a plack-catalyst test suite to ensure the session is doing the right thing. Once again I’m open to clue-sticks and patches.


Catalyst, Catalyst::Plugin::Session, Plack::Middleware::Session, Catalyst::Plugin::Session::State::PSGI, Catalyst::Plugin::Session::Store::PSGI




This software is copyright (c) 2011 by Chisel Wright.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

Leave a comment

About Chisel