Re: CGI::Session Cookies

Note that CGI::Session was last released in 2011, its maintainer hasn't made any CPAN releases since 2012, it has 23 open issues on RT, and its maintainer hasn't made any commits to the repo since 2015 and it is now marked read-only. In general, CGI.pm, while it still works, isn't really recommended any more, and especially not for new developments. In particular, you're using its HTML generation functions, which are deprecated (I'm printing strings below, which isn't recommended either, but since this is about cookies and the strings are entirely static, I think it's ok for this demo).

For more modern approaches, see e.g. this node, in particular I personally like Mojolicious, which supports (client-side) sessions out of the box, and I have quite a few examples on my scratchpad, for example a comparison between Mojo and CGI.pm here.

Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”.

Note that this means that explicitly setting the value to "Lax" doesn't seem strictly necessary, other than perhaps to quiet the warning.

Anyway, one way that I see that this issue could be patched is by subclassing CGI::Session and overriding its cookie method, which is what generates the cookies (this is called by its header method, which is why your approach to reaching into the query object didn't work). Though CGI::Cookie doesn't document it, which I am guessing may be an oversight instead of an intentional omission, it does have accessors to change its samesite etc. properties.

use warnings;
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
use CGI::Session;

package CGI::Session::Mine {
    use parent 'CGI::Session';
    sub cookie {
        my $self = shift;
        my $cookie = $self->SUPER::cookie(@_);
        $cookie->secure(1);
        $cookie->samesite('Lax');
        return $cookie;
    }   
}

my $CS = CGI::Session::Mine->new();
$CS->expire('+1d');
print $CS->header();
print '<!DOCTYPE html><html><head><title>Test</title></head>'
    .'<body><h1>Test</h1></body></html>';
[download]

An alternative is to patch directly into CGI::Session using Class::Method::Modifiers, since the former's cookie method does support the passing of additional parameters to the constructor:

use warnings;
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
use CGI::Session;
use Class::Method::Modifiers 'around';

around 'CGI::Session::cookie' => sub {
    my ($orig, $self) = (shift, shift);
    $orig->($self, @_, secure=>1, samesite=>'Lax');
};

my $CS = CGI::Session->new();
$CS->expire('+1d');
print $CS->header();
print '<!DOCTYPE html><html><head><title>Test</title></head>'
    .'<body><h1>Test</h1></body></html>';
[download]

In fact, you can mix and match the two approaches of patching the method vs. subclassing, and modifying the returned cookie vs. passing additional arguments to the method.

While testing further and trying CGI::Cookie, I'm still not able to assign "SameSite" values

This workaround works for me, perhaps your version of CGI::Cookie is too old?

Comment on Re: CGI::Session Cookies Select or Download Code

Replies are listed 'Best First'.
Re^2: CGI::Session Cookies by JayBee (Scribe) on Jul 09, 2022 at 22:18 UTC
Interesting new ways to write html not using CGI.. I will have to review Mojo and re-learn perl after this project. Apparently old-school approach has a count-down timer, esp with tech. UPDATE: Used your 'Subclassing' sript... Brilliant! :D Thank you. Even added httponly, as js will never use this. `$cookie->secure(1); $cookie->samesite('Strict'); $cookie->httponly(1);` [download]	[reply] [d/l]


Think about Loose Coupling
	PerlMonks