CORS has two parts, the server and the client side. It is a protocol wholly contained in the http headers of client requests and server side responses.
The server controls what is allowed and what is not allowed. The client uses these headers to start the CORs 'handshake' process.
Let's first examine an outbound request from a browser's front end code.
From this request, the headers tell us the destination Host and the Origin:
Host: function.azurewebsites.net
Origin: http://localhost:4200
These values are set by the browser and cannot be overridden.
They also have nothing to do with routing.
The Host value defined where the request is destined, and the Origin defines where it came from.
Sec-Fetch-Site
Sec-Fetch-Site: cross-site
The browser sets 'cross-site' by default anytime the Origin and Host are not the same site. This header value cannot be overridden.
Server Side
In Azure Functions there is a tab named "Cors" which looks like this:
What is shown is that we are allowing any Origin header value of
https://fakeName.azurewebsites.net
http://localHost:4200
To access our function application.
Don't mistake these values for routes (as I did in the early days). These are not routes they are key value pairs of {Origin:value}.
This should solve CORS errors which must allow Origins on the server side.
JWP2021
Top comments (0)