web-dev-qa-db-ja.com

Web.configとWebApiConfigおよびコントローラー属性を介してCORSを有効にする

Web API 2でクロスオリジンリクエストの共有を有効にするには、機能的に異なる2つの方法があるようです。

1つは、EnableCors属性を使用して_System.Web.Http.Cors_、コントローラーの装飾をインポートし、WebApiConfigにconfig.EnableCors()を書き込むことです。

_[EnableCors(origins: "http://111.111.111.111", headers: "*", methods: "*")]
public class GenericController : ApiController
{
    // etc.
_

もう1つは、Web.configを変更：

_<system.webServer>
     <httpProtocol>
         <customHeaders>
            <add name="Access-Control-Allow-Origin" value="http://111.111.111.111" />
            <add name="Access-Control-Allow-Methods" value="*" />
            <add name="Access-Control-Allow-Headers" value="*" />
_

これら2つの異なるアプローチの間に機能的な違いはありますか？どちらが正しいですか-これらは同じことを達成しませんか？両方の方法を使用してCORSを有効にすると、事態は爆発しますか？

asp.net-web-apiasp.net-web-api2
17
alex

Web.configにヘッダーを追加すると、そのアプリケーションによって処理されるeveryリクエストには、指定されたヘッダーが含まれます。このメソッドはWebサーバーレベルでサポートされ、config.EnableCors()の実行に依存しません。このメソッドを使用して、必要なHTTPヘッダーを追加できます。

反対に、EnableCors属性にはWebAPIが必要であり、それを機能させるためにコードを追加する必要があります。エンドユーザーにとって、結果は同じです。

どちらの方法が良いですか？これらの設定が将来の開発者に明らかであるように、属性を使用してアプリケーションコードにこれらの設定を保持するのが好きです。必要に応じて、メインのApiControllersが継承して同じCORSヘッダーを繰り返し配信できる抽象CorsApiControllerを調べることができます。ただし、CORSヘッダーをコントローラーごとに、またはアクションごとに変更する必要がある場合、このメソッドは機能しません。

11
Steven V