Angular2 tips WEB WEBフロントエンド開発

Angular2のクロスドメインアクセスの問題対応

投稿日:2017年4月26日 更新日:

Angular2のクロスドメインの対応を備忘録としてまとめました。私がAngular2のSPAを開発する時、フロントエンド側がangular-cliで、バックエンド(WEB-API)側がPHP+IISとなる組み合わせが多く、フロントエンドとバックエンドで開発用WEBサーバが異なるため(ポートも異なるため)、どうしてもクロスドメイン環境になってしまいます。この開発環境下において、IE11は特に問題が発生しませんでしたが、FireFox52.0.2とChrome57.0.2987.133ではクロスドメインのアクセスの問題が発生しました。

 

クロスドメインアクセスの問題とは

ブラウザに実装されている”同一生成元ポリシー”の制約により、自分を生成したドメイン以外のドメインのサーバと通信することができない事が問題としてあげられます。中規模以下のシステムの場合、通常、フロントエンド側のSPAのプログラム(HTML、JavaScript、CSS)とバックエンド側のWEB-APIのプログラム(PHP、Java、,NETなどのアプリケーションサーバとして構築)は同じドメイン配下のサーバに配置される事が多いと思いますので、クロスドメインの問題は発生しません。しかし、この両者のプログラムが異なるドメインのサーバに配置された場合、クロスドメインの問題が発生する事になります。

 

(エラー発生状況)

フロントエンド側開発をangular-cli(簡易WEBサーバ)、バックエンド側開発をPHP(WEBサーバはIIS)で行っている時、下記のようにHTTP通信処理でエラーが発生し、error.text();の戻り値として{ "isTrusted": true }の内容が戻ってくる状況となりました。

下図のエラーは後ほど説明しますが、preflightリクエストに対する応答処理が十分でないため発生しているエラーでした。

 

とりあえず動作させたい対応

セキュリティ、処理効率などは関係なく、とりあえず動作させたい場合は、バックエンド側処理でレスポンスヘッダに以下の項目を設定する事で対応できると思います。

レスポンスヘッダ 説明 設定例
Access-Control-Allow-Origin 許可するリクエスト元のURLを設定 *, "http://www.ifelse.jp"
Access-Control-Allow-Method 許可するメソッドを設定 *, "GET,PUT,POST,DELETE"
Access-Control-Allow-Headers 許可するヘッダ情報を設定 content-type

PHPで記述すると以下のようになります。

 

対応指針

クロスドメインアクセスの対応方法としては、以下の3つに大別できそうです。当該ページでは、CORSの対応方法について記述します。CORS(Cross-Origin Resource Sharing)とはクロスドメインアクセスを安全に実現する仕様です。

(1)JSONPで対応する方法

JSONP(JSON with padding)とは、JavaScriptを使用してクロスドメインの問題を解決する方法で、HTMLのscriptタグ、JavaScript(関数)、JSONを組み合わせて実現します。HTMLのscriptタグのsrc属性には、別ドメインのURLを指定することができる点を利用して、別ドメインのサーバからデータを取得することを可能にする方法です。同一生成元ポリシーに従わないため、悪意を持った第三者からの攻撃のリスクが高くなる可能性があります。

(2)CORS(そのままリクエストを送る)

通常のAjaxによりHTTPリクエストと同等で、サーバ側でレスポンスヘッダに「Access-Control-Allow-Origin」を設定する事で対応する方法です。次項に説明する『CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)』場合の最初のpreflightリクエスト動作がない場合と同等になります。

(3)CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)

前項に説明した『CORS(そのままリクエストを送る)』にpreflightリクエスト動作を追加した内容になります。最初にpreflightリクエスト(OPTIONSメソッド)をサーバに送信し、サーバ側で接続確認を行いブラウザ側に返信します。接続に問題がなければ、再度、ブラウザは本来の要求リクエストを送り、本来処理を行います。サーバ側ではpreflightリクエストの対応処理を行う必要があります。また、前項同様にサーバ側でレスポンスヘッダに「Access-Control-Allow-Origin」を設定する必要があります。

『CORS(そのままリクエストを送る)』方法と『CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)』方法のどちらの方法を採用するかは、リクエスト条件によってブラウザが決定します。preflightリクエストの送信有無は以下の条件によってブラウザが決定し、条件全てに当てはまらないリクエストの場合に、preflightリクエストが自動で送られます。

  • HTTPメソッドがGET, POST, HEADのいずれか
  • HTTPヘッダにAccept, Accept-Language, Content-Language, Content-Type以外のフィールドが含まれない
  • Content-Typeの値はapplication/x-www-form-urlencoded, multipart/form-data, text/plainのいずれか

以下のようなajaxでよく見かけるコードは、上記の条件により、『CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)』方法となります。

CORSのどちらの方式になるかはブラウザが決定するため、サーバ側では正しくpreflightリクエストの対応を行わないとクロスドメインアクセスの問題により通信が出来ない状態となります。

 

CORS(そのままリクエストを送る)

『CORS(そのままリクエストを送る)』方法でクロスドメインアクセスを対応させるためには、ブラウザがpreflightリクエストを行わない条件でプログラムする必要があります。そのため、フロントエンド側の開発では、前項の説明の通り必然的にボディフォーマットをJSONデータでリクエストする事が出来ないことになります。[キー1=値1&キー2=値2&...]というようにキーと値のペアにするx-www-form-urlencoded形式で送付する必要があります。また、サーバ側では、以下のようにレスポンスヘッダに「Access-Control-Allow-Origin」を設定する必要があります。

