REST APIからデータを取得しようとしたときに、要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しません

HPAlmのRESTAPIからいくつかのデータをフェッチしようとしています。小さなcurlスクリプトでかなりうまく機能します-データを取得します。

JavaScriptでそれを行うようになった今、フェッチとES6（多かれ少なかれ）はより大きな問題のようです。このエラーメッセージが表示され続けます：

FetchAPIを読み込めません。プリフライト要求への応答がアクセス制御チェックに合格しません：要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。起源「http://127.0.0.1:3000」がゆえのアクセスが許可されていません。応答のHTTPステータスコードは501でした。不透明な応答がニーズを満たす場合は、リクエストのモードを「no-cors」に設定して、CORSが無効になっているリソースをフェッチします。

これは、ローカルホスト内からそのデータをフェッチしようとしているためであり、ソリューションはCORSを使用する必要があることを理解しています。今、私は実際にそれをしたと思いましたが、どういうわけかそれは私がヘッダーに書いたものを無視するか、問題は何か他のものですか？

それで、実装の問題はありますか？私はそれを間違っていますか？残念ながらサーバーログを確認できません。私は本当にここで少し立ち往生しています。

function performSignIn() {

  let headers = new Headers();

  headers.append('Content-Type', 'application/json');
  headers.append('Accept', 'application/json');

  headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
  headers.append('Access-Control-Allow-Credentials', 'true');

  headers.append('GET', 'POST', 'OPTIONS');

  headers.append('Authorization', 'Basic ' + base64.encode(username + ":" + password));

  fetch(sign_in, {
      //mode: 'no-cors',
      credentials: 'include',
      method: 'POST',
      headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

Chromeを使用しています。そのChromeCORSプラグインも使用しようとしましたが、別のエラーメッセージが表示されます。

リクエストの認証情報モードが「include」の場合、応答の「Access-Control-Allow-Origin」ヘッダーの値はワイルドカード「*」であってはなりません。起源「http://127.0.0.1:3000」がゆえのアクセスが許可されていません。XMLHttpRequestによって開始されたリクエストの資格情報モードは、withCredentials属性によって制御されます。

この回答は多くの分野をカバーしているため、次の3つの部分に分かれています。

• CORSプロキシを使用して「Access-Control-Allow-Originヘッダーがない」問題を回避する方法
• CORSプリフライトを回避する方法
• 「Access-Control-Allow-Originヘッダーはワイルドカードであってはならない」問題を修正する方法

CORSプロキシを使用して「Access-Control-Allow-Originヘッダーがない」問題を回避する方法

フロントエンドJavaScriptコードがリクエストを送信しているサーバーを制御しておらず、そのサーバーからの応答の問題が必要なAccess-Control-Allow-Originヘッダーの不足である場合でも、リクエストを行うことで機能させることができます。 CORSプロキシ。これがどのように機能するかを示すために、最初にCORSプロキシを使用しないコードをいくつか示します。

const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(url)
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))

catchブロックがヒットする理由は、ブラウザがそのコードがから返される応答にアクセスするのを防ぐためhttps://example.comです。そして、ブラウザがそれを行う理由は、Access-Control-Allow-Origin応答に応答ヘッダーがないためです。

これはまったく同じ例ですが、CORSプロキシが追加されています。

const proxyurl = "https://cors-anywhere.herokuapp.com/";
const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(proxyurl + url) // https://cors-anywhere.herokuapp.com/https://example.com
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))

注：https：//cors-anywhere.herokuapp.comを試したときにダウンしているか利用できない場合は、Herokuに独自のCORS Anywhereサーバーをわずか2〜3分でデプロイする方法について以下を参照してください。

上記の2番目のコードスニペットは、リクエストURLをhttps://cors-anywhere.herokuapp.com/https://example.com;に変更するため、レスポンスに正常にアクセスできます。このようにプロキシURLをプレフィックスとして追加すると、リクエストはそのプロキシを介して行われます。

1. リクエストをに転送しhttps://example.comます。
2. からの応答を受け取りhttps://example.comます。
3. Access-Control-Allow-Origin応答にヘッダーを追加します。
4. 追加されたヘッダーを使用して、その応答を要求元のフロントエンドコードに返します。

次に、ブラウザはフロントエンドコードが応答にアクセスすることを許可します。これは、Access-Control-Allow-Origin応答ヘッダーを含む応答がブラウザに表示されるためです。

https://github.com/Rob--W/cors-anywhere/のコードを使用して、独自のプロキシを簡単に実行できます。
次の5つのコマンドを使用して、独自のプロキシをわずか2〜3分でHerokuに簡単にデプロイすることもできます。

git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master

これらのコマンドを実行すると、たとえば、で実行されている独自のCORSAnywhereサーバーが作成されますhttps://cryptic-headland-94862.herokuapp.com/。したがって、リクエストURLの前に。を付けるのではなく、https://cors-anywhere.herokuapp.com代わりに独自のインスタンスのURLを前に付けますhttps://cryptic-headland-94862.herokuapp.com/https://example.com。

したがって、https：//cors-anywhere.herokuapp.comを使用しようとしたときに、ダウンしていることがわかった場合（まだダウンしている場合もあります）、Herokuアカウントを取得することを検討してください（まだ取得していない場合）。または、上記の手順を実行して3分で、Herokuに独自のCORSAnywhereサーバーをデプロイします。

独自に実行するか、CORS Anywhereまたは他のオープンプロキシを使用するかに関係なく、このソリューションは、リクエストがブラウザにCORSプリフライトOPTIONSリクエストを実行するようにトリガーするものであっても機能します。その場合、プロキシは必要なヘッダーAccess-Control-Allow-HeadersとAccess-Control-Allow-Methodsヘッダーも送り返すためです。プリフライトを成功させます。

CORSプリフライトを回避する方法

問題のコードは、Authorizationヘッダーを送信するため、CORSプリフライトをトリガーします。

https://developer.mozilla.org/docs/Web/HTTP/Access_control_CORS#Preflighted_requests

それがなくてContent-Type: application/jsonも、ヘッダーはプリフライトもトリガーします。

「プリフライト」の意味：ブラウザは、POST質問のコードでを試行する前に、まずOPTIONSサーバーにリクエストを送信します。サーバーが、ヘッダーPOSTを持つクロスオリジンの受信をオプトインしているかどうかを判断します。AuthorizationContent-Type: application/json

小さなcurlスクリプトでかなりうまく機能します-データを取得します。

で適切にテストするcurlにはOPTIONS、ブラウザが送信するプリフライトリクエストをエミュレートする必要があります。

curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
    -H 'Access-Control-Request-Method: POST' \
    -H 'Access-Control-Request-Headers: Content-Type, Authorization' \
    "https://the.sign_in.url"

…https://the.sign_in.url実際のsign_inURLに置き換えられます。

ブラウザがそのOPTIONSリクエストから確認する必要のある応答には、次のようなヘッダーが必要です。

Access-Control-Allow-Origin:  http://127.0.0.1:3000
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization

OPTIONS応答にこれらのヘッダーが含まれていない場合、ブラウザーはそこで停止し、POST要求を送信しようとさえしません。また、応答のHTTPステータスコードは2xx（通常は200または204）である必要があります。それが他のステータスコードの場合、ブラウザはそこで停止します。

問題のサーバーは、OPTIONS501ステータスコードでリクエストに応答していOPTIONSます。これは、リクエストのサポートを実装していないことを示しようとしていることを意味しているようです。この場合、他のサーバーは通常、405「メソッドは許可されていません」ステータスコードで応答します。

したがってPOST、サーバーOPTIONSが405または501、あるいは200または204以外でその要求に応答する場合、または必要なもので応答しない場合、フロントエンドJavaScriptコードからそのサーバーに直接要求を行うことはできません。応答ヘッダー。

問題のケースのプリフライトのトリガーを回避する方法は次のとおりです。

• サーバーがAuthorizationリクエストヘッダーを必要とせず、代わりに、たとえば、POSTリクエストの本文に埋め込まれた認証データまたはクエリパラメータに依存した場合
• サーバーがPOST本体にContent-Type: application/jsonメディアタイプを必要とせず、代わりに、値がJSONデータである名前付き（またはその他）のパラメーターとPOST同様に本体を受け入れた場合application/x-www-form-urlencodedjson

「Access-Control-Allow-Originヘッダーはワイルドカードであってはならない」問題を修正する方法

別のエラーメッセージが表示されます：

リクエストの認証情報モードが「include」の場合、応答の「Access-Control-Allow-Origin」ヘッダーの値はワイルドカード「*」であってはなりません。したがって、オリジン 'http://127.0.0.1:3000'はアクセスを許可されていません。XMLHttpRequestによって開始されたリクエストの認証情報モードは、withCredentials属性によって制御されます。

認証情報を含むリクエストの場合、Access-Control-Allow-Originレスポンスヘッダーの値が*。の場合、ブラウザはフロントエンドJavaScriptコードにレスポンスへのアクセスを許可しません。代わりに、その場合の値は、フロントエンドコードのオリジンと完全に一致する必要がありますhttp://127.0.0.1:3000。

MDN HTTPアクセス制御（CORS）の記事の「資格情報付きの要求とワイルドカード」を参照してください。

リクエストの送信先のサーバーを制御する場合、このケースに対処する一般的な方法は、Originリクエストヘッダーの値を取得し、Access-Control-Allow-Originそれを応答ヘッダーの値にエコー/反映するようにサーバーを構成することです。例：nginxの場合：

add_header Access-Control-Allow-Origin $http_origin

しかし、それは単なる例です。他の（Web）サーバーシステムは、起点値をエコーする同様の方法を提供します。

Chromeを使用しています。そのChromeCORSプラグインも使ってみました

そのChromeCORSプラグインAccess-Control-Allow-Origin: *は、ブラウザに表示される応答に単純にヘッダーを挿入しているようです。プラグインがよりスマートである場合、プラグインはその偽のAccess-Control-Allow-Origin応答ヘッダーの値をフロントエンドJavaScriptコードの実際のオリジンに設定しますhttp://127.0.0.1:3000。

したがって、テストであっても、そのプラグインの使用は避けてください。それはただ気を散らすものです。ブラウザがフィルタリングせずにサーバーから取得する応答をテストするには、curl -H上記のように使用することをお勧めします。

fetch(…)質問のリクエストのフロントエンドJavaScriptコードに関する限り：

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

それらの行を削除します。Access-Control-Allow-*ヘッダはレスポンスヘッダ。リクエストでそれらを送信することは決してありません。唯一の効果は、ブラウザをトリガーしてプリフライトを実行することです。

このエラーは、ポート番号を含め、クライアントURLとサーバーURLが一致しない場合に発生します。この場合、クロスオリジンリソースシェアリングであるCORSのサービスを有効にする必要があります。

Spring RESTサービスをホストしている場合は、SpringFrameworkのブログ投稿CORSサポートで見つけることができます。

Node.jsサーバーを使用してサービスをホストしている場合は、

1. Node.jsサーバーを停止します。
2. npm install cors --save

3. server.jsに次の行を追加します

   var cors = require('cors')
   
   app.use(cors()) // Use this after the variable declaration
   

この問題は、フロントエンドのリクエストヘッダーとして次のコードを追加したために発生しました。

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

これらのヘッダーは、要求ではなく応答に属します。したがって、次の行を含めて、それらを削除します。

headers.append('GET', 'POST', 'OPTIONS');

あなたのリクエストは'Content-Type: application/json'、CORSプリフライトと呼ばれるものをトリガーしました。これにより、ブラウザはOPTIONSメソッドを使用してリクエストを送信しました。詳細については、CORSプリフライトを参照してください。

したがって、バックエンドでは、次のような応答ヘッダーを返すことで、このプリフライトリクエストを処理する必要があります。

