Access to XMLHttpRequest has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

Products

• CA Single Sign On Agents (SiteMinder)
• CA BCS Premier for CA Single Sign-On
• CA Single Sign On Federation (SiteMinder)
• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

User's first SSO login is successful. The original authentication agent refers to another cookie provider agent.

Then later on, user refreshes app by clicking on different icons of the app, by SiteMinder design at times, cookie provider will be called for session validation. 

When the session validation call is made to cookie provider, user gets error below from time to time.

Access to XMLHttpRequest at 'https://........example.com/siteminderagent/SmMakeCookie.ccc?SMSESSION=xxxxxxxxx-xxxxx-xxxxxxxx-xxxx-xxxxxxx&ACCEPT=1&PERSIST=0&TARGET=-SM-HTTPS%3a%2f%2f......' (redirected from 'https://...another_example.com/.......?_dc=xxxxxxxx') from origin 'https://...another_example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

Environment

Release : 12.8.06a

Cause

The problem occurs when there is a CORS preflight HTTP OPTIONS request.

The CORS preflight request occurs when a resource is accessed using a client-side XMLHttpRequest object that includes headers that exclude the request from being considered a "simple" CORS request, e.g. sending a "Content-Type: application/json" header makes the request not "simple".

When the resource being accessed using XMLHttpRequest object requires an update to the SMSESSION cookie, and the realm is configured with a cookie provider, then the response that updates the SMSESSION cookie (with a Set-Cookie header) is an HTTP 302 redirect to the cookie provider's SmMakeCookie.ccc resource.

When the SmMakeCookie.ccc resource is on a different domain than the original XMLHttpRequest, then the CORS preflight request will occur.

The CORS preflight request is an HTTP OPTIONS request with "Access-Control-Request-Method:" and "Access-Control-Request-Headers:" request headers.

Expected: The CORS preflight response MUST be an HTTP 200 or HTTP 204 response, with appropriate CORS headers.

Actual: The CORS preflight response is an HTTP 302 redirect back to the originally requested resource for the XMLHttpRequest object. An HTTP 302 is not a valid response for the CORS preflight OPTIONS request and the browser blocks the flow.

For example:

If the validation request to cookie provider is regular resource, like .jsp, .jsf, .woff2, .pack, with protocol like GET, or POST.  There is no problem, transaction goes through.

If the validation request to cookie provider is rest API call, like ..../rest_example/, or /api_example/, (content is xml based), the browser does not consider the HTTP 302 response to an OPTIONS request to be a valid response.  

It will result OPTIONS call with error "has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request."

Resolution

First of all, ensure cookie provider agent Apache server configuration already added  "Header always set Access-Control-Allow-Origin *".

 

The final solution exists or not, will depend on if the application traffic can be separated between xml api call (OPTIONS) and regular simple content call (GET/POST). 

Also consider what works best in the environment based on the network architecture, any proxy server or load balancer in place, etc.

 

On the cookie provider side web server, customize apache httpd.conf or httpd-ssl.conf with url rewrite, so that HTTP request like ..../rest_example/.... or /api_example/ does not go to cookie provider agent,  instead return HTTP 200 or HTTP 204 response, then the error will be avoided.

Additional Information

https://fetch.spec.whatwg.org/#http-responses