Fixed
Details
Assignee
UnassignedUnassignedReporter
Samuel W. KnowltonSamuel W. KnowltonPriority
NewNew Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Affects versions
Details
Details
Assignee
Unassigned
UnassignedReporter
Samuel W. Knowlton
Samuel W. KnowltonPriority
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Affects versions
Created 24 October 2019 at 16:45
Updated 8 May 2020 at 18:56
Resolved 22 November 2019 at 14:50
This is a regression in 5.3.4. Initial discussion here: https://dev.lucee.org/t/status-of-csrf-functions-and-session-type/6083
We store a struct in the session scope and then build a CFC out of that struct on every request and stash it in the request scope. When a user logs in, we create the security object from their user object and then create the session memento from that in two lines of code:
This works in 5.3.2.
In 5.3.4 or 5.3.5.25, it throws an exception: Session scope does not support CSRF Tokens – but not, interestingly, on the line where we're storing anything in the session. The tag context shows that this is happening in the constructor of the security object that is being placed in the request scope - no interaction with the session (yet) at all. This is the line in question:
If we change the session type to J2EE, it works, but that introduces other issues and is not a desirable workaround for us. It looks like on LDEV-412, it was made possible to use CSRF functions with J2EE sessions (yay!) ... but now it's no longer possible to use them without J2EE sessions.