-
Task
-
Resolution: Done
-
L3 - Default
-
7.13.0
-
None
Camunda BPM Run provides easy-to-setup CORS and authentication support. When configuring both together there are some things to look out for.
Not every browser/REST-client adheres to the CORS specification in the same way. Some browsers require certain HTTP headers while others are laxer.
The following headers are relevant when dealing with CORS and authentication:
| HTTP Header | Header Type | Purpose | Link |
|---|---|---|---|
| Access-Control-Allow-Credentials | response header | In a response to a CORS preflight request, it indicates whether or not the actual request can be made using credentials. Some browsers rely on this and will fail the authenticated actual request. | [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials ] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials |
| Authorization | request header | The header contains the credentials to authenticate the request. This header is not allowed by default. Requests that contain this header will be considered invalid by the CORS filter. | [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization ] https://www.sjoerdlangkemper.nl/2018/09/12/authorization-header-and-cors/ |
| XSRF/CSRF and other headers | Other headers that could be necessary, (e.g. for CSRF prevention) must also be allowed by the CORS filter. | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers |
Since browsers and other REST-clients handle CORS differently one solution would be to make the allowed HTTP headers in a CORS request configurable in the Camunda BPM Run configuration. This way, the users can adapt Run to their environments.
AT:
- Make the response header Access-Control-Allow-Headers configurable in the response of the CORS filter
Side note:
- Consider making all of the parameters of the CORS filter configurable: https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter