October 2011 Archives

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

By Chisel on October 22, 2011 3:00 PM under Perl

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

NAME

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

VERSION

version 0.0.1

SYNOPSIS

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

use Catalyst qw/
    Session
    Session::State::PSGI
    Session::Store::PSGI
/;

EXPERIMENTAL

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

SUMMARY

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.

AREAS OF CONCERN

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
    $psgi_env->{'psgix.session.expires'}
        ||= $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.

AUTHOR

Chisel chisel@chizography.net

COPYRIGHT AND LICENSE

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

0 comments

Simple config for the perl debugger

By Chisel on October 21, 2011 3:36 PM under Perl

I’ve been using a config file ($HOME/.perldb) for some time now. While it’s not the biggest file in the world it automates settings that I’m far too lazy to type every time I fire the beast up.

.perldb

$DB::deep=1000 ;
sub afterinit { push @DB::typeahead, "{{v" unless $DB::already_curly_curly_v++; } ;
parse_options('dumpDepth=2 NonStop=1') ;

The Explanation

$DB::deep=1000

This increases the limit for the recursion limit from 100 - a level that’s so low I seemed to be hitting it all the time

sub afterinit { … }

I like ‘v’ as a way of seeing where I’m at in the code, with some context. I hate typing it myself every time the debugger returns to the prompt.

This small piece of voodoo simply pushes the command ‘{{v’ onto the list of things to do when the debugger has finished initialising. ‘{{’ is “Add to the list of debugger commands to run before each prompt” and ‘v’ is “View window around line”.

Until recently the command was just

sub afterinit { push @DB::typeahead, "{{v" } ;

This was annoying if you used ‘R’ to restart the script you were debugging as you’d call ‘{{v’ again and force an extra ‘v’ at every prompt. This would increase every time you used ‘R’.

The variable is forced into the DB:: namespace otherwise you’d increment a value scoped to the afterinit() sub.

parse_options(‘dumpDepth=2 NonStop=1’)

Set a couple of useful options:

dumpDepth=2 limits the depth of variables shown if you use ‘x’ or similar on a variable. Especially useful if you’re forever accidentally examining DBIx::Class objects.
NonStop=1 saves you from having to type ‘c’ after everything has initialised so that your program will run. Useful if you drop in $DB::single = 1 statements as your initial breakpoint in the source.

6 comments