The change in
, where the allowed headers are now checked on the Actual request is causing previously working CORS on 13.5.x to fail. The issue is that on Chrome the Origin header is always sent. So nearly every request will end up as sort of treated as "CORS" (even if they are not and so the pain is all the methods, headers are needed to be added). OPENAM-9606
, checking of the allowed headers was in the preflight but it is now enforced in the Actual flow. This is causing issues since proxies that may be injecting headers to the request will break. Note that the CORS specs does not mention stopping or preventing Actual request (it is only mentioned in the preflight section) and so this explicit enforcement is too strict (or not needed). It seems that neither Tomcat CORSFilter not Spring CORSFilter suffer from such issues (they do enforce preflight allowed-header restrictions). OPENAM-9606
Impact: In the context of Proxies or client browser injecting headers, the OpenAM CORSFiiter will prevent request to be service to these clients.
Details steps outlining how to recreate the issue (remove this text)
1. Setup AM
2. Setup CORS (web.xml) give the origins=*, methods=GET, POST, allowed-headers=x-openam-password,x-openam-username
3.Test preflight (should work)
OPTIONS /openam/json/sessions HTTP/1.1
- Test actual call
GET /openam/json/sessions HTTP/1.1
(Failure as new header DNT is presented).
1) Tomcat CORSFilter
OPTIONAL - If you already investigated the code, please share your finding here (remove this text)
Ideally we should let the client browser do the checks and not enforce CORS. What we should do not make sure we send out the correct policy/header decision.