ユーザーが401を取得したら、ログアウトしようとしています。axiosを使用して、APIからデータを返しています。
私は周りを見回していて、同じaxios.interceptors.responseを見つけました
axios.interceptors.response.use(
response => response,
error => {
const {status} = error.response;
if (status === 401 ) {
store.dispatch('snackBar', snackbarObj)
}
return Promise.reject(error);
}
)
Error.responseが定義されていないようです。何が悪いのかわかりませんか?何か案は?
ブラウザーがプリフライトを実行するときに401の不正な応答を受け取ったため、Axiosで実行しているリクエストから応答が得られませんOPTION
リクエスト。これにより、実行しようとしているリクエストに対してNetwork Errorが発生します。
これは [〜#〜] cors [〜#〜] の動作とバックエンドがOPTION
リクエストを処理する方法に関連しています。バックエンドサーバーがプリフライトリクエストをどのように処理するかを理解するには、理解することが重要です プリフライトリクエストを導入する動機は何ですか。
バックエンドサーバーはOPTION
リクエストの認証をチェックするべきではありません。クロスドメインリクエストを受け入れるエンドポイントに対してリクエストが行われていることを検証し、そうであれば成功コードを返します。
その後、自動的に、ブラウザーは最初に意図された要求を続行します。
これにより、ユーザーが認証されなくなった場合、Axiosインターセプターは401エラーコードを受け取ります。
恥知らずの自己宣伝、私は (axios-middleware と呼ばれる簡単なAxiosプラグインを公開しました大きなアプリでのAxiosインターセプターの使用を抽象化するのに役立ちます。 認証されていない要求を自動的に処理するミドルウェア の例を提供し、要求を再送信する前に再度認証を試みます。
プリフライトOPTION
リクエストが正常に終了したが、次のGET/POST
のレスポンスにAccess-Control-Allow-Origin
http-headerが含まれていない場合も、レスポンスオブジェクトは未定義になります。
私の場合、nginx 401応答にAccess-Control-Allow-Origin
ヘッダーを追加すると問題が解決します
ベストプラクティスではありませんが、この方法で解決します
axios.interceptors.response.use(
response => response,
error => {
if (typeof error.response === "undefined") {
// do somthing
}
return Promise.reject(error);
}
)