CODEWITHSUNDEEP
asp.net-coreasp.net-core-webapi
Ben Thomson
Ben Thomson

Reputation: 1143

CORS not working after upgrading to aspnetcore 2.0

I've got an aspnetcore web api that was being called by an angularjs app which was working fine locally. I had CORS enabled as this was the only way I could get the client to work with the API for now (which seemed to make sense and I needed to worry about other things for now).

After upgrading to aspnetcore 2.0 today (because it has a couple of features I could really use) I now just get the same error that I used to get before enabling CORS:

No 'Access-Control-Allow-Origin' header is present on the requested resource.

I have upgraded all dotnetcore packages to version 2.0 (including Microsoft.AspNetCore.Cors).

It might be worth noting that I have not made any changes to my startup or configuration code which is as follows:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();
    app.UseCors(builder => builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader());        
    app.UseMvc();
}

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<Models.SmtpConfig>(Configuration.GetSection("Smtp"));
    services.AddCors();
    services.AddMvc();
}

As stated before this all worked fine with aspnetcore 1.1 and FYI I plan on restricting CORS in production so it only accepts calls from a given sub domain but that's a way off at the moment.

Upvotes: 2

Views: 1596

Answers (1)

Ben Thomson
Ben Thomson

Reputation: 1143

I'm not sure if answering this is the right thing to do here but I'll state what the issue was (basically my own foolishness)...

Thanks to the comment from Poke on my original question I started digging a little deeper and adding more breakpoints (something I should have done first off) and found that it was actually an issue in the code (I'd removed one line of code that was injecting a command and it's handler during startup) so there was a runtime error in the DI code and a side effect of that was that the headers weren't being set on the response.

Not sure why the debugger didn't throw the error as it used to before so the lesson for me is if I see a CORS error in the browser triple check that it's not a 500 server error first.

Upvotes: 3

Related Questions