AngularJS：$ http.postリクエストの前にプリフライトを呼び出すオプション

Question

私はAngularJS v1.2.4を使用しています。

私は角度がプリフライトOPTIONSは（クロームOPTIONSは、「キャンセル」と呼んで見せていた）を呼び出し、送信の問題を持っていたし、それを解決：

すべての私の$リソース・コールのために働い

$httpProvider.defaults.useXDomain = true; 
delete $httpProvider.defaults.headers.common['X-Requested-With']; 

、およびすべてのものよかった。

私は認証を実装しようとしています。ユーザーの資格情報を使用してサーバーにPOST要求を送信するログインページを試しています。私は前に直面していた問題を見ていますが、$リソースコールはまだ正常に動作しています。

本当に不快なことは、問題が断続的に発生することです。ヘッダーを囲むいくつかのオプションを変更してから、ちょっとした作業をして、コードを変更せずにもう一度作業をやめてください。

私のサーバーはCORS用に構成されており、curlや他のRESTクライアントで正常に動作します。ここでは例です：

var authRequest = $http.post('https://' + $location.host() + ':3001/authenticate', {email: email, password: password}); 

を私のアプリの作品からの呼び出しが、これはOPTIONS要求がどのように見えるかのとき：

curl -X OPTIONS -ik 'https://localhost:3001/authenticate' -H "Origin: https://localhost:8001" 
HTTP/1.1 200 OK 
content-type: application/json; charset=utf-8 
content-length: 2 
cache-control: no-cache 
access-control-allow-origin: * 
access-control-max-age: 86400 
access-control-allow-methods: GET, HEAD, POST, PUT, DELETE, OPTIONS 
access-control-allow-headers: Authorization, Content-Type, If-None-Match, Access-Control-Allow-Headers, Content-Type 
access-control-expose-headers: WWW-Authenticate, Server-Authorization 
set-cookie: session=Fe26.2**94705d49717d1273197ae86ce6661775627d7c6066547b757118c90c056e393b*2KYqhATojPoQhpB2OwhDwg*W9GsJjK-F-UPqIIHTBHHZx1RXipo0zvr97_LtTLMscRkKqLqr8H6WiGd2kczVwL5M25FBlB1su0JZllq2QB-9w**5510263d744a9d5dc879a89b314f6379d17a39610d70017d60acef01fa63ec10*pkC9zEOJTY_skGhb4corYRGkUNGJUr8m5O1US2YhaRE; Secure; Path=/ 
Date: Wed, 18 Dec 2013 23:35:56 GMT 
Connection: keep-alive 

はここで$ http.postを呼びました

動作しない場合は、OPTIONSリクエストです。

ヘッダー属性が完全に不足しているようです。誰も似たような問題に遭遇しましたか？

編集：それは動作しない場合

だけで、明確にする、要求がサーバーにそれを作ることはありません - それはすぐにブラウザで中止されています。 Firebugので

、リクエストヘッダは次のとおりです。

OPTIONS /authenticate HTTP/1.1 
Host: localhost:3001 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.91,en-GB;q=0.82,fr-FR;q=0.73,fr;q=0.64,utf-8;q=0.55,utf;q=0.45,de-DE;q=0.36,de;q=0.27,en-sg;q=0.18,en-ca;q=0.09 
Accept-Encoding: gzip, deflate 
Origin: https://localhost:8001 
Access-Control-Request-Method: POST 
Access-Control-Request-Headers: content-type 
Proxy-Authorization: Basic cGF0cmljZUB6b25nLmNvbTpjaGFuZ2VtZQ== 
Connection: keep-alive 
Pragma: no-cache 
Cache-Control: no-cache 

更新：

私はおそらくサーバーに問題のを排除してきた、私は思いますホストを存在しないサーバーに変更します。それでも同じ動作が見られます。

はここにいくつかのコードです：

