lochmueller/staticfilecache

BE user get cached pages served after one hour

schliesser opened this issue · 6 comments

schliesser commented

Bug Report

Current Behavior
BE user logs in at the morning. Makes some changes and can see the changes. Later the day (more than 1 hour after login), he makes some more changes and can't see them. He gets the cached version served.

Expected behavior/output
BE users always get the uncached version of a page served.

Environment

  • TYPO3 version(s): 10.4.27
  • staticfilecache version: 12.4.4
  • Is your TYPO3 installation set up with Composer (Composer Mode): yes
  • OS: unix plesk server / ddev on macos

Possible Solution
IMHO the lifetime of the cookie staticfilecache must be equal or higher than be_typo_user or at least much longer than 1 hour.

Idea:

Set the lifetime of the staticfilecache cookie till browser session ends (or maybe even 1year). When the BE/FE session now expires, the staticfilecache cookie is still valid and returns the uncached page. But then there is a middleware which checks for any existing FE/BE session. If there is no valid session anymore, the staticfilecache cookie is deleted. On the next page call the user gets the cached pages served. When he logs in again, the staticfilecache cookie is created again and the progress repeats.

That way, it doesn't really matter to have a very long cookie lifetime, as it will be deleted by the middleware.

The only drawback I can see is, that the user get one time a uncached page served if he has the cookie still set. But I think this is much better than having annoyed editors not seeing their changes.

Additional context
Slack discussion leading to this issue https://typo3.slack.com/archives/C9LRD4LSJ/p1651052878186619

schliesser commented

fyi There are session timeout settings for FE and BE in the Install Tool with those defaults, but the cookies itself never expire.

$GLOBALS['TYPO3_CONF_VARS']['BE']['sessionTimeout'] = 28800;
$GLOBALS['TYPO3_CONF_VARS']['FE']['sessionTimeout'] = 6000;
schliesser commented

Some thoughts:

I wonder why frontend users should always bypass the staticfilecache? I think backend users should always bypass the staticfilecache to be able to see the latest preview. But frontend users normally have only a small user related section which is not cacheable due to USER_INT etc. The rest of the page should show the same content as always?!
Do I miss something?
Should we have different cookies for frontend and backend user logins? This way the page owner can decide in the htaccess how to handle them? But it would add more complexity.

Just some thoughts about the cookie handling which came up during putting this PR together :-)

lochmueller commented

@schliesser
Related to the lifetime. Perhaps we should set this to default "null" https://github.com/lochmueller/staticfilecache/blob/master/Classes/Service/CookieService.php#L22 and use $GLOBALS['TYPO3_CONF_VARS']['FE']['sessionTimeout'] in case of "null"?

FE users have to bypass the StaticFileCache because also non _INT objects are possible. As far as I know, there is a different page cache for logged-in users and users without valid session and SFC only handle the "public version" of the URI.

Regards,
Tim

schliesser commented

@lochmueller
thanks for the fast merge and the explanation!

I think we don't need to think about the lifetime at all and could use 0 as default value. This way the cookie is valid until browser session ends. The only line where we need to set the lifetime is in the unsetCookie() method.
The CookieCheckMiddleware deletes the cookie during the logout process (load the "successfully logged out"-page), the next page a user navigates to is already fetched from the cache. We would only have a problem if the CookieCeckMiddleware failes to unset the cookie.

I'll open an other PR, so you can decide how to continue ;-)

André

lochmueller commented

Hey @schliesser

you are right. We could use the middleware to drop the cookie.

But I don't know if the session cookie is the best way. Keep in mind, that a session cookie is not enough, because the FE user can keep the login session (option in EXT:felogin and core). If the user close the browser the SFC Cookie is gone. So there is no SFC cookie that can checked by the htaccess file, but the user is still logged in. Or do I miss something?

If there a multiple cases, I suggest increasing the cookie lifetime and drop an invalid cookie via middleware instead of sending cached content to valid authenticated users?!

Regards,
Tim

lochmueller commented

I would close this issue. Thanks for the rework. I will check this change in the next major release for v12 again.

  • 👍1