Perl Mason | Session Hash not stored in Browser

premsai has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

While working on an existing Perl/Mason project, suddenly it happened that when logging into the site as a user, am getting Access Denied error. I noticed that the login_submit.html page properly authenticates the user and is updating the session variable with the logged-in user's id within the login_submit.html page.

$m->session->{user_id} = $User->user_id;
[download]

Then its redirected to another page ( say my.html ). But once redirected, I am getting Access Denied error because $m->session->{user_id} is no longer accessible there. if I check browser's session storage, I cannot find the session key/value set for user_id .

Any idea what could be the reason ?

I have not changed any configuration setting in Dhandler.pm script. Though I am pasting it below for your reference, in case someone can think of a possible reason.

# Create Mason ApacheHandler object.
my $mason = new HTML::Mason::ApacheHandler(
   comp_root              => [
                                [ document_root => $MYPROJECT::DOCUMEN
+TS_DIR ],
                                [ lib           => "$MYPROJECT::ROOT_D
+IR/mason_lib" ],
                             ],
   data_dir               => "$MYPROJECT::ROOT_DIR/tmp/mason",
   autohandler_name       => '.autohandler.mas',
   dhandler_name          => '.dhandler.mas',
   allow_globals          => [ qw/$dbh $Member %Cookies $Exception $Si
+te/ ],
   decline_dirs           => 1,
   error_mode             => 'fatal',
   request_class          => 'MasonX::Request::WithApacheSession',
   session_class          => 'Apache::Session::MySQL',
   session_use_cookie     => 1,
   session_cookie_name    => 'session_id',
   session_cookie_expires => '+3d',
   session_cookie_resend  => 1,
   args_method   => "mod_perl",
   session_handle         => $dbh,
   session_lock_handle    => $dbh,
);
[download]

Note: Everything was working fine and I am almost 99% sure that I have not changed something that would have broken the login function. I was in fact working on a form update function which updates the User table.

Comment on Perl Mason \| Session Hash not stored in Browser Select or Download Code

Replies are listed 'Best First'.
Re: Perl Mason \| Session Hash not stored in Browser by stevieb (Canon) on Oct 01, 2019 at 13:04 UTC
Welcome to the Monestary, premsai! "Everything was working fine and I am almost 99% sure that I have not changed something that would have broken the login function. I was in fact working on a form update function which updates the User table. " Your best bet is to not guess at these things. If you use a Version Control System, check your commits and see what had changed, and if necessary roll commits back until you find out where things went awry. If you don't use a VCS, I'd make a backup of what you have now, and restore the original software from a backup. Then I'd implement a VCS immediately to keep track of all code changes, as well as write a unit test suite so that changes can be tested reliably.	[reply]
Re: Perl Mason \| Session Hash not stored in Browser by shadowsong (Pilgrim) on Oct 01, 2019 at 13:27 UTC
Hi premsai Not much more to add beyond what stevieb has imparted, but have you altered your Apache config? Do you have a `SetHandler` directive in your Apache config? What configuration directives govern the location of that `my.html` resource? Cheers, Shadow	[reply] [d/l] [select]
Re^2: Perl Mason \| Session Hash not stored in Browser by premsai (Initiate) on Oct 01, 2019 at 16:36 UTC
I haven't altered my apache config. Both login_submit.html & my.html are under the DocumentRoot of my domain. Btw, once login_submit.html sets the session its simply redirected using the piece of code `$m->redirect('my.html');`	[reply] [d/l]
Re^3: Perl Mason \| Session Hash not stored in Browser by stevieb (Canon) on Oct 01, 2019 at 18:59 UTC
Are you the maintainer or administrator of this system? Did you make any changes to the software? If not the latter and not the former, ask your system admins if they did anything on the file system or services configuration that could impede things from working. If the latter and not the former, find out if the admins did any work, and review everything you did code-wise. If the admins were making changes while you were working on code (on a production system I'm assuming), you need to seriously review your maintenance scheduling procedures. If you're the only one who maintains this system, then as cold as this seems, you need to learn better system maintenance, programming and implementation policies. Implement a Version Control System. Any will do, but 'git' has been, and remains (I'd say) the de-facto standard today. To back that up, Github is a free VCS repository hosting site that allows you to store your code remotely. Honestly, the basics of Git can be learned in a day. For a single-developer situation, it's worth a day to pick things up on. The more advanced topics and situations can be learned as-you-go by Internet searches Document your code. This is a very easy thing to do. Most don't do it because they say it wastes time. Well-written documentation can be the light in a train tunnel. At minimum, especially if writing the docs after the code is long in use, it provides you the time to go back through that code, and re-understand what it's supposed to do. Thereafter, a quick look at your docs should point you to where you want to go Write a test suite. I can not emphasize this enough. Whether it's 15 year old code, or code you've just inherited, you can take a few minutes every day to write tests that can become something that will reliably test against regressions and other issues that devolve into situations like the one you're facing right now. Writing tests against code you haven't really worked with in a while (or just cobbled together over time without any thought) allows you to re-familiarize yourself with it. If, during review, you feel "holy crap, this is shitty!", you can begin to 'refactor' the code, but because you now have tests, you can mostly move forward with confidence Implement at least one infrastructure that mirrors your production system (replace system with environment at will) as closely as possible. You should, at minimum have at least one development system, and your production system. Better yet, have a dev, stage and prod. Whether you use VMs, or some form of containerization system, you should always be developing and testing in your dev/stage systems, and only go to prod when all of the above points have been done, and you are certain that moving to prod will not break things. Test your integrations several ways. Test as many edge cases as possible to avoid catastrophe Last but not least, always document yourself a backout strategy. I don't care if this is a test change of a single line of code, or a change of Operating System, software versions or hardware platforms. If you know you're making some changes, document them down, then document down how you'll roll those exact changes out in the event of an emergency Please do not be disillusioned; these are the most basic of things that should be undertaken for any programming language, and for any type of system/environment change control. Nothing I've stated here is strictly Perl-related and shouldn't be construed as such.	[reply]
Re: Perl Mason \| Session Hash not stored in Browser by 1nickt (Canon) on Oct 01, 2019 at 20:32 UTC
Hi, is `$User` supposed to be in the list of allowed globals? Hope this helps! The way forward always starts with a minimal test.	[reply] [d/l]
Re: Perl Mason \| Session Hash not stored in Browser by jcb (Parson) on Oct 01, 2019 at 23:13 UTC
Your configuration suggests that you are storing your sessions in a MySQL database. Have you checked that the DB is still working and not, for example, on a full disk?	[reply]
Re: Perl Mason \| Session Hash not stored in Browser by Anonymous Monk on Oct 01, 2019 at 22:58 UTC
You do not specify how sessions are being persisted (cookies?). If so, is there actually an exchange back to the user's browser which would include a `set-cookie:` header? If you simply redirect to another page, the cookie might never be set on the client side. Nevertheless, "if it worked yesterday," the first step is to (first, stash your changes, then ...) version-control "revert" back to the last known-good state.	[reply]