Access-Control-Allow-Origin : http://localhost:3000
Access-Control-Allow-Credentials : true
Access-Control-Allow-Methods : GET, POST, OPTIONS
Access-Control-Allow-Headers : Origin, Content-Type, Accept

もちろん、実際の構文は、バックエンドに使用するプログラミング言語によって異なります。

フロントエンドでは、次のようになります。

function performSignIn() {
    let headers = new Headers();

    headers.append('Content-Type', 'application/json');
    headers.append('Accept', 'application/json');
    headers.append('Authorization', 'Basic ' + base64.encode(username + ":" +  password));
    headers.append('Origin','http://localhost:3000');

    fetch(sign_in, {
        mode: 'cors',
        credentials: 'include',
        method: 'POST',
        headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

私の場合、以下のソリューションを使用します

フロントエンドまたはAngular

post(
    this.serverUrl, dataObjToPost,
    {
      headers: new HttpHeaders({
           'Content-Type':  'application/json',
         })
    }
)

バックエンド（私はphpを使用しています）

header("Access-Control-Allow-Origin: http://localhost:4200");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header("Access-Control-Allow-Headers: Content-Type, Authorization");

$postdata = file_get_contents("php://input");
$request = json_decode($postdata);
print_r($request);

使用dataType: 'jsonp'は私のために働いた。

   async function get_ajax_data(){
       var _reprojected_lat_lng = await $.ajax({
                                type: 'GET',
                                dataType: 'jsonp',
                                data: {},
                                url: _reprojection_url,
                                error: function (jqXHR, textStatus, errorThrown) {
                                    console.log(jqXHR)
                                },
                                success: function (data) {
                                    console.log(data);

                                    // note: data is already json type, you
                                    //       just specify dataType: jsonp
                                    return data;
                                }
                            });


 } // function               

これを削除します：

credentials: 'include',

私はSpringRESTを使用していて、AllowedMethodsをWebMvcConfigurerに追加して解決しました。

@Value( "${app.allow.origins}" )
    private String allowOrigins;    
@Bean
public WebMvcConfigurer corsConfigurer() {
            System.out.println("allow origin: "+allowOrigins);
            return new WebMvcConfigurerAdapter() {
                @Override
                public void addCorsMappings(CorsRegistry registry) {
                    registry.addMapping("/**")
                    //.allowedOrigins("http://localhost")
                    .allowedOrigins(allowOrigins)
                    .allowedMethods("PUT", "DELETE","GET", "POST");
                }
            };
        }

私の場合、Webサーバーは「OPTIONS」メソッドを防止しました

オプションの方法については、Webサーバーを確認してください

• Apache：https：//www-01.ibm.com/support/docview.wss？ uid = ibm10735209
• webtier：4.4.6オプションメソッドの無効化https://docs.oracle.com/cd/E23943_01/web.1111/e10144/getstart.htm#HSADM174
• nginx：https：//medium.com/@hariomvashisth/cors-on-nginx-be38dd0e19df

「webtier」を使用しています

/www/webtier/domains/[domainname]/config/fmwconfig/components/OHS/VCWeb1/httpd.conf

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

への変更

<IfModule mod_rewrite.c>
  RewriteEngine off
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

ちょうど私の2セント... 「ヘッダーなし」の問題を回避するためにCORSプロキシを使用する方法についてAccess-Control-Allow-Origin

バックエンドでphpを使用している場合、「CORSプロキシ」のデプロイは次のように簡単です。

1. 次の内容の「no-cors.php」という名前のファイルを作成します。

   $URL = $_GET['url'];
   echo json_encode(file_get_contents($URL));
   die();
   

2. フロントエンドで、次のような操作を行います。

   fetch('https://example.com/no-cors.php' + '?url=' + url)
     .then(response=>{*/Handle Response/*})`
   

追加mode:no-corsすると、APIでのcorsの問題を回避できます。

fetch(sign_in, {
        mode: 'no-cors',
        credentials: 'include',
        method: 'POST',
        headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}