背景
セキュリティは徐々に人気を得た安全な都市、スマートシティ、シャープエンジニアリング、高度道路交通の継続的な構成では、セキュリティ企業のために、このような広大な市場の顔はちょうどより多くの機会と挑戦ではありません。ほとんどの今日のカメラの伝統的な監視方法は、このように、ストレージリソース、貧しいリアルタイム検索の難しさと、大規模なカメラ膨大な映像データ検索によって引き起こされる他の問題によって占められた映像データの蓄積が大量で、その結果、手動監視を取り除くことができて、警察の多くを必要としていません。
これらの問題を解決するために、近年では、ビデオ監視産業は発展の主な方向である：「高精細、ネットワークベース、インテリジェント」また、市場の需要の変化を導く、新たな市場の需要を作成中に、システムをアップグレードするには、ビデオ監視機器、高度な技術革新。
クロスドメイン認証の問題によって引き起こさ研究EasyNVR
クロスドメインとは何ですか？
ときウェブドメイン名から別のドメイン名を要求されたリソース、ドメイン名、ポート、プロトコルのいずれか違うのブラウザは、クロスドメインです。
なぜ、クロスドメインの問題があります
同一生成元ポリシー制限ブラウザ用。同一生成元ポリシー（同一生成元ポリシー）は同一生成元ポリシーの欠如、ブラウザの通常の機能が影響を受ける可能性がある場合は、ブラウザのコアは、また、最も基本的なセキュリティ機能です、慣例です。ウェブは、同一生成元ポリシーに基づいて構築されると言うことができますが、ブラウザが実現元ポリシーに向けられています。元ポリシーは、別のドメインの相互作用にドメインjavascriptのスクリプトとコンテンツを防ぐことができます。いわゆる相同（同一でドメインを参照）は、2つのページが同じプロトコル（プロトコル）、ホスト（ホスト）とポート番号（ポート）を有しています
ソリューション
1は、サーバ処理
1）ログインに成功すると、サーバーは積極的にクッキーにトークンを書きます
以前のインターフェースの設計によると、ログインが成功すると、サーバーがトークンにHTTPレスポンスボディを返し、クライアントは自分のトークン書き込みクッキーの責任となります。クロスドメインのシナリオでは、これは動作しません、ブラウザの制限により、クライアントはできませんトークンは、サーバーのSet-Cookie HTTP応答ヘッダーフィールドを追加します。サーバは、代わりにこの問題を持っていないトークンクッキーを書くためのイニシアチブをとる。nonsubtypedドメインクッキーを書いて、書き込みトークン= XXX
2）統一サービス料を終了し、設定クロスドメインアクセスを行うことを約束した
サーバーの構成とクロスドメイン徐料はクッキーを運び、あなたは、HTTPレスポンスヘッダに以下の二つを追加する必要があります。
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: $http_origin
HTTT起源前アクセス制御 - 許可 - 起源*配置されていないが、現在の需要クライアント
ログオフすると3）、サーバは、クッキーからトークンをクリーンアップするためのイニシアチブ取る
のSet-Cookie：=トークンを、期限が切れる =木を、1970年1月1日00:00:00 GMT。
2、クライアント処理
クライアントは、クロスドメイン設定を追加する必要がありEasyNVRクッキーやインタラクティブなインターフェースで保存されたすべてのトークンを表示する必要がxhrFields :. {WithCredentials：真}ず、クロスドメイン：真
次のようにクロスドメインのようなサンプル・ログイン・インターフェースを呼び出します。
$.ajax({
type: "GET",
url: "http://other-domain/api/v1/login",
xhrFields: {
withCredentials: true
},
crossDomain: true,
data: {
username: 'admin',
password: '21232f297a57a5a743894a0e4a801fc3'//admin
}
});
