33

私は立ち往生しています。 真剣に... -解決しました。読む ：）

シナリオ: ここで正しいことをしようとしています。Thinktecture Identitymodel CORS DelegatingHandler に依存する CORS 機能を REST サービス (ASP.NET Web-API) に追加しました。ここまでは順調ですね。

実際に機能しているかどうかをテストするために、次のことを行いました。

  1. シンプルな HTML ページをセットアップし、残りのサービスとは別のホスト ( xttp://otherhost/simplewebpage ) で公開しました。このページでは、JQuery を使用してサンプル リクエストを作成します。コードは以下を参照してください。
  2. 次に、iis Express を使用せず、開発マシン ( xttp://developmenthost/restservice ) で実行されている完全なインスタンスを使用するようにレスト サービスをセットアップしました。
  3. 最後になりましたが、開発マシンで xttp://otherhost/simplewebpage を開き、Ajax リクエストを起動します。エラー コールバックが実行され、Chrome で「トランスポート エラー」（IE9）または「」（空の文字列）が発生したことが通知されます。プロキシ関連の接続の問題などがないことを確認しました。

そこで、Fiddler のトレースと IIS のログを調べました。Fiddler は、GET /rest/hello リクエストではなく、OPTIONS /rest/hello リクエストがあると言っています。これはまったく問題なく、期待どおりです。しかし、OPTIONS リクエストへの応答は興味深いものです。

応答ヘッダー全体は次のようになります。

HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Server: Microsoft-IIS/7.5
Public: OPTIONS, TRACE, GET, HEAD, POST
Date: Fri, 15 Feb 2013 14:09:27 GMT
Content-Length: 0

もちろん、これは予想される応答にはほど遠いものです。これについての楽しい部分は、アプリケーションで Request が Application_BeginRequest() にさえヒットしなかったことです。したがって、私のアプリケーションがその結果に責任を持つことはできません。IIS ログで要求を確認でき、IIS が Powered-by-ASP.NET ヘッダーを追加するので、(正しい) IIS サイトを確実に通過します。

ajax リクエストをトリガーする JQuery コード: 

    function Run()
    {
        $.ajax({
            type: 'GET',
            url: url,
            dataType: "json",
            beforeSend: function(jqXhr) {
                jqXhr.setRequestHeader("Authorization", "Basic " + getBasicHttpEncodedString(userName, password));
                jqXhr.setRequestHeader("Api-Key", "123");
            },
            success: successCallback,
            error: errorCallback,
            timeout: 180*1000
        });
    }

結果の OPTIONS リクエストは次のようになります。

OPTIONS http://services.dev13/Rest/Hello HTTP/1.1
Host: developmenthost
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://otherhost/simplewebpage
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
Access-Control-Request-Headers: accept, origin, api-key, authorization
Accept: */*
DNT: 1
Referer: http://otherhost/simplewebpage
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

...そして、あなたはすでにそれに対する応答を見てきました。

私の OPTIONS リクエストに正確に答える人はいますか? または、私の JQuery コードに欠陥がありますか? たとえば、Postman (Google Chrome アプリ) を使用する場合、または Fiddler でリクエストを偽造する場合 (おそらく、CORS ネゴシエーションを行わないため、OPTIONS リクエストがないため)、REST サービスは正常に機能します。

更新 #1:今日、WebDAV の無効化は OPTIONS リクエストに干渉するため必須であるとどこかで読みました。私の IIS Role Services ビューは、WebDAV Publishing is Not installedと表示します。

* 更新 #2:*問題は解決しましたか?? さらに掘り下げました。OPTIONS 要求に対する「望ましくない (?)」応答を担当する IIS に登録されたモジュールがあります。その名前は「OPTIONSVerbHandler」（ハンドラ：ProtocolSupportModule）です。そのモジュールを無効にすると、リクエストはアプリケーションに渡されます。より意味のある応答が作成され、その後に実際の G​​ET 要求が続きます。 わーい！

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: http://otherhost/simplewebpage
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept,origin,api-key,authorization
X-AspNet-Version: 4.0.30319
Date: Fri, 15 Feb 2013 15:09:25 GMT
Content-Length: 0

もちろん、問題がどこにあるかがわかれば、web.configがそのように見えることを確認するように指示する多くのリソースを見つけることができます:-/

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="false">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="OPTIONSVerbHandler" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>

ただし、IE9 ではまだ機能しません (「エラー: トランスポートがありません」)。誰かが私と同じ道をたどった場合->それはIE9のものです: https://stackoverflow.com/a/10232313/1407618

4

3 に答える 3

1

あなたの答えはここにあります: https://gist.github.com/mathieucarbou/1114981

基本的に、IE には、cor に関するいくつかのかなり具体的な注意事項と落とし穴があります。私は一度自分で書き始めましたが、その後 mathieucarbou の解決策を見つけ、彼の方が優れていると判断しました。

これはあなたが望んでいたよりも少し重いソリューションかもしれませんが、クロスブラウザのサポートのために、「カスタムソリューション」で IE を思いっきり叩いても問題ないことがわかりました。

于 2013-10-09T14:18:55.853 に答える
0

このset-access-control-allow-origin-in-web-apiを確認してください。これが役立つ場合があります。

于 2014-12-22T09:13:42.430 に答える