ログインFEを作成して終了しました。そしていつものように、私のajaxへの参加はAxiosでした。私のコードは次のとおりです。
_const baseUrl = http://localhost:5000/project/us-central1/api
Axios.post(
`${baseUrl}/v1/user/login`,
{ ...data },
{
headers: {
Authorization: 'Basic auth...'
}
},
).then(r => console.log(r).catch(e =>console.log(e));
_
次に、ローカルのFirebase Cloud関数にリクエストを送信しようとすると、 400の不正なリクエストを受け取ります。
リクエストを確認した後、なぜプリフライトリクエストが送信されないのかと思っていましたが(これは私の知る限り)、代わりに_Sec-Fetch-Mode
_というヘッダーが表示されました。少し抽象的であるところならどこでも検索しました。そして、私は私の要求がまだ失敗する理由を何も理解できないようです。
axios
の設定に不足しているものはありますか?
私のFEはlive server(http://127.0.0.1:5500)
という名前のVSCodeプラグインで実行されています
また、私のfirebaseクラウド機能はcors
を有効にしました
_// cloud function expres app
cors({
Origin: true
})
_
どんな洞察も非常に役に立ちます。
非単純と見なされるOPTIONS
ヘッダーを含むクロスオリジン要求を送信しているため、Authorization
要求が実際に送信されています。 Chrome 76&77)の機能/バグのため、開発者ツールには表示されません。詳細については、「 Chromeが[ネットワーク]タブにOPTIONSリクエストを表示しない 」を参照してください。
プリフライトリクエストは、サーバーがCORSに対応していない場合(例:古いものやメンテナンスされていない場合)、または明示的に必要な場合に、ブラウザー側でクロスオリジンリクエストを拒否できるメカニズムです。クロスオリジンリクエストを拒否します(どちらの場合も、サーバーはAccess-Control-Allow-Origin
ヘッダーを設定しません)。 CORSはサーバー側でOrigin
ヘッダーをチェックすることで実行できますが、実際にはCORSは不要なクロスオリジンリクエストを送信する前にフィルタリングするので、ネットワークトラフィックとサーバーの負荷を軽減し、古いサーバーが受信しないようにします。デフォルトではクロスオリジンリクエスト。
一方、Sec-Fetch-Mode
は Fetch metadata headers (Sec-Fetch-Dest
、Sec-Fetch-Mode
、Sec-Fetch-Site
and Sec-Fetch-User
)の1つです。これらのヘッダーは、要求が送信されたコンテキストについてserverに通知することを目的としています。この追加情報に基づいて、サーバーは要求が正当であるかどうかを判断するか、単に拒否することができます。これらはHTTPサーバーが特定のタイプの攻撃を軽減するために存在し、CORSとは関係ありません。
たとえば、<img src="https://mybank.com/giveMoney?amount=9999999&[email protected]">
がSec-Fetch-Dest
に設定されるため、古き良き"image"
攻撃はサーバー側で検出される可能性があります(これは単なる例であり、サーバーがGET
でエンドポイントを公開していることを意味しますお金の操作のための方法は、実際の生活では明らかにそうではありません)。
結論として、フェッチメタデータヘッダーはプリフライトリクエストを置き換えるようには設計されておらず、さまざまなニーズを満たすため、プリフライトリクエストと共存するように設計されています。また、400エラーはこれらとは関係なく、エンドポイントの仕様に準拠していないリクエストに関係している可能性があります。
スプレッド演算子にドットがありません。これは正しい構文です:
{...データ}
「データ」の前の3つのドットに注意してください。
オブジェクトでのスプレッド演算子の使用については、こちらをご覧ください:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax