Difference between 3.1.0 and 4.1.0 with respect to where the token is saved in the container

[deepak229]

In 3.1.0, the token was saved as a session attribute while we see that it is stored in InMemoryTokenHolder. Is that the case always or will it ever be written to session?

With 3.1.0, we depended on the value stored in the session to apply some business logic. It looks like the token is no more stored in the session as a result, we need to refactor our logic a bit during the upgrade.

Even withe the csrfguard-extension-session it does not store the new token generated in session. SessionAttribute action in that extension is called only to handle an exception thrown during validation.

@forgedhallpass Please confirm. Thank you in advance.

[forgedhallpass]

Hello @deepak229,

the token was saved as a session attribute while we see that it is stored in InMemoryTokenHolder. Is that the case always or will it ever be written to session?

Starting from version 4.0 a new abstraction layer (LogicalSession) has been introduced to support both stateless and stateful web applications. This means that in case of stateless web apps, there is no container session to rely on. For this reason, the TokenService accesses tokens through the TokenHolder interface. The reference implementation for this interface is the InMemoryTokenHolder, which can serve both use cases, but you could also create your own implementation for it (e.g. a DatabaseTokenHolder).

Saving the tokens to the session is not possible anymore, because it would create a tight coupling with the HttpSession.

Even withe the csrfguard-extension-session it does not store the new token generated in session. SessionAttribute action in that extension is called only to handle an exception thrown during validation.

Indeed.

CSRF Guard provides a way of executing pre-defined and/or custom actions when specific errors or potential attacks are detected. These actions implement the IAction interface. The SessionAttribute is an example of such action, that enables storing CsrfGuardExceptions to the container session, under a user-defined attribute.

TLDR: starting from version 4.0, tokens are not stored on the HTTP session anymore.