レスポンスヘッダ 説明 設定例
Access-Control-Allow-Origin 許可するリクエスト元のURLを設定 *, "http://www.ifelse.jp"

PHPで記述すると以下のようになります。

しかしながら、フロントエンド側の開発でどうしてもJSON形式のデータフォーマットでリクエストしたい要望も発生すると思います。その時は、リクエストヘッダのContent-Typeをx-www-form-urlencodedに設定してJSON形式のデータを「無理やり」リクエストし、サーバ側処理でリクエストヘッダの内容を判断しながらリクエストデータを取り出す処理を行うことで対応するしかないと思われます。

 

CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)

『CORS(最初にpreflightリクエストを送ってから、その後、本来の要求リクエストを送る)』方法でクロスドメインアクセスを対応させるためには、ブラウザがpreflightリクエストを送る前提となりますので、サーバ側でpreflightリクエストに対する対応処理が必要になります。preflightリクエストの以下の項目をチェックします。

preflightリクエストヘッダのOrigin

Originは送信元のドメインが設定され、内容が許可されているドメインであるかチェックする必要があります。Originが許可されていないドメインの場合、preflightリクエスト失敗としてアクセス許可しない必要があります。Originの内容はpreflightリクエスト送信時にブラウザによって自動的に付加されます。

preflightリクエストヘッダのAccess-Control-Request-Method

Access-Control-Request-Methodは、preflightリクエスト後の本来要求分のリクエストで使用するメソッドを知らせるための項目です。許可されていないメソッドが定義されている場合は、preflightリクエスト失敗としてアクセス許可しない必要があります。Access-Control-Request-Methodはpreflightリクエスト送信時にブラウザによって自動的に付加されます。

preflightリクエストヘッダのAccess-Control-Request-Headers

Access-Control-Request-Headersは、Access-Control-Request-Method同様にpreflightリクエスト後の本来要求分のリクエストで使用されるヘッダ情報をサーバー側に知らせるための項目です。許可されていないヘッダ情報が定義されている場合は、preflightリクエスト失敗としてアクセス許可しない必要があります。Access-Control-Request-Headersはpreflightリクエスト送信時にブラウザによって自動的に付加されます。

 

サーバ側では、上記のpreflightリクエストの各項目の許可チェックを行い、結果をレスポンスヘッダに設定してブラウザ側に返信する必要があります。レスポンスヘッダの項目は下表のようになります。

レスポンスヘッダ 説明 設定例
Access-Control-Allow-Origin 許可するリクエスト元のURLを設定 *, "http://www.ifelse.jp"
Access-Control-Allow-Method 許可するメソッドを設定 *, "GET,PUT,POST,DELETE"
Access-Control-Allow-Headers 許可するヘッダ情報を設定 content-type

 

以下はPHPでpreflightリクエスト処理を記述した例です。

以下はSPRING MVCでpreflightリクエスト処理を記述した例です。

 

ブラウザはpreflightリクエスト動作でクロスドメインのサーバがアクセス許可であると認識すると、次に本来要求分のリクエストを送信します。サーバ側では本来要求分のレスポンスヘッダにAccess-Control-Allow-Originの設定を行う必要があります。今までの流れをキャプチャした実際の様子が下図のようになります。

(1)preflightリクエスト動作

上図はpreflightリクエストヘッダとレスポンスヘッダです。preflightリクエストがOPTIONSメソッドでリクエストされている事が分かります。また、preflightリクエストヘッダのOrigin、Access-Control-Request-Method、Access-Control-Request-Headersは、次の本来要求分のリクエスト情報である事が分かります。preflightリクエストに対するレスポンスは、Access-Control-Allow-Origin、Access-Control-Allow-Method、Access-Control-Allow-Headersが設定されています。

(2)本来要求分のリクエスト動作

上図は本来要求分のリクエストヘッダとレスポンスヘッダです。『CORS(そのままリクエストを送る)』方法の場合と同じになり、本来要求分のレスポンスヘッダにAccess-Control-Allow-Originが設定されている事が分かります。

 

 

スポンサーリンク

スポンサーリンク

-Angular2, tips, WEB, WEBフロントエンド開発

執筆者:

関連記事

Chromeを使ったAngular-cliのオンラインデバッグの方法について

当セクションでは、angular-cliの開発において、ブレイクポイントを設定するオンラインデバッグの方法について説明したいと思います。ChromeのデベロッパーツールによってTypescriptのソ ...

SEO対策のまとめ

SEO対策は良く言われるように、(1)クローラーの巡回フェーズ、(2)ページのインデックス登録フェーズ、(3)検索順位決定フェーズの3つのフェーズで考える必要があるようです。SEO対策は様々なWEBペ ...

TypeScriptとSystemJSを使ったWEBフロントエンド開発

当セクションでは前回の『SystemJSを使ったWEBフロントエンド開発』をもとに具体的なプロジェクトを作成して、モジュール管理ツールとしてのSystemJSの機能を把握したいと思います。以前に紹介し ...

SystemJSを使ったWEBフロントエンド開発

当セクションはSystemJSを使ったWEBフロントエンド開発について説明します。JavaScriptをロードするための最も基本的な方法はscriptタグで実現することですが、SPAを構築するフロント ...

Angular2のプロジェクト作成から開発をしてIISにデプロイまで

当セクションではAngular2のプロジェクト作成し、プロジェクト開発を行い、IISへのデプロイまでを説明したいと思います。 angular-cliでAngular2の開発環境を構築している事が前提と ...