Reset the cookie session before Mojolicious saves it.

[drgrice1]

Currently the session parameters are set at the beginning of each request. However, if another request occurs for the same process before the first request completes, then the session for the first request gets saved with the parameters of the second request. This is because there is only one Mojoicious session setup for the entire app and the session parameters are global for the process.

To fix this the session parameters need to be set again at the end of the request just before the session is saved.

This is only an issue if there are multiple clients per worker process. Of course that is not the case at this point, but hopefully will be some day, so I am going to go ahead an put this in. This is not critical that it goes into this release, and it can be delayed until after the release.

[pstaabp]

@drgrice1 Anyway to test this? I checkout out this branch and am testing things--seems to work on my development machine. Maybe needs to be tested with multiple clients per worker though.

[drgrice1]

If you are on a development machine, then you would need to set it to a single worker (with no spares) and multiple clients.

One way to test this is to add the following problem to a set in two different courses:

DOCUMENT();

loadMacros('PGstandard.pl', 'PGML.pl', 'PGcourse.pl');

warn 'starting loop test';

$delay = 5;
my $endTime = time + $delay;
while (time < $endTime) {};

warn 'ending loop test';

BEGIN_PGML
This will loop for [`[$delay]`] seconds.
END_PGML

ENDDOCUMENT();

Then log in to the two courses in two different browsers (I used Firefox and Chrome). Then open that problem in the first course in the first browser, and then while that is looping open the problem in the other course in the other browser. Once the problem has rendered in both browsers, go to the developer tools in the first browser and inspect cookies in storage. You will see that there is now a cookie in that browser for the other course (as well as a cookie for the course that user is actually logged into).

With this pull request the above cookie mixup will not happen.

[drgrice1]

By the way, you will also only see warnings in the second browser. In fact, if you want to see the issue with the global warning handler (not fixed in this pull request), then use different warning messages in the problems in the two different courses and then perform the test above again. You will see that only the problem started second gets the warnings, but furthermore, it is shown the warnings that should have been shown in the other browser.