GET和POST工作时，PUT请求失败，HTTP预检失败（使用Angular 6和Dotnet Core 2.1 Web API）

Question

I'm developing a web application using Angular 6 on the front-end and .NET Core Web API on the back-end.

I'm working on setting up the API to work with my Angular services. My font-end and back-end projects are on different localhost ports, but I've enabled CORS for development purposes in my API as such.

services.AddCors(o => o.AddDefaultPolicy(builder =>
{
    builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();
}));

Using this setup, I can successfully execute a GET request. For example, my Angular service:

getAllFiles():Observable<MediaFile[]> {
  return this.http.get<MediaFile[]>(`${this.request_url}/files`)
}

Can call my Web API Controller:

[HttpGet]
public IEnumerable<MediaFile> GetFiles(string code = null)
{
    if (code != null)
    {
      return context.Files.Where(file => file.Meeting.Code == code);
    }
    return context.Files;
}

And successfully gives me the media files I've requested.

I won't include it here for brevity purposes, but I've done the same thing for POST and it works as expected.

I'm trying to add a handler for PUT requests. Here is the relevant code:

putFile(file:MediaFile):Observable<MediaFile> {
  return this.http.put<MediaFile>(
    `${this.request_url}/files/${file.id}`, file
  )
}

And on the server-side:

[HttpPut("{id}")]
public async Task<IActionResult> PutFile([FromRoute] int id, [FromBody] MediaFile file)
{
   if (!ModelState.IsValid)
   {
      return BadRequest(ModelState);
   }

   if (id != file.Id)
   {
      return BadRequest();
   }

   context.Entry(file).State = EntityState.Modified;

   try
   {
      await context.SaveChangesAsync();
   }
   catch (DbUpdateConcurrencyException)
   {
     if (!FileExists(id))
     {
       return NotFound();
     }
     else
     {
        throw;
      }
    }
    return NoContent();
}

But when I try executing this code, the browser sends an HTTP OPTIONS request. A bit of Googling has told me that this is most likely a preflight request . It then sees that no OPTIONS method exists in my API, and returns a 404.

I don't understand why the preflight request is failing under these circumstances. Why does my API work with GET and POST requests, but not with PUT? Could somebody please shed some light on what could be going wrong here.

Thanks!

Answer 1

I managed to fix this issue by manually catching the preflight request and returning a response:

[HttpOptions("{id}")]
public IActionResult HandleOptions([FromRoute] int id)
{
      Request.HttpContext.Response.Headers.Add("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
      Request.HttpContext.Response.Headers.Add("Access-Control-Allow-Headers", "origin, content-type, accept, x-requested-with");
      Request.HttpContext.Response.Headers.Add("Access-Control-Max-Age", "3600");
      return Ok();
 }

This feels like a bit of hack, but for now it serves my needs. I would still appreciate if someone could shed light on what the real problem could be.

Answer 2

Apparently this is a bug in asp.net core when using Windows Authentication (NTLM) and using cors. When the browser sends the preflight OPTIONS request, it should not require authentication, but the server handles it as if authentication is required, resulting in the 401 error.

I found and modified a solution from here: https://github.com/e5Workflow/CoreWebApp

The solution there was apparently a bit outdated as it did not work in my aspnetcore 2.1 app, but I picked the relevant bits out of the code and made it work.

1. Enable anonymous authentication by editing launchsettings.json

    "windowsAuthentication": true, "anonymousAuthentication": true, 

2. Add the following as your very first middleware in startup.cs :

    app.Use(async (context, next) => { if(context.Request.Method != "OPTIONS" && !context.User.Identity.IsAuthenticated) { context.Response.StatusCode = 401; await context.Response.WriteAsync("Not Authenticated"); } else { await next.Invoke(); } }); 

The idea is that every request except an OPTIONS request will still require authentication, but OPTIONS requests will not, so the proper 200 response and headers will be sent back.