Cataly...Session(3pm)

📦
version 0.44 · 5 versions
, in ubuntu resolute, ubuntu stonking

💖 NAME 💖

okay so this page is for Catalyst::Plugin::Session — the header gets squished like Cataly...Session(3pm) and says "User Contributed Perl Documentation", but bestie, it's Catalyst::Plugin::Session in section 3pm. It's the Generic Session plugin: it ties together server side storage and client side state required to maintain session data. periodt.

✨ SYNOPSIS ✨

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

# 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, and honestly it's giving infrastructure.

  • The first part, the State — this is about getting the browser to repeat back a session key, so the web application can identify the client and logically string several requests together into a session.
  • The second part, the Store — this deals with the actual storage of information about the client. This data is stored so that it may be revived for every request made by the same client.

This plugin links the two pieces together. slay. 💅

🎀 RECOMENDED BACKENDS 🎀

Yes, it's spelled RECOMENDED in the source. We're keeping it iconic. 😌

  • 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. That's it, that's the method. 💖

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.

You can also set session keys by passing a list of key/value pairs or a hashref. Like:

$c->session->{foo} = "bar";      # This works.
$c->session(one => 1, two => 2); # And this.
$c->session({ answer => 42 });   # And this.

session_expires

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.

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.

🚨 Note: use of the flash is an easy way to get data across requests, but it's also strongly disrecommended, due it it being inherently plagued with race conditions. This means that it's unlikely to work well if your users have multiple tabs open at once, or if your site does a lot of AJAX requests.

Catalyst::Plugin::StatusMessage is the recommended alternative solution, as this doesn't suffer from these issues.

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

    }
}

clear_flash

Zap all the keys in the flash regardless of their current state. poof. 💅

keep_flash @keys

If you want 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.

🚨 NOTE: This method will also delete your flash data.

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('Plugin::Session' => { expires => 10000000000 }); # "forever"
(NB If this number is too large, Y2K38 breakage could result.)

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

change_session_id

By calling this method you can force a session id change while keeping all session data. This method might come handy when you are paranoid about some advanced variations of session fixation attack.

If you want to prevent this session fixation scenario:

0) let us have WebApp with anonymous and authenticated parts
1) a hacker goes to vulnerable WebApp and gets a real sessionid,
   just by browsing anonymous part of WebApp
2) the hacker inserts (somehow) this values into a cookie in victim's browser
3) after the victim logs into WebApp the hacker can enter his/her session

you should call change_session_id in your login controller like this:

if ($c->authenticate( { username => $user, password => $pass } )) {
  # login OK
  $c->change_session_id;
  ...
} else {
  # login FAILED
  ...
}

change_session_expires $expires

You can change the session expiration time for this session;

$c->change_session_expires( 4000 );

Note that this only works to set the session longer than the config setting.

🧚 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('Plugin::Session') with the default values listed in CONFIGURATION.

prepare_action

This method is extended.

Its 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_headers

This method is extended and will extend the expiry time before sending the response.

finalize_body

This method is extended and will call finalize_session before the other finalize_body methods run. Here we 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 simply a hexidecimal string of raw bytes from the system entropy source, e.g. /dev/urandom.

session_hash_seed

This method returns raw bytes from the system random source. It is no longer used but exists for legacy code that might override generate_session_id but still uses this method.

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.

The original also lists these internal methods with no extra descriptions, bestie — they're just chilling here in this exact order:

  • calculate_extended_session_expires
  • calculate_initial_session_expires
  • create_session_id_if_needed
  • delete_session_id
  • extend_session_expires — Note: this is not used to give an individual user a longer session. See change_session_expires.
  • extend_session_id
  • get_session_id
  • reset_session_expires
  • session_is_valid
  • set_session_id
  • initial_session_expires

🌈 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 ⚙️

ok bestie listen, you set all of this up like so:

$c->config('Plugin::Session' => {
    expires => 1234,
});

Every single config param lives inside a hash ref hanging off the Plugin::Session key in your config hash. That's the vibe. 💅

  • expires — the time-to-live of each session, counted in seconds. Defaults to 7200 (which is literally two whole hours ✨).
  • expiry_threshold — only refresh the session's expiry time if it would otherwise expire within this many seconds from now. Why tho? So your session store doesn't get hammered with writes when literally nothing else in the session changed. Defaults to 0, and at 0 the expiration gets updated always. 🫶
  • verify_address — when true, $c->request->address gets checked at prepare time. If it doesn't match the address that started the session, the session gets yeeted. Defaults to false.
  • verify_user_agent — when true, $c->request->user_agent gets checked at prepare time. If it doesn't match the user agent that started the session, the session gets deleted. Defaults to false. 😭
  • flash_to_stash — this one is iconic for making actions behave the same whether they got forwarded to or redirected to. At prepare time it copies the contents of flash (if there are any) over to the stash. Main character convenience behavior fr.

🔑 SPECIAL KEYS 🔑

The hash ref that $c->session hands back? It's got a few keys that get set automatically, no cap:

  • __expires — nope, this key does not exist anymore. Use session_expires instead, bestie.
  • __updated — the last time a session got saved to the store.
  • __created — the time when the session was first created. its birthday 🎂
  • __address — the value of $c->request->address back when the session was created. Heads up: this only gets populated if verify_address is true in your config.
  • __user_agent — the value of $c->request->user_agent at the time the session was created. Again, only populated when verify_user_agent is true in the config.

💀 CAVEATS 💀

🔄 Round the Robin Proxies 🔄

ngl, verify_address could make your site literally inaccessible to users sitting behind load-balanced proxies. Some ISPs hand out a different IP to every single request from the same client because of that proxying situation, and if you're verifying addresses, those users' sessions just cannot persist. periodt.

So if you want those users to still get in, you've got two moves: either disable address verification entirely, or put a checkbox in the login dialog that tells the server "hey it's fine if this client's address changes." And when the server sees that box ticked, it should delete the __address special key from the session hash at the moment 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. Which means there's some real risk of session data getting overwritten, kinda 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 💀
For applications where any given user's session is only making one request at a time, this plugin should be safe enough. ✨

👑 AUTHORS 👑

  • Andy Grundman
  • Christian Hansen
  • Yuval Kogman, nothingmuch@woobling.org
  • Sebastian Riedel
  • Tomas Doran (t0m) bobtfish@bobtfish.net — current maintainer, holding it down 🙌
  • Sergio Salvi
  • kmx kmx@volny.cz
  • Florian Ragwitz (rafl) rafl@debian.org
  • Kent Fredric (kentnl)
  • And countless other contributers from #catalyst. Thanks guys! 💖

🌈 Contributors 🌈

  • Devin Austin (dhoss) <dhoss@cpan.org>
  • Robert Rothenberg <rrwo@cpan.org>
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.

okay that's the whole page bestie, you're so welcome 🎀 this was documented by the lovely people over at perl v5.40.1, dated 2025-08-10, and it's Cataly...Session(3pm) — go forth and session responsibly 🦋✨💜

📦 where this page comes from