| Catalyst::Plugin::Session(3pm) | User Contributed Perl Documentation | Catalyst::Plugin::Session(3pm) |
Catalyst::Plugin::Session - Generic Session plugin - ties together server side storage and client side state required to maintain session data.
# 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");
}
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.
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.
$c->session->{foo} = "bar"; # This works.
$c->session(one => 1, two => 2); # And this.
$c->session({ answer => 42 }); # And this.
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 that 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
}
}
NOTE: This method will also delete your flash data.
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.
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
...
}
$c->change_session_expires( 4000 );
Note that this only works to set the session longer than the config setting.
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.
This currently ensures that the session ID string is any amount of case insensitive hexadecimal characters.
Currently it returns a concatenated string which contains:
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.
This clears the various accessors after saving to the store.
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
}
$c->config('Plugin::Session' => {
expires => 1234,
});
All configuation parameters are provided in a hash reference under the "Plugin::Session" key in the configuration hash.
The purpose of this is to keep the session store from being updated when nothing else in the session is updated.
Defaults to 0 (in which case, the expiration will always be updated).
Defaults to false.
Defaults to false.
The hash reference returned by "$c->session" contains several keys which are automatically set:
"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" special key from the session hash when the hash is first created.
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:
For applications where any given user's session is only making one request at a time this plugin should be safe enough.
Andy Grundman
Christian Hansen
Yuval Kogman, "nothingmuch@woobling.org"
Sebastian Riedel
Tomas Doran (t0m) "bobtfish@bobtfish.net" (current maintainer)
Sergio Salvi
kmx "kmx@volny.cz"
Florian Ragwitz (rafl) "rafl@debian.org"
Kent Fredric (kentnl)
And countless other contributers from #catalyst. Thanks guys!
Devin Austin (dhoss) <dhoss@cpan.org>
Robert Rothenberg <rrwo@cpan.org> (on behalf of Foxtons Ltd.)
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.
| 2022-06-03 | perl v5.34.0 |