We were testing the 5.3.4 RC this morning and encountered this error when creating a session security object:
Session scope does not support CSRF Tokens.
If we change our session type from application to JEE, it works.
We store sessions in Redis but (currently) have sessionCluster = false.
I know there are some outstanding issues/bugs related to CSRF & sessions, e.g.
https://luceeserver.atlassian.net/browse/LDEV-2137
https://luceeserver.atlassian.net/browse/LDEV-784
But it’s not clear to me which permutation of configuration is ideal to dodge some of these issues. Our workaround for 2137 was to use a CSRFGenerateToken call as follows:
CSRFGenerateToken( user.getUserID() & dateFormat( now(), “m/dd/yyyy” ) )
The use of the key argument dodges the cache issue from 2137 and that had been working for us in 5.3.2.
My question is: Is there someplace that the different functionality between these two modes is documented? Lucee admin suggests that JEE is the ‘correct’ value for a clustered application, and that’s the direction we’re moving in, but the implications of changing this aren’t entirely clear.
I’d also like to document the restriction on using the application type with CSRF functions in the session, if someone could explain the nature of the change.