Thanks steven.
> why use javascript to set those tokens. qa provides token settings function, why not call them and do a regex replace server side?
Funny. I seem to have been confused. It's as you say. I mimic javascript for CSRF on the net. Since the structure of Q2A is good, I did not need to do that.
> From my read, exposing session_id is discouraged in general. One could hash the session_id with form name, but that is still not optimal. The best security is a 'nonce' (hash that occurs only once) using timestamp, saving it to form and session and checking it if form submitted. I believe that is what qa is doing with the provided functions already.
Yes. I agree. However, since one time token in the form is also cached, I thought we can not use it. This change has begun from Yerbol's report below.
http://www.question2answer.org/qa/46578/updated-qa-caching-plugin-v0-3?show=46595#a46595
But, in my environment, this issue do not occur. I investigated CSRF protection logic again. As result, I thought changes about CSRF protection logic in caching plugin is not needed basically. However, we might be necessary to correct cached time stamp.
How do you think about it?