App.services.factory('AuthService', function ($http, $location, $q) { 

    var currentUser; 

    return { 
     authenticate: function (email, password) { 

      //promise to return 
      var deferred = $q.defer(); 

      var authRequest = $http.post('https://this.does.not.exist.com:3001/authenticate', {email: email, password: password}); 

      authRequest.success(function (data, status, header, config) { 
       currentUser = data; 
       console.log('currentUser in service set to:'); 
       console.log(currentUser); 
       //resolve promise 
       deferred.resolve(); 
      }); 

      authRequest.error(function (data, status, header, config) { 
       console.log('authentication error'); 
       console.log(status); 
       console.log(data); 
       console.log(header); 
       console.log(config); 

       //reject promise 
       deferred.reject('authentication failed..'); 
      }); 

      return deferred.promise; 
     }, 
     isAuthenticated: function() { 
      return currentUser !== undefined; 
     } 
    }; 
}); 

とHTTP設定：それはあなたがあなたのローカルホスト上httpsエンドポイントをヒットしているという事実に関連するかもしれないようにこれが感じる

App.config(['$httpProvider', function ($httpProvider) { 

    $httpProvider.defaults.useXDomain = true; 
    //$httpProvider.defaults.headers.common = {}; 

    console.log('logging out headers'); 
    console.log($httpProvider.defaults); 
    console.log($httpProvider.defaults.headers.common); 
    console.log($httpProvider.defaults.headers.post); 
    console.log($httpProvider.defaults.headers.put); 
    console.log($httpProvider.defaults.headers.patch); 
    console.log('end logging out headers'); 

    $httpProvider.defaults.headers.common = {Accept: "application/json, text/plain, */*"}; 
    $httpProvider.defaults.headers.post = {"Content-Type": "application/json;charset=utf-8"}; 

    console.log('after: logging out headers'); 
    console.log($httpProvider.defaults.headers.common); 
    console.log($httpProvider.defaults.headers.post); 
    console.log($httpProvider.defaults.headers.put); 
    console.log($httpProvider.defaults.headers.patch); 
    console.log('after: end logging out headers'); 

    $httpProvider.interceptors.push(function ($location, $injector) { 
     return { 
      'request': function (config) { 

       console.log('in request interceptor!'); 

       var path = $location.path(); 
       console.log('request: ' + path); 

       //injected manually to get around circular dependency problem. 
       var AuthService = $injector.get('AuthService'); 
       console.log(AuthService); 
       console.log(config); 

       if (!AuthService.isAuthenticated() && $location.path() != '/login') { 
        console.log('user is not logged in.'); 
        $location.path('/login'); 
       } 

       //add headers 
       console.log(config.headers); 
       return config; 
      } 
     }; 
    }); 
}]); 

Answer 1

。つまり、何らかの自己署名SSL証明書を使用している可能性があります。これは、Chromeが信頼できないと判断する可能性があります。

私はまず/ authenticateエンドポイントに行き、Chromeから信頼されていない証明書についての警告が表示されるかどうかを確認します。その警告を受け入れるかどうかを確認してください。

ローカルでテストしている間に、おそらくhttpエンドポイントにヒットして問題を解決できるかどうかを確認できますか？

Answer 2

マイケル・コックスfor pointing me in the right directionに大変感謝します。それは解決策に私を導いたので、私は彼の答えを受け入れるが、ここでは詳細は以下のとおりです。

は、httpsの問題を見ると、私が見つかりました：

• Why Chrome cancel CORS OPTION request
• https://code.google.com/p/chromium/issues/detail?id=141839

を私の問題しかし少し異なっていた。私は上記のリンクの指示に従った後もまだ動作していませんでした。私はクロム「信頼できない」メッセージを注意深く読んだ。それは「あなたはmylocalhost.comにアクセスしようとしているが、サーバはそれ自体を代表している」のようなものだった。

それが「mylocalhost.crt」

Answer 3

あるべきときには、一緒にAccess-Control-Allow-Origin: *とallow-credentialsを持つことができません「をserver.crt」だった私の急いで作成した自己署名証明書ことが判明しました。

重要な注意：資格のあるリクエストに応答する場合、サーバーはドメインを指定する必要があり、ワイルドカードを使用することはできません。

GETリクエストに関して、特別なヘッダーがない場合、プリフライトなどは必要ありません。

出典：Mozilla Developer Network。 （ウェブ上のベストCORSリンク）