Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
From @iwbo on Wednesday, October 19, 2016 4:22:02 AM
There is a similar closed issue that I have commented on, but there hasn't been any response, so I created a new issue.
Has this issue been revisited?
But the main problem for me is that if I allow some domain do make CORS requests, I expect them to get all the information.
If the request was made with "XMLHttpRequest" as fallows:
If the response is indeed 500 but without CORS headers, then the "XMLHttpRequest" status will be 0, not 500.
So what's your ideas on this? Or am I missing something?
Copied from original issue: aspnet/CORS#90
From @Eilon on Wednesday, November 23, 2016 2:40:30 PM
I think the issue here is that this is not likely to be safe to do in general in the CORS middleware, which is why we recommend customizing the behavior for your app. That is, it is not generally safe to send all error details to a remote caller. So, instead of letting the generic ASP.NET Core error handling mechanism propagate the error to the client, we recommend writing error handling code that effectively handles the error safely, and returns the appropriate message/info/data to the caller. That's essentially what is shown here: aspnet/CORS#46 (comment)
From @iwbo on Wednesday, November 23, 2016 3:20:48 PM
So if I need to let the caller know that an Internal Server Error occurred together with CORS middleware.
Also isn't detailed Error information hidden by default in asp.net core ?
From @Eilon on Monday, December 19, 2016 9:15:57 AM
From @iwbo on Thursday, January 5, 2017 2:59:08 AM
Yes, I also think the question is a bit philosophical. And an alternative solutions has already been posted!
But here are some reasons:
From @Eilon on Tuesday, May 16, 2017 5:39:58 PM
Outside of the philosophical side of things, I think the thing being discussed here is that ASP.NET Core's exception-handling middleware (the Developer Exception Page and the Exception Handler) will clear out all the headers so that they can send their response, which includes clearing out CORS headers.
I don't think that the CORS middleware itself cares about status codes; it'll gladly add the CORS headers as necessary.
So, if your code explicitly returns some error status code (400, 404, 500, etc.), I'm guessing that CORS will work just fine. However, if ASP.NET Core is going to render a generic error page, it clears all the headers in order to ensure maximum security (data exposure) and maximum compatibility (header conflicts).
From @PureKrome on Thursday, November 16, 2017 3:03:21 PM
@Eilon I'd like to add some more input (hopefully valid) to this issue.
I have a very standard ASPNet Core 2.0
When a server error occurs I'm expecting the Client App to successfully receive a Response from the server ... even if it's an HTTP-500 response. Right now when I handle custom exceptions
the aspnet core code clears all headers so my client app cannot read the response because the browser rejects the non-cors-complient response. This has been justified as:
It took me ages to figure out this was happening.
There is no obvious documentation about this. Literally, I had to ask in StackOverflow and then by fluke I was given some help because another very kind person actually checked the source code (thank you for OSS, MS!!) and told me what to do :)
So - would you gals/guys consider maybe enhancing the api to include an option to keep the headers etc .. because we the developer can make that call based upon what we intend to do with our custom exception handling.
for example (for one of the methods in the ExceptionHandlerExtensions class) :
I find something like this important because it's actually describing some 'black magic' that would normally occur "under the hood/inside the box" and allow us, the developer, to make a more accurate decision about what we are trying to do with exception handling now.
Now - this is a lot of chat for something that can be considered smallish, so I'll give you guys some context to what we are doing and why we find this important.
So our libraries throw exceptions to handle non-happy-path scenarios and our custom exception handler (called by the exception handling middleware) checks the
Finally, we return our error info in the response body as json so a consuming client can (if they wish) interrogate the json payload to determine what to show on the client. At the very least, check the status code and update the UI accordingly.
if error == 400, display validation errors (info is in the json payload).
(NOTE: this is getting into the "philosophical side of things" so I don't want to debate this, just give some context to what and why we are doing things as such.
The counter to this interesting too. Basically, have a
Note: browser pseduo code, etc...
and called like this..
So yeah - some context, some thoughts, some extra discussion. Not sure if this should be asked in the
thanks for reading this and keep on being awesome :)
From @Jungers42 on Thursday, November 30, 2017 1:15:53 PM
Ugh ... I just spent half a day wrestling with ways to solve this (to aid in our migration from a full framework ASP.NET WebApi project into a new .NET Core API project (.NET Standard 2). After playing lots of games, this was my only reasonable solution to still have the useful dev exception message from the comfort of our actual web app (Chrome dev tools or the like) which is using both OAuth and CORS.
The startup bits look like this:
Notice that CORS is the first middleware in the pipeline (pretty wide open). Next, only for development, we add our own custom middleware MaintainCorsHeader followed by the standard DeveloperExceptionPage.
Here is that custom middleware which does the magic necessary to "bring back" the CORS headers. It could be more restrictive, but it's only holding onto headers we've chosen to add in anyhow so it should be safe.
First thing, it looks for and holds onto any CORS related (starts with "Access-Control-") headers. Then it binds to the OnStarting event of the Response so that it can double check that those headers STILL exist. If not (as is the case with the dev exception middleware responses), then this puts them back in place.
From @PureKrome on Thursday, November 30, 2017 2:57:35 PM
From @Jungers42 on Friday, December 1, 2017 6:03:31 AM
We are just starting to test the deployment of this replace API (and yes, we're consuming it in an Angular 4 SPA primarily ... at least where we are using CORS). My logic tells me that a 4xx/5xx err when NOT in Development will be just fine, CORS headers and all. Remember that the CORS middleware is adding the response headers for CORS into the response very early on (first thing in my startup) ... so unless some other middleware does a Response.Clear() (as the DevelopmentExceptionPage middleware does) or otherwise modifies the headers to remove the CORS headers, then they'll still be there on whatever response is generated. I only wanted to ensure that our pretty exception stack traces would be visible in dev tools when doing development to vastly simplify the debug process.
Im running into this problem as well.
I have a json api where I return responses like this:
The problem is that I can't access this message from my JS client since the Cors headers doesn't get sent to the client because I return status code 500.
I think that this really should be up to me, the developer of the application, to configure if the CORS headers should be sent or not. I don't think the headers should be stripped if a 500 error occurs, especially since the "Internal Error" has been handled already and I just want to return a appropriate status code. One "workaround" now is to set the status code to 400 instead of 500, but that is not acceptable since it's a blatant lie, it wasn't a bad request that occured, it was an internal server error....
I wish this was documented, as it is non standard behavior to hack CORS in order to hide error codes and messages.
I recently stumbled upon this situation in our OData + Angular based application. Our client app implements varying behaviors for different types of errors. Some are displayed to the user, many are sanitized (client-side), others are hidden, but all are logged with the original response message to our Application Insights, which pools all client side errors for easy triage. We even try to interpret network connectivity errors, which are typically reported as code 0, vs other code like 400s or 500s. This is all necessary to give our customers a good user experience.
Unfortunately without CORS for unhandled exceptions, the responses all have 0 status code, and no message. This behavior is something that never would have crossed my mind, since I already knew CORS worked properly in all normal cases for our app.
Sorry but what should I do to get this changes? I have already updated all nugget packages to the last versions (Microsoft.AspNetCore.App to 2.1.2) and .Net Core SDK to 2.1.3, but nevertheless instead of 500 type errors my WebApi project sends CORS type errors to frontend.
You have this 5xx NO CORSE problem or what? Any warning in browser console?
Hi, it looks like you are posting on a closed issue/PR/commit!
We're very likely to lose track of your bug/feedback/question unless you:
I know this might sound painful, but ....
This seems to be the fastest way to get the maintainers to triage and classify the bug. As @pranavkm (maintainer of this stuff) said above, create a new issue + detailed repo.
Again, I know this sounds like more effort on either of you, but short term pain for long term gain.