[Opencms 14/15/16] Unlock bug for detail page container resources (on logout)

[tobias-karrer]

I once reported a problem of detail page container not being unlocked: https://github.com/alkacon/opencms-core/issues/740

Seems fine so far when closing the tab or go to a different page - the then file is unlocked.

We now experienced, that a lot of user often directly log out after editing detail pages, e.g. news or events. The lock then remains and publishing is blocked in the publish dialog.

Isn't it possible to do the unlock on logout, too? (same behaviour as when closing the tab or the browser)

[gWestenberger]

Still can't reproduce this. Logging out via the menu on the top right of the toolbar (behind the user icon) should invalidate the session, which removes all temporary locks on resources for that user.

The only scenario I can think of where this doesn't happen is if you have configured a custom <logoutUri> in your opencms-system.xml, and the page behind that URI doesn't invalidate the session correctly.

Regardless of whether this is the case, the session should still be invalidated after the session timeout configured in web.xml. So the resources should eventually be unlocked.

[tobias-karrer]

Prerequisites: User1 - tobias.karrer.ext - default user for demo system User2 - tobias.karrer - with Project Manager role:

The only scenario I can think of where this doesn't happen is if you have configured a custom in your opencms-system.xml, and the page behind that URI doesn't invalidate the session correctly.

I didn't change any configuration on the demo system. Just created a second user to test.

Steps to reproduce:

1) Login to OpenCms - User1 with Chrome, User2 with Firefox

2) Open event in demo instance, e.g. https://demo.opencms.org/230704/ld_4om1s140qf/mercury-demo/detail-pages/event/Gathering-of-Repetitive-Users-00041/?instancedate=1697706000000 with User 2 and add+edit content section (marked yellow), without closing browser window.

According container page in .detailContainer is locked now for User1:

3) Log out User2. Resource still is locked for User1:

[gWestenberger]

If I do this, the resource gets unlocked at the end (though you need to reload the explorer to notice).

One interesting point: The unlocking only happens on logout if it's the last session for that user. If the servlet container still has an older active session for the same user (which happens e.g. if they don't log out directly, but just clear their cookies), the lock will not be removed at that time. But all of the sessions will eventually time out - the lock is removed then.

[tobias-karrer]

Hmm, did you try with different users?

I wanted to try it again with current cms version, but seems the opencms demo isn't working correctly. We already registerered with different mail addresses and got the note, the demo instance will be created, but never got a mail to confirm the user or to access the demo instance.

[tobias-karrer]

Just checked again with demo instance https://demo.opencms.org/240223/ld_67j6ncpj16/ (OpenCms 16.0_livedemo)

@gWestenberger: still reproduceable with the steps described above

User1 edits page: After logout of user1:

So if editing user doesn't do a reload of the browser window after adding a new content to the page, then directly logs out, the lock on .detailContainer remains. User2 then is not able to publsh the event without switching to VFS to steal the lock before.

[gWestenberger]

I couldn't reproduce this before because I kept reusing the same test page. It only happens for newly created detail-only container pages. The preceding commit should fix it.

[tobias-karrer]

Great. Thanks a lot!