Change the $CookieLifeTime default to 30 minutes to match $sessionKeyTimeout.

[drgrice1]

The cookie lifetime should be the same as the session timeout. It doesn't make sense to keep the cookie any longer than the session is valid for. That only results in stale cookies sitting unusable in the browser cache.

Should we consider increasing both of these settings to 1 hour instead of 30 minutes? I don't think it would be a good idea to increase the default any more than that. Note that the time limit is extended each time that a request is sent to the server. So a 30 minute cookie and session lifetime means that if there must be no communication between the client and server for a full 30 minutes before the session expires.

Also correct the $CookieSameSite documentation in localOverrides.conf. I think this was a copy and paste issue.

[Alex-Jordan]

Are there any problems if $sessionKeyTimeout is changed in Course Config to something like 3 hours, but $CookieLifeTime is still only 30 minutes?

[drgrice1]

Yes, that is a huge problem. Basically, what should really be done is the $CookieLifeTime setting should be deleted entirely, and there should be only one setting which would be $sessionKeyTimeout. The real problem here is that there are two settings that are really for the same thing, and if those settings are not the same, then there either there will be early false timeout issues (that is the case that you just described where $CookieLifeTime is less than $sessionKeyTimeout, or a useless stale cookie will be left in the browser when it shouldn't be (that is the case that $CookieLifeTime is greater than $sessionKeyTimeout.

[drgrice1]

Furthermore, 3 hours is an excessive timeout that should certainly not be the default, and no one really should use a timeout that is that long. That has security vulnerability written all over it.

[drgrice1]

Basically, the one case that should never happen is for $CookeLifeTime to be less than $sessionKeyTimeout. In that case authentication will fail early because the browser will delete the cookie before the session key expires. After which the user will need to sign in again even though the session has not expired since the session key is no longer available in the cookie client side.

The other case is not as serious, but still shouldn't be. There is no point in the browser hanging on to a cookie that won't work.

Perhaps I should do as we discussed in the meeting on Wednesday and take this to where it should be. That is delete the $CookieLifeTime setting.

[drgrice1]

The one case where you would want the timeout to be long (like 3 hours) would be the case that you have a test with a large number of problems per page in which case you might expect the user to sit on one page for a long period of time without any requests being sent to the server. Of course that use case is not recommended (anymore at least). However, instructors don't always adhere to that recommendation. So that would be a case that you would set $session_key_timeout to be longer (with the security implications that entails). If there are still two settings then both should be set to the same longer time. If the $CookieLifeTime is not also set to the lengthened period the user will still have the session timeout, and will not be able to submit the test.

[dlglin]

The one case where you would want the timeout to be long (like 3 hours) would be the case that you have a test with a large number of problems per page in which case you might expect the user to sit on one page for a long period of time without any requests being sent to the server. Of course that use case is not recommended (anymore at least). However, instructors don't always adhere to that recommendation. So that would be a case that you would set $session_key_timeout to be longer (with the security implications that entails). If there are still two settings then both should be set to the same longer time. If the $CookieLifeTime is not also set to the lengthened period the user will still have the session timeout, and will not be able to submit the test.

Prior to 2.17 I would have argued for a longer default timeout because of this. Since that use case is no longer recommended I am okay with a shorter default. If people are using long, monolithic quizzes they can manually set a longer timeout for their course.

I also think that getting rid of $CookieLifeTime and using $session_key_timeout for both is the way to go. There doesn't appear to be a situation where it would make sense for the two to differ.

[Alex-Jordan]

If the two things are becoming one, let's make a new thing with a new name, like $session_timeout.

How terrible is the following idea?

When entering a timed quiz or loading a timed quiz page, everywhere that $session_key_timeout/$CookieLifeTime is used, effectively replace $session_key_timeout/$CookieLifeTime with the quiz's time length if that is a longer amount of time.

This would temporarily make $session_key_timeout/$CookieLifeTime longer for that user. They might end up with a cookie that last a little longer than it needs to. Would there be any consequences worse than that?

[drgrice1]

I am closing this in favor of #2412 which is much better.