Forward IDisableCorsAttribute to a more broadly-used package

[dougbu]

IDisableCorsAttribute and DisableCorsAttribute are located in the Microsoft.AspNetCore.Cors package. This means external frameworks and extensions must reference those packages just to disable the possibly-conflicting features, even if they are aimed at API controllers. That is, they may need to reference Cors to disable CORS in case their consumers reference that package -- but for no other reason.

Hit this and aspnet/Mvc#7076 while working on the ASP.NET Core WebHooks implementation. No action associated with the WebHookAttribute needs antiforgery checks or CORS support. But, the containing Microsoft.AspNetCore.WebHooks.Receivers package would need to reference the Cors and MVC's ViewFeatures packages to disable both.

One possible landing spot for the interface would be be the Microsoft.AspNetCore.Http.Abstractions package.

[Eilon]

What is the connection between CORS and Web Hooks? Web Hooks are triggered by other servers (e.g. Office 365, GitHub, etc.), whereas CORS is a browser security feature that applies to AJAX requests.

[dougbu]

More the opposite of a connection: It's sensible to disable CORS for WebHook actions.

[Eilon]

My question is when does CORS even apply to this? CORS is used only by browsers, but when is a browser ever calling a web hook?

[dougbu]

If a browser called a web hook, why enable CORS? Except in a the rare case of a receiver that implements "ping" using a simple GET, the request should always fail -- but due to the receiver's normal rules, not because CORS blocks it.

[Eilon]

Browsers never call web hooks, do they?

[dougbu]

Browsers can call almost-any ASP.NET Core endpoint. A WebHooks endpoint is just another URL on the Internet.

[Eilon]

The question isn't whether they can - my thermostat can make web calls too, but I don't know whether it supports CORS 😄 The question is whether it's a scenario that happens in practice, and I can't think of a case where it does.