I have a site with two https servers. One (frontend) serves the user interface created from static pages. The other (backend) serves the microservice. Both of them use the same X509 (test) certificate to identify themselves. Individually, I can connect to them as https, requiring a client certificate "tester".
We hid CORS issues so far by going through the nginx setup, which makes the frontend and backend that they are the same Origin. I applied “Access-Control-Allow-Origin” headers, “Access-Control-Allow-Credentials” to all requests; with methods, headers for pre-flight check requests (OPTIONS).
In Chrome, a cross site like this works fine. I can see that the front-end and backend URLs are different sites. I see OPTIONS requests that are made before the backend requests.
Although Chrome doesn't seem to need it, I found an xmlhttprequest object that will be used to execute the request and made xhr.withCredentials = true on it, because it looks like what fetch.js does under the hood when he gets "credentials":"include" . I noticed that there is an xhr.setRequestHeader function that I can use to make Firefox happy.
- Firefox behaves the same for UI calls. But for all backend calls, I get 405. When he does this, there is no network connection to the server. The browser simply decided that it was 405 without making any https request. Although this is different from Chrome, it makes sense. Both the interface interface and the internal server must select a client certificate. When I connected to the user interface, I selected the tester certificate. When he makes a request for the backend, he can assume that the same client certificate must be used to access the internal content. But perhaps it suggests that it may be different, and there is something else that I need to tell Firefox.
Does anyone here use CORS in combination with two methods of SSL certificates like this and have this Firefox issue and fix it somewhere. I suspect this is not a server-side fix, but something the client needs to do.
source share