CORSクロスドメイン:FLaskではクロスドメイン問題をどう解決しますか?RESTful-appiではCORSはどう使いますか?

参考記事:https://zhuanlan.zhihu.com/p/75738155
クロスドメインとは何ですか
クロスドメインを理解するには、まず同じソース戦略について話します.ソースポリシーは、Netscapeが提案した有名なセキュリティポリシーで、JavaScriptをサポートするすべてのブラウザがこのポリシーを使用します.同源とはドメイン名、プロトコル、ポートが同じことです.ページがスクリプトを実行する時、訪問したリソースが同じソースかどうかを確認します.もし同じソースでないなら、データを要求する時、ブラウザはコンソールに異常を報告します.ドメインをまたぐと、ドメイン名から別のドメイン名を要求するリソースを意味します.ドメイン名でお願いします.ドメインをまたぐ時、ブラウザはその他のドメイン名のウェブサイトのスクリプトを実行することができなくて、ブラウザーの同源の策略からもたらしたので、ブラウザーの加えた安全な制限です.
ドメインを越えて厳密に言えば、プロトコル、ドメイン名、ポートにはどのような違いがありますか?
何がCORSですか
CORSはW 3 C標準で、全称は「ドメインをまたぐ資源共有」(Cross-orign resource shring)です.これは、ブラウザがソースサーバを横断して、XMLttpRequestを要求することを許可して、AJAXが同じソースでしか使用できない制限を克服しました.
長所と短所
利点:

は、POSTおよびすべてのHTTP要求

をサポートする.

セキュリティはJSOPより高い

です.

先端のすることは少ないです.
短所:

は、IE 9および以下の

のような古いバージョンのブラウザに対応していません.

サービスサポートが必要です.

使用するにはちょっと複雑です.
FlashkではCORSを使用してクロスドメイン問題を解決します.
flash-cordsをインストールしますpip install flask-corsもしあなたの試みの関数が飾り器をルートとしてurlするなら、以下の方法が使えます.

@cross_を使用します.オリジン

from flask_cors import cross_origin

@app.route("/")
@cross_origin()
def helloWorld():
  return "Hello, cross-origin-world!"

CORS関数を使用してグローバル構成を適用する:

from flask_cors import CORS

app = Flask(__name__)
cors = CORS(app)

@app.route("/api/v1/users")
def list_users():
  return "user example"

もちろん、CORS関数では自由パラメータ構成が可能です.CORS関数のパラメータ説明:
パラメータ
タイプ
ヘッドフィールド
説明
レスポンス
辞書、重ね合わせまたは文字列
なし
グローバル構成は、ドメインをまたぐAPIインターフェースを可能にする.
オリジン
リスト、文字列、正規表現
Access-Coontrol-Allow-Origin
ドメインをまたぐアクセスを許可するソースを設定します.*はすべて許可されています.
methods
リスト、文字列
Access-Coontrol-Alllow-Mottehods
ドメイン間サポートの要求方式を設定します.例えば、GET、POST
expose_headers
リスト、文字列
Access-Coontrol-Expose-Headers
カスタム要求応答のヘッド情報
allow_headers
リスト、文字列、正規表現
Access-Coontrol-request-Headers
ドメイン横断を許可する要求ヘッダを設定します.
supports_credentials
ブール値
Access-Coontrol-Alllow-Chredentials
クッキーの送信を許可するかどうか、falseは許可されていません.
max_メッセージ
整数、文字列
Access-Coontrol-Myx-Age
予備検査要求の有効時間は長いです.
Resource類を継承して書くRESTful-PIインターフェースであれば、上記の方法は使えません.
ドメイン間要求をサポートする必要があるAPIクラスにおいて、クラス別の方法optionsを追加すると、ドメイン間問題を解決することができる.

class YourAPI(Resource):
    def options(self):
        return {'Allow': '*'}, 200, {'Access-Control-Allow-Origin': '*',
                                     'Access-Control-Allow-Methods': 'HEAD, OPTIONS, GET, POST, DELETE, PUT',
                                     'Access-Control-Allow-Headers': 'Content-Type, Content-Length, Authorization, Accept, X-Requested-With , yourHeaderFeild',
                                     }

可能な理由:
クロスドメイン問題の要求が発生した場合、POST要求であろうと、PUT要求であろうと、フロントエンドは優先的にOPTTIONS要求を開始します.そして、フロントエンドページのエラーメッセージを結合して、最後に結論を出します.フロントエンドはドメイン横断要求を処理する時、OPTIONS要求の許容範囲を先に開始します.ドメイン横断要求を解決する時、各リソースurlにoptions要求方式を追加し、適切な応答ヘッダ情報を返すだけで、ドメイン間問題を解決できるはずである.
具体的に構成可能なパラメータの説明:

Access-Coontrol-Allow-Originこのヘッダ情報はサーバによって返され、それらのクライアントのドメイン名を明示的に指定してこのリソースにアクセスすることができます.その値は「*」を使って任意のドメイン名を許可します.

完全なドメイン名(例えば:https://example.com)

クライアントに検証情報を送る必要がある場合(例えば、cookies).この値は＊ではいけません.完全なドメイン名が必要です.

Access-Coontrol-Alllow-Coredentialsというヘッダ情報は、cookiesを通じて認証情報を伝えるリターンデータのみをサーバでサポートします.その値は一つしかないです.trueです.サイドバンドにまたがって情報を検証する場合、サーバーはこの値を設定するために努力しなければなりません.サーバはユーザーのクッキーを取得できません.

Access-Coontrol-Headersは、カンマ区切りのリストを提供して、サーバがサポートする要求データの種類を表します.もしあなたがカスタムヘッドを使用すると(例えば、x-authentication-tokenサーバがOPTIOS要求に戻る時に、この値をこのヘッダに入れると、要求がブロックされます).

Access-Coontrol-Expose-Headersは似ています.このリターン情報にはヘッダ情報のセットが含まれています.これらの情報はそれらのクライアントが使用できることを表しています.他に中にいない頭部の情報は制限されます.

Access-Coontrol-Alllow-Mottehodsのカンマ区切りのリストは、サーバーサポートの要求タイプ(例えば、GET、POST)

を示しています.

Originというヘッダ情報は、要求データの一部に属する.この値はこの要求がブラウザで開いているどのドメインから発信されるかを示しています.セキュリティのため、ブラウザはこの値を変更することができません.