I have a small Web API app up on a web server, with one GET method that returns 3 records, and a POST method that accepts an object and then assigns it an ID and returns the same object.
I'm making ajax calls from a local web app, and testing out my CORS implementation. Almost everything so far, is working well. If I don't specify an Access-Control-Allow-Origin (just set to *
for now), my calls are disallowed (what I expect), but I also tried specifying Access-Control-Allow-Methods and it doesn't seem like my input restricts specific calls from being made.
For example, this is what my web.config contains:
<httpProtocol>
<customHeaders>
<clear />
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type, Authorization, Accept, X-Requested-With " />
<add name="Access-Control-Allow-Methods" value="OPTIONS, GET" />
</customHeaders>
</httpProtocol>
I only have OPTIONS
and GET
listed, but I am still able to make POST requests. Likewise, if I set it it "OPTIONS, POST"
I am still able to make GET requests.
EDIT
Based on the answer from @geekonaut below I was able to see this function as I'd expect. I attempted to try a PUT
request, rather than GET
or POST
, but then I got an error that the OPTIONS
(preflight) request wasn't allowed. I first needed to add a section in my Global.asax.cs
file to accept that method, then if I toggled adding/removing PUT
in my web.config's Access-Control-Allow-Methods
value, I saw that it would only allow that method if it was listed.
protected void Application_OnBeginRequest()
{
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
HttpContext.Current.Response.StatusCode = 200;
HttpContext.Current.Response.End();
}
}
The Access-Control-Allow-Methods response header specifies one or more methods allowed when accessing a resource in response to a preflight request.
Use a reverse proxy server or WSGI server(such as Nginx or Apache) to proxy requests to your resource and handle the OPTIONS method in the proxy. Add support for handling the OPTIONS method in the resource's code.
Cross-Origin Resource Sharing (CORS) errors occur when a server doesn't return the HTTP headers required by the CORS standard. To resolve a CORS error from an API Gateway REST API or HTTP API, you must reconfigure the API to meet the CORS standard.
CORS does not prevent a simple (or even preflighted) POST
request based on its method.
The Access-Control-Allow-Methods
will only be effective for requests that could not have been made with a simple cross-origin form, for instance.
That means: GET
and POST
can skip the Access-Control-Allow-Methods
as described in the spec:
Simple cross-origin requests generated outside this specification (such as cross-origin form submissions using GET or POST or cross-origin GET requests resulting from script elements) typically include user credentials, so resources conforming to this specification must always be prepared to expect simple cross-origin requests with credentials.
Because of this, resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery (CSRF) by requiring the inclusion of an unguessable token in the explicitly provided content of the request.
(emphasis mine)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With