前後端分離:WebAPI+Vue開発——クロスドメイン設定
前後端分離:WebAPI+Vue開発——リモートデータ要求axios
前後端分離:WebAPI+Vue開発——クロスドメイン設定
前後端分離:WebAPI+Vue開発——身分認証
本論文で採用した戦略は「クロスドメイン資源共有-Cross Origin Resource Sharing(CORS)」である.
一般的に、フロントエンドとバックエンドは2つのプロジェクトにおいて、フロントエンドのドメイン名のような2つのドメイン名で展開されます.http://www.abc.com/ウェブAPIドメイン名http://api.abc.com/これはドメインをまたぐ問題が発生しました.ドメインをまたぐ時にこのようなエラーメッセージが発生します.
「Failed to loadhttp://api.abc.com/api/user: No'Access-Coontrol-Origin'header is present on the requested reource.Origin'http://www.abc.com'is therefore not allowed access."
大体の意味はhttp://www.abc.comWebAPIインターフェースからはありません.http://api.abc.com/データを取得する権限は、jsで非同期的に要求された保護機構であり、axios独自の問題ではないことを明確にしておきたい.このブログには詳細な説明があります.
私が採用した方式はWebAPIのwebconfig構成を修正し、system.webServerタグに下記の構成を追加します.
このように処理してから終わりますか?まだです.上の引用のブログでOPTTIONSの処理について一言で説明しましたが、OPTTIONSをなぜ処理するかというと、処理方法はコントローラごとに修正が必要で、これは不便です.
なぜOPTTIONSの要請がありますか?これは主流のブラウザーがドメインをまたいで要求する仕組みで、POSTの要求の前にOPTTIONSの事前要求を送り、事前に状態コードを返すように要請した場合、私達が本当に欲しいPOST要求を送ります.つまりPOSTは先に小弟のOPTTIONSを探して道を探します.弟はこの道が歩けると言っています.POSTはやっと出発します.この文章はもっと詳しく話してください.
二つの処理方法が提供されます.
一、globalにOPTTIONS方法を追加する処理
このラベルはドメインをまたぐ要求の中で本当に大きな穴です.(後で確認してみます.これはピットではないことが分かりました.OPTTIONSの要求がスパン攻撃を増加することができます.サーバー側のリスクが大きいです.)OPTTIONSの要求を受け付けないという意味です.
私が検証した結果、上記の2つの方法のいずれを選んでも問題を解決できます.しかし、上記の解決策を見つける前に、post要求テストをする時、パラメータを渡さないと、サービス側がoptions要求に対して上の処理をしなくても正常に戻ることができます.ブラウザのNetWorkに表示されていますので、ブラウザからoptionsの事前要求がありません.
前後端分離:WebAPI+Vue開発——クロスドメイン設定
前後端分離:WebAPI+Vue開発——身分認証
本論文で採用した戦略は「クロスドメイン資源共有-Cross Origin Resource Sharing(CORS)」である.
一般的に、フロントエンドとバックエンドは2つのプロジェクトにおいて、フロントエンドのドメイン名のような2つのドメイン名で展開されます.http://www.abc.com/ウェブAPIドメイン名http://api.abc.com/これはドメインをまたぐ問題が発生しました.ドメインをまたぐ時にこのようなエラーメッセージが発生します.
「Failed to loadhttp://api.abc.com/api/user: No'Access-Coontrol-Origin'header is present on the requested reource.Origin'http://www.abc.com'is therefore not allowed access."
大体の意味はhttp://www.abc.comWebAPIインターフェースからはありません.http://api.abc.com/データを取得する権限は、jsで非同期的に要求された保護機構であり、axios独自の問題ではないことを明確にしておきたい.このブログには詳細な説明があります.
私が採用した方式はWebAPIのwebconfig構成を修正し、system.webServerタグに下記の構成を追加します.
このように処理してから終わりますか?まだです.上の引用のブログでOPTTIONSの処理について一言で説明しましたが、OPTTIONSをなぜ処理するかというと、処理方法はコントローラごとに修正が必要で、これは不便です.
なぜOPTTIONSの要請がありますか?これは主流のブラウザーがドメインをまたいで要求する仕組みで、POSTの要求の前にOPTTIONSの事前要求を送り、事前に状態コードを返すように要請した場合、私達が本当に欲しいPOST要求を送ります.つまりPOSTは先に小弟のOPTTIONSを探して道を探します.弟はこの道が歩けると言っています.POSTはやっと出発します.この文章はもっと詳しく話してください.
二つの処理方法が提供されます.
一、globalにOPTTIONS方法を追加する処理
protected void Application_BeginRequest()
{
if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
{
Response.End();
}
}このラベルはドメインをまたぐ要求の中で本当に大きな穴です.(後で確認してみます.これはピットではないことが分かりました.OPTTIONSの要求がスパン攻撃を増加することができます.サーバー側のリスクが大きいです.)OPTTIONSの要求を受け付けないという意味です.
私が検証した結果、上記の2つの方法のいずれを選んでも問題を解決できます.しかし、上記の解決策を見つける前に、post要求テストをする時、パラメータを渡さないと、サービス側がoptions要求に対して上の処理をしなくても正常に戻ることができます.ブラウザのNetWorkに表示されていますので、ブラウザからoptionsの事前要求がありません.