I currently installing camunda-bpm-wildfly-7.10.0 on Wildfly and run into a user session problem: The session is lost e.g at the XHR POST request invoked by pressing create user at the add new user form. By help of the Firefox Developer Tools I was able to see the anwer telling about a wrong XSRF-TOKEN.
The issue vanishes if I disable the CSRF filter at web.xml. The filter feature seems to be introduced with >=7.9
In conjunction with an request header entry X-XSRF-TOKEN, I notice even two additional entries called XSRF-TOKEN in the Cookie:-header entry. Maybe the filter is confused by this.
@Camunda: Please verify this issue. If you provide a bugfix as a classfile for org.camunda.bpm.webapp.impl.security.filter.CsrfPreventionFilter , I may test it.
I’m facing a similar issue, after upgrading camunda from 7.9.0 to 7.10.0 version and adding CsrfPreventionFilter filter, I cannot create user, also cannot delete user, or open Tasklist.
@gjaekel Do you still have this issue or you solved it?
Today I got time to look at it. But re-reading your answer I wonder if this should help because Camunda already is running on the root application context.
If you want to create a user with the REST API of the web application at http://localhost:8080/camunda/api/… you will run into this issue with the CSRF filter. It’s added for security reasons.
I’m not talking about the REST API. At the moment, wee just use the web applications parts. The application is running at the root context of some domain, but without disabling the CSRF filter in the web.xml, one is kicked out at every serious action. If I get some time, I’ll investigate what happens if I define server.servlet.context-path="/" and enable the CSRF filter.
most likely the token get lost somewhere in the load balancer, proxy or Apache httpd configuration.
I had a similar problem with a wrong configuration in the load balancer. Here the admins missed the sticky session configuration. I can assume that your configuration can get tricky.
No, that don’ help. The configuration not tricky in any way and proved by more than fifty other application. In addition, as written there’s just a single instance of Camunda running. Therefore, there’s no load balancing but a single route to the used Wildfly instance.
As I wrote, the token is not lost but there are more than one token “cruising around” in the header and the application seems to be confused by this, Until yet, I got not time to figure it out in detail because our developers need a running Camunda. But as soon I have copied the setup to our approval state, I’m free to do some further investigation about the CFRF issue on our test stage.