We Keep Coding

HTTP PATCH no 'Access-Control-Allow-Origin' header in ASP.NET Core 6

I have reviewed the information on Enable Cross-Origin Requests .NET 6 to no avail.
This only affects the HttpPatch. When I run it in Swagger, no problems. When I try to test through 3rd party tool or CORS Test tool, I get errors.
The policy used dedicated for the CORS Test webapp already mentioned. Here is the code:
builder.Services.AddCors(options =>
{
options.AddPolicy(name: "MyAllowAllHeadersPolicy",
policy =>
{
policy.WithOrigins("https://cors-test.codehappy.dev")
.AllowAnyHeader()
.AllowAnyMethod();
});
});
When I run a test, I get this error message each time: It does not have the access-control-allow-origin header set to *. Without this header, requests from other domains cannot be made to it via a users browser.
All my other routes are OK, as I have enabled them on the Caddy Server globally using the following JSON snippet:
header {
# enable HSTS
Strict-Transport-Security max-age=31536000;
# disable clients from sniffing the media type
X-Content-Type-Options nosniff
# clickjacking protection
X-Frame-Options DENY
# keep referrer data off of HTTP connections
Referrer-Policy no-referrer-when-downgrade
# Content-Security-Policy: default-src 'self'
Access-Control-Allow-Origin *
Access-Control-Allow-Credentials true
Access-Control-Allow-Methods *
Access-Control-Allow-Headers *
}
On the particular route in the Controller that uses PATCH (there is only 1 controller using PATCH for 1 item), I have this code too (abbreviated to show the annotations):
[EnableCors("MyAllowAllHeadersPolicy")]
[HttpPatch("{id:int}")]
public async Task<IActionResult> PatchAsync(int id, ...
The long error message in the Console from the browser is:
Access to XMLHttpRequest at 'https://web.site' from origin 'http://localhost:4200'
has been blocked by CORS policy: Response to preflight request doesn't pass access
control check: It does hot have HTTP ok status.
I don't want to post the entire URI, as this exposes my API and there are no Authorisations setup whilst it is undergoing development mode, so the URL's are just for example purposes.
Ideally I want to handle the preflight request on the server side, in the WebApi project, so it returns a HTTP status code of 200 so that the browser will continue with sending the actual request.
I have read through quite a few documents and tried different policies, setting it to allow all, but to no avail.
Is there someone that might be able to point me in the right direction to resolve this?
My alternative, was to take a copy of the object, and re-publish it back to the API as a PUT command over the top of the object. This worked before but was a big overhead to handle the request. :-(
To enable the HTTP PATCH I referenced this Microsoft article: aspnet Core 6 JsonPatch

I created a .net 6 MVC app, and in my controller, I followed the document you mentioned and added a request like this:
[HttpPatch]
public IActionResult JsonPatchWithModelState([FromBody] JsonPatchDocument<Customer> patchDoc)
{
if (patchDoc != null)
{
var customer = new Customer {
customerName = "a"
};
patchDoc.ApplyTo(customer, ModelState);
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
return new ObjectResult(customer);
}
else
{
return BadRequest(ModelState);
}
}
Then in the Program.cs, adding cors policy:
builder.Services.AddControllersWithViews().AddNewtonsoftJson();
builder.Services.AddCors(options =>
{
options.AddPolicy(name: "MyAllowAllHeadersPolicy",
policy =>
{
//policy.WithOrigins("https://cors-test.codehappy.dev")
policy.AllowAnyOrigin()
.AllowAnyHeader()
.AllowAnyMethod();
});
});
...
..
.
app.UseRouting();
app.UseCors("MyAllowAllHeadersPolicy");
And now test in the tool you mentioned :
But when I create a SPA to test the api
$("#btn2").click(function() {
alert(2);
$.ajax({
headers : {
'Accept' : 'application/json',
'Content-Type' : 'application/json'
},
url : 'https://localhost:7151/home/JsonPatchWithModelState',
type : 'PATCH',
data : JSON.stringify({customerName: "xxxx"}),
success : function(data) {
alert("OK");
},
error : function(data) {
alert("error");
}
});
});
It can access the api.

Unexpected behavior with CORS on .NET Core

I have added the following to my service configuration.
services.AddCors(options
=> options.AddDefaultPolicy(builder
=> builder
//.AllowAnyHeader()
.WithHeaders("header-that-nobody-knows")
.WithOrigins("http://localhost:44304")));
My expectation was that the calls would bounce (as I don't add header-that-nobody-knows to my headers). However, the request is carried out just as if AllowAnyHeader() was set.
Manipulating the port, domain or protocol in WithOrigins() produces the expected result, so the config seems to be wired up properly. I suspect it's a special case somehow because I'm getting unexpected behavior with WithMetod() when it comes to GET and POST (while other methods are blocked/allowed depending on the paramers passed).
Checking MSDN gave nothing I recon as explanation.
I doubt that it matters but for completeness sake, here's the Angular code invoking the call.
let url = "https://localhost:44301/security/corstest?input=blobb";
this.http.get<any>(url).subscribe(
next => console.log("next", next),
err => console.warn("err", err));
The action method looks as below.
[HttpGet("corstest")]
public IActionResult CorsTest([FromQuery] string input)
{
return Ok(new { data = input + " indeed..." });
}

When you try to send a request to a cross-origin URL with a "non-standard" header,
the browser will perform a preflight OPTIONS request with the Access-Control-Request-Headers header that contains the non-standard headers.
OPTIONS /corstest
Access-Control-Request-Method: GET
Access-Control-Request-Headers: header-that-nobody-knows
Origin: https://my.api
ASP.NET Core inspects this value and checks if the CORS policy has AllowAnyHeader or if it explicitly allows it with .WithHeaders, if not it will issue a non-200 response and the browser will refuse to send the actual request.
So, not adding header-that-nobody-knows to request headers doesn't mean ASP.NET Core will refuse to serve the request, it means if you set header-that-nobody-knows header in a cross-origin request, it will allow it instead of issuing a non-200 response (assuming you allowed it with WithHeaders or AllowAllHeaders)
So in a nutshell:
You have to allow some/all origins + some/all headers at minimum for a CORS policy to take effect.
Browser expects both Access-Control-Allow-Headers and Access-Control-Allow-Origin in the preflight request to match the main request.
You can only send a subset (which includes 0) of the allowed headers.
References
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests

OPTIONS preflight not handled in jQuery

I have a webpage at localhost:63342 with a jQuery ajax call in that webpage, to my webservice server at localhost:55000. In the webservice I set the Access-Control headers.
In Chrome's developer tools, Network tab, I can see that the OPTIONS preflight thing is sent, and the response header has the following, which looks great.
Access-Control-Allow-Headers:x-requested-with, X-Auth-Token, Content-Type, Accept, Authorization
Access-Control-Allow-Methods:POST, OPTIONS, GET
Access-Control-Allow-Origin:*
Cache-Control:private
Content-Length:0
Date:Fri, 06 Jun 2014 13:30:58 GMT
Server:Microsoft-IIS/8.0
However, the response to the OPTIONS request hits the error function of my jQuery ajax call. Developer tools shows me that the browser prepares the POST, but fails it because it thinks the resource does not have the Access-Control-Allow-Origin header set. The browser does not try to send the POST. Here is the error message from the console of the browser:
XMLHttpRequest cannot load http://localhost:55000/webservice/ws.svc/CreateOuting. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access.
Its as though jQuery is interfering in the OPTIONS, POST process. Any ideas on what I should do to make this work?
Here is my ajax call
$.ajax({
type: 'POST',
data: JSON.stringify(obj),
headers: { "Content-type": "application/json" },
url: base_url + 'CreateOuting',
crossDomain: true,
success: function (an_outing) {
$('#listviewOutings').listview('refresh', true);
$('#boxOutingName')[0].value = '';
myLib.OpenBasicPopup('Success', 'The outing name was saved.')
},
error: function (err) {
alert(err.statusText); // response to OPTIONS request ends up here
}
});
Here is how I set the headers in the method on the server (.NET C#):
public bh_Outing CreateOuting(string strOuting) {
try
{
//for all cors requests
WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
//identify preflight request and add extra headers
if (WebOperationContext.Current.IncomingRequest.Method == "OPTIONS")
{
WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "POST, OPTIONS, GET");
WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Headers", "x-requested-with, X-Auth-Token, Content-Type, Accept, Authorization");
return null;
}
// do stuff
Here is the interface for that method. I dont think its perfect yet, but I dont think its the problem either.
[WebInvoke(UriTemplate = "*", Method = "*", ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
bh_Outing CreateOuting(string strOuting);
Thanks for taking a look at this. I am truly stuck.
Update, 6/17/14, 5:38 PM EST
I added a element to my webconfig as in this post, and this made no change to my results.

This may be not the reason, but have you tried enabling cors in jQuery? Before any cors ajax request:
jQuery.support.cors = true;

The cause of the problem that made me post the above question, seems to be that Chrome was incorrectly representing what was really happening. As I wrote above, what was happening was:
... the response to the OPTIONS request hits the error function of my
jQuery ajax call. Developer tools shows me that the browser prepares
the POST, but fails it because it thinks the resource does not have
the Access-Control-Allow-Origin header set. The browser does not try
to send the POST.
To try to get more detail, I installed and used Microsoft Message Analyzer. It showed that the OPTIONS request was being sent; the OPTIONS response was being sent; the POST request was being sent back to the webservice (!!!) and a POST response was being sent.
This was a huge breakthrough because now, instead of trying to solve a CORS problem (the error message that Chrome developer tools showed) I started working to solve a "Not Found" and then a "Bad Request" error (the error messages that MS Message Analyzer showed).
The other technique I used that helped a lot was that I set up tracing in my webservice. Tracing wrote stuff to a log file which default-opens in an event viewer and provided the details that I needed to figure out the (real) issues. Here is what I put in the webconfig to enable tracing.
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Critical, Error, Warning"
propagateActivity="true">
<listeners>
<add name="myListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\logs\ServiceModelExceptions.svcLog" />
</listeners>
</source>
</sources>
</system.diagnostics>
I made no changes to the CORS settings (jQuery and web.config) and its running fine in Chrome now. Also, I have the webservice out on the www, so it is truly cross-domain, not just localhost:63342 to localhost:55000.

Cannot load web api method using Backbone.js

I have a blank asp.net solution with 5 different projects. One of them is asp.net web api and other one is blank web site with bunch of html pages. I am using backbone.js/jQuery to make calls to the web api within the solution. My blank web site is running on different port and my web api is running on different port.
//Collection
var AuditsCollection = Backbone.Collection.extend({
url: 'http://localhost:56501/api/searchaudits',
sync: function (method, model, options) {
if (!options.crossDomain) {
options.crossDomain = true;
}
options.timeout = 1000;
alert(method + ": " + JSON.stringify(model));
return Backbone.sync(method, model, options);
},
});
var audits = new AuditsCollection();
// Model
var Audit = Backbone.Model.extend({ });
var audit = new Audit({ auditNumber: "A12" });
audits.add(audit);
// POST CALL - I am sending this model and expecting back another JSON object in response.
audit.save({}, {
success: function (response) {
alert("Got audits successfully" + response);
},
error: function (response) {
alert("Error.. Go home now");
}
});
I still get this error
XMLHttpRequest cannot load http://mydomain:56501/api/searchaudits. Request header field Content-Type is not allowed by Access-Control-Allow-Headers.

I think I figured out what the issue is. The project is setup in the following structure.
Error:
-- Solution
-- Project 1 (Web API) - running on `http://localhost:80/api`
-- Project 2
-- Project 3
-- Project 4 (Views) - running on `http://localhost:3000/`
So when I started making ajax requests, it started giving exceptions like
XMLHttpRequest cannot load http://localhost:80/api/searchaudits. Request header field Content-Type is not allowed by Access-Control-Allow-Headers.
OPTIONS localhost:80/api/searchaudits 405 (Method Not Allowed)
XMLHttpRequest cannot load /api/searchaudits
I did not know that it is going to consider domains with different ports ad different domains.
Solution:
Override Backbone.Sync method - reference
In your Web Api projects web.config file, add the following
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type, Accept"/>
</customHeaders>
</httpProtocol>
</system.webServer>
There are answers in StackOverflow regarding this issue in bits and pieces, but this is an effort to put the complete solution together in one place.

CORS Support within WCF REST Services

I have a WCF REST service hosted within a Windows service and I would like to send the Access-Control-Allow-Origin HTTP header (defined as part of CORS) with every response.
My attempted solution was to have something like the following within an IDispatchMessageInspector implementation:
public void BeforeSendReply(ref Message reply, object correlationState)
{
var httpResponse = reply.Properties["httpResponse"] as HttpResponseMessageProperty;
if (httpResponse != null)
{
// test of CORS
httpResponse.Headers["Access-Control-Allow-Origin"] = "*";
}
}
Normally this would work, but unfortunately my service also uses HTTP basic authorization, which means that when a request comes in without the Authorization header, WCF automatically sends a 401 response asking for credentials. Unfortunately WCF does not call my IDispatchMessageInspector during this initial exchange, so Access-Control-Allow-Origin header is not added to the initial exchange.
The problem occurs when I try to call the service from a browser. CORS specifies that cross-origin requests should only be allowed if the origin domain matches the domain listed in the Access-Control-Allow-Origin response header (* matches all domains). Unfortunately when the browser sees the initial 401 response without the Access-Control-Allow-Origin header, it prevents access (according to the same origin policy).
Is there any way add a header to the initial 401 response sent automatically by WCF?

This guy saved my day.
http://blogs.microsoft.co.il/blogs/idof/archive/2011/07.aspx
I am going to place some of his notes here, just in case that web page dies some day.
(I hate finding "Your answer is right HERE" links, and then the link is dead.)
<behaviors>
<endpointBehaviors>
<behavior name="webSupport">
<webHttp />
<CorsSupport />
</behavior>
</endpointBehaviors>
</behaviors>
<extensions>
<behaviorExtensions>
<add name="CorsSupport" type="WebHttpCors.CorsSupportBehaviorElement, WebHttpCors, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>
</extensions>
<services>
<service name="Service.JSonService">
<endpoint address="http://localhost:8080" behaviorConfiguration="webSupport” binding="webHttpBinding" contract="Service.IJSonService" />
</service>
</services>
Now, you have to find his downloadable library called "WebHttpCors.dll".
But there is enough there (above) to help you google/bing your way to a resolution.
The part that was throwing me for a loop (in my scenario) is that IE was working, but Firefox was not working.
My originating page was:
http://localhost:53692/test/WCFCallTestViaJQ14.htm
So my service is at:
http://localhost:8002/MyWCFService/MyWCFMethodByWebGet?state=NC&city=Raleigh
So I had localhost <<-->> localhost traffic.
**** But the ports were different. (53692 and 8002) ****
IE was ok with it. Firefox was not ok with it.
Then you gotta remember that each browser handles their .Send() requests differently (inside JQUERY that is).
It all makes sense now.
//JavaScript snipplet from JQuery library
if (window.XMLHttpRequest) {
returnObject = new XMLHttpRequest();
} else if (window.ActiveXObject) {
returnObject = new ActiveXObject("Microsoft.XMLHTTP");
} else {
msg = "Your browser doesn't support AJAX!";
}
Here are some key words, phrases that I've been googling/binging that finally led me somewhere.
Result: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.statusText]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://localhost:53692/test/WCFCallTestViaJQ14.htm :: HandleJQueryError :: line 326" data: no]
XMLHttpRequest Send "NS_ERROR_FAILURE"
JQuery Ajax WCF Self Hosted CORS JSON
NOW, YOU NEED TO READ HIS BLOG BLOGS TO UNDERSTAND WHAT THE CODE IS DOING:
For example, he says:
“Access-Control-Allow-Origin” header with the value of “*”
This may or may not be what you want. You may want to have better control of this value (headers) and the others (methods and the origins).
Development environment is one thing. (Use all the *'s you want).
Production is something else, you may want to tweak down those * values to something more discriminate. In a nutshell, you need to understand what CORS is actually doing for you in terms of security, and not just add a behavior that lets everything in.
allowed-origins: '*'
allowed-headers: '*'
allowed-methods: '*'

To achieve what you want you need to handle the authorization yourself which is possible by impelementing + registering a HttpModule... there you would issue the 401 and along with it any http header you want... there is even a sample implementation here on SO - see Adding basic HTTP auth to a WCF REST service
EDIT - after comment from OP:
Since the OP's comment says that he is self-hosting the solution is not with HTTPModule but actually with IDispatchMessageInspector.BeforeSendReply and with IDispatchMessageInspector.AfterReceiveRequest.
The Authorization must be configured to "None" and custom implemented/handled in IDispatchMessageInspector - this way you can add any header when issuing a 401 . Otherwise the runtime handling Basic Auth wouldn't call your IDispatchMessageInspector before proper/positive Auth.
Although this works BEWARE that this means you implement security-sensitiv code yourself and thus need to take appriopriate measure to ensure its proper implementation...

Adding the following line to the first method that gets called in the WCF Service worked for me.
WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
Requires the following import
System.ServiceModel.Web;
Refer this for original answer

I tried many ways but could not find anything and then suddenly in the end I came to know that headers should be sent through OPTIONS request only and then I found some helpful SO code here!
This one resolves my problem completely.
Actually the point here is that you have to add headers in OPTIONS request along with just a 200 OK response and thats what is done on this link.