I was recently doing a test of adding the built-in functions for CSRF
protection ( CSRFGenerateToken( [ key [, forceNew ] ] ) and CSRFVerifyToken(
token [, key ] ) ), but I ran into an issue not enumerated in the
documentation (
CSRFGenerateToken() :: Lucee Documentation ).
The additional form field was:
<input type=“hidden” name=“csrf_token” value="#CSRFGenerateToken("index
“,true)#” />
However, when I ran the page, an exception was thrown:
this function only works with CF Sessions
We are using “j2ee” as the sessionType, so does this mean that the CSRF
protection only extends to CF Sessions? And is there any workaround short
of changing the session type away from j2ee?
I’m bumping this, because it doesn’t seem to have ever been resolved. Is
there any way we can get CSRF functions that work with J2EE sessions?On Thursday, May 14, 2015 at 3:20:25 PM UTC-4, Jason Brookins wrote:
I was recently doing a test of adding the built-in functions for CSRF
protection ( CSRFGenerateToken( [ key [, forceNew ] ] ) and CSRFVerifyToken(
token [, key ] ) ), but I ran into an issue not enumerated in the
documentation (
CSRFGenerateToken() :: Lucee Documentation ).
The additional form field was:
<input type=“hidden” name=“csrf_token” value="#CSRFGenerateToken("index
“,true)#” />
However, when I ran the page, an exception was thrown:
this function only works with CF Sessions
We are using “j2ee” as the sessionType, so does this mean that the CSRF
protection only extends to CF Sessions? And is there any workaround short
of changing the session type away from j2ee?
Hey Jason,
First, if you’d like to see progress on this issue, you should file a
bug report for this if you haven’t already (http://bugs.lucee.org will
redirect you to Jira where you can log in and file this as a bug).
Second, as a workaround you can always generate your own CSRF token and
validation… the function really just spits out some random alphanumeric
string, which is stored in the SESSION scope, and then validates that
random alphanumeric string is sent with the request and checked for
equivalence against the stored SESSION variable. That’s what we did before
CFML had the CSRF functions, anyway 
– DennyOn Friday, April 15, 2016 at 9:12:28 PM UTC-4, Jason Brookins wrote:
I’m bumping this, because it doesn’t seem to have ever been resolved. Is
there any way we can get CSRF functions that work with J2EE sessions?
On Thursday, May 14, 2015 at 3:20:25 PM UTC-4, Jason Brookins wrote:
I was recently doing a test of adding the built-in functions for CSRF
protection ( CSRFGenerateToken( [ key [, forceNew ] ] ) and CSRFVerifyToken(
token [, key ] ) ), but I ran into an issue not enumerated in the
documentation (
CSRFGenerateToken() :: Lucee Documentation ).
The additional form field was:
<input type=“hidden” name=“csrf_token” value="#CSRFGenerateToken("index
“,true)#” />
However, when I ran the page, an exception was thrown:
this function only works with CF Sessions
We are using “j2ee” as the sessionType, so does this mean that the CSRF
protection only extends to CF Sessions? And is there any workaround short
of changing the session type away from j2ee?
Nevermind… I see you filed a bug report already. Time to poke the bear
with a stick, I reckon :)On Friday, April 15, 2016 at 9:12:28 PM UTC-4, Jason Brookins wrote:
I’m bumping this, because it doesn’t seem to have ever been resolved. Is
there any way we can get CSRF functions that work with J2EE sessions?
On Thursday, May 14, 2015 at 3:20:25 PM UTC-4, Jason Brookins wrote:
I was recently doing a test of adding the built-in functions for CSRF
protection ( CSRFGenerateToken( [ key [, forceNew ] ] ) and CSRFVerifyToken(
token [, key ] ) ), but I ran into an issue not enumerated in the
documentation (
CSRFGenerateToken() :: Lucee Documentation ).
The additional form field was:
<input type=“hidden” name=“csrf_token” value="#CSRFGenerateToken("index
“,true)#” />
However, when I ran the page, an exception was thrown:
this function only works with CF Sessions
We are using “j2ee” as the sessionType, so does this mean that the CSRF
protection only extends to CF Sessions? And is there any workaround short
of changing the session type away from j2ee?