In first part we have seen what CORS means and when it should be used. Lets take this further to understand how these CORS request and responses look like and how does it work.
How does CORS Requests work?
A CORS request from main web site hops in two separate requests, and these requests are called as Preflight and Actual requests.
First call goes to service with the request to check what operation can be performed on service by CORS calls, and returns the response with provided permissions. Based on the response from first call your applications need to make second call to the service.
So service has to impose certain rules on its side to give only specific permission to execute actions on it by external CORS calls, these rules are called as CORS RULES
Let’s understand in detail what exactly happened in each of these calls.
Preflight request queries the CORS restrictions imposed by the service. The preflight request is required unless the request method is a simple method, meaning GET, HEAD, or POST.
The actual request, made against the desired resource.
How do CORS rules look like?
Following is a sample of a single CORS rule.
<Cors> <CorsRule> <AllowedOrigins>http://www.sharecareinspire.com</AllowedOrigins> <AllowedMethods>PUT,GET</AllowedMethods> <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders> <ExposedHeaders>x-ms-meta-*</ExposedHeaders> <MaxAgeInSeconds>120</MaxAgeInSeconds> </CorsRule> </Cors>
Let’s understand what each element of this rule indicates.
AllowedOrigins: The origin domains that are permitted to make a request against the service via CORS
AllowedMethods: The HTTP methods the origin domain may use for a CORS request.
AllowedHeaders: The request headers that the origin domain may specify on the CORS request.
ExposedHeaders: The response headers that may be sent in the response to the CORS request.
MaxAgeInSeconds: The maximum amount time that a browser should cache the preflight OPTIONS request.
How does Preflight Request work
The preflight request queries the CORS rules set on the service which your web page want to consume. The web browser sends an OPTIONS request with request headers, method and origin domain. Once call reached to the service, it evaluates the intended operation based on CORS rules that specify which origin domains, request methods, and request headers are allowed to make calls.
If CORS is enabled for the service and there is a CORS rule that matches the preflight request, the service responds with status code 200 (OK), and includes the required Access-Control headers in the response.
If CORS is not enabled for on the service or no CORS rule matches the request, the service will respond with status code 403 (Forbidden).
If the OPTIONS request doesn’t contain the required headers like Origin and Request Method, the service will respond with status code 400 (Bad request).
How does Actual Request work
Once the preflight request is accepted and the response is returned, the browser will dispatch the actual request against the resource. The browser will deny the actual request immediately if the preflight request is rejected.
The actual request is treated as normal request against the service, the only difference between normal request and CORS request is headers, Origin header indicates that the request is a CORS request and the service will check the matching CORS rules. If a match is found, the Access-Control headers are added to the response and sent back to the client. If a match is not found, the CORS Access-Control headers are not returned.
Health and Parenting Inspiring Stories Technology Microsoft Azure SharePoint O365