No review necessary. The original fix which is simply being re-merged was reviewed.

For clarification on the status of this issue.

It is currently resolved in Confluence 2.10.1 and later version of Confluence 2.10.

It is currently not resolved in Confluence 3.0. It is scheduled to be fixed in Confluence 3.0.1.

This fix was accidentally removed from the Confluence development trunk part-way through the 3.0 release cycle. It will be re-instated in Confluence 3.0.1.

Hi Christoph,

This is possible, but it might cause problems with other plugins that may be expecting the non seraph keys to still be present. I'll try to add in the property com.atlassian.logout.invalidatesession for 3.0, which when true will invalidate the Session after wiping the keys and triggering the firing of the event, which should make your plugin unnecessary.

Regards,
Andrew lynch

I have a question to the current implementation.
I was a supporter of the bug that caused this issue, i.e. I wanted sessions to be invalidated upon logout.
As this was not possible at the time when I started to integrate confluence in our environment, I came up with a plugin that listens for logout events and invalidates the session upon such an event.
I was pleased to hear that invalidation should become standard and a bit disappointed (i.e. I thought that I would have to use my plugin again) as it didn't.

Now, I am upgrading from 2.10 to 2.10.3 and have to find out that even my workaround is not possible any longer, because the logout event is sent before all non-seraph session keys are removed, so a session invalidation in the event listener results in a exception:

java.lang.IllegalStateException: getAttributeNames: Session already invalidated

Therefore, I wonder whether it might be possible to either send the logout event after the removal of the attributes or to handle the case where the session got invalidated before, i.e. in an EventListener or - even better - in the authenticator used.

Thank you for considering my input and no bad feelings on my side, I like your work!

Kind regards,
Christoph

I just changed LogoutAction to remove all session keys that don't start with "seraph". Given session attributes should be the only place we are storing session-related state, I can't really see how this is any less secure than invalidating the session.

Checked into 2.10-stable and trunk.

We didn't have time to fix this properly for 2.10, so this issue is left open.
By specifying com.atlassian.logout.preservesession=true as a system property, the session will not be invalidated from 2.10 onwards.