vue-nuxt ログイン認証の実装

導入

メンターから整理し、要約と記録を作成する

リンク

https://auth.nuxtjs.org/api/options/#cookie

始める

このドキュメントによると、@nuxt/auth を使用した後、指定された cookie: false が表示されない場合は、認証トークンがデフォルトで cookie に保存されます (上記の localstorage についても同様)
したがって、ログイン インターフェースが成功すると、トークンは auth._token.{provider} の形式で保存されます。

インターフェースはリクエスト時に Cookie からトークンを取得し、それをインターフェース資格情報としてサーバーに送信します。

ディレクトリ構造

nuxt-distは、npm run devまたはnpm run buildのたびにwebpackによって生成されるファイルです。その中のコードは、実際に最後に呼び出すコードとみなすことができます（ここで直接変更やデバッグを行うこともできますが、プロジェクトを再実行するたびに復元されます。

nuxt/auth にはいくつかのスキームがあります。たとえば、この nuxt-dist/auth/schemes/local.js を参照してください。
デフォルトのオプションはいくつかあります。

私たちが書いたコードでは、$auth.loginWith を使用してこれを呼び出しましたが、実際には、loginWith は最終的に login を呼び出します。

次に、nuxt-dist/auth/schemes/local.jsにあるログインを確認します。

nuxt-dist は、npm run dev または npm run build のたびに webpack によって生成されるファイルです。ここのコードは、最後に実際に呼び出すコードと見なすことができます (ここで直接変更してデバッグすることもできますが、プロジェクトを再実行するたびに復元されます)。
nuxt/auth にはいくつかのスキームがあります。たとえば、この nuxt-dist/auth/schemes/local.js を参照してください。
デフォルトのオプションはいくつかあります。

私たちが書いたコードでは、$auth.loginWith を使用してこれを呼び出しましたが、実際には、loginWith は最終的に login を呼び出します。

次に、nuxt-dist/auth/schemes/local.jsにあるログインを確認します。

メソッド内の this.name は auth.strategy であり、これは local、local1 などであり、上記の loginWith メソッド内の setStrategy() は auth.strategy 情報をローカルに保存します。
成功すると、tokenRequiredはデフォルトでtrueになり、this.$auth.setTokenが呼び出されます。このメソッドはauth/schemes/auth.jsにあります。

この方法では

この方法では、_keyは._token.localに組み立てられます。
このメソッドはauth/storage.jsにあります

最後に、このメソッドは setCookie メソッドと serLocalStorage メソッドを呼び出し、トークンを cookies と localstorage に保存し、setCookie で再度組み立てられ、デフォルトで auth である cookies.prefix が追加されます。

最後にシリアル化後、Cookie に保存されます。
その後、axios はそれを直接クッキーから取得し、リクエストとともに送信します。

ログインと認証のロジック全体は基本的に次のようになります。

コードを読み進めてください

nuxt.config.jsで複数の認証を設定することもできます: {strategies: {local

WeChatでログイン、携帯電話番号でログイン、アカウントでログイン…

自動フェッチ

https://auth.nuxtjs.org/schemes/local
ユーザーを取得
uth モジュールはユーザーに関する情報を保存しないため、ページのリロード時にユーザーの情報を取得する方法が必要です。これがユーザー エンドポイントの目的です。デフォルトでは、ログインが成功した後にもこれが呼び出されます。

user.autoFetch が true (デフォルト) の場合、endpoints.user はログインが成功するとすぐにリクエストを送信します。このエンドポイントは、ユーザー プロパティに直接割り当てられた特定のユーザーの JSON 情報で応答する必要があります。

ログイン セッションから直接ユーザー情報を返す場合は、user.autoFetch を false に設定し、loginWith 応答からユーザー情報を取得して、setUser に渡します。

ユーザー情報の取得を完全に無効にしたい場合は、endpoints.user: false を設定します。これは、ユーザー情報エンドポイントが呼び出されないことを意味しますが、フロントエンドはユーザーについて何も知らないことも意味します。つまり、this.$auth.user は {} になります。

ps: インターフェースを置き換える必要があるため、ユーザーは自動的にクエリを実行し、結果として生じるエラーは開発に役立ちません。コメントを通じて段階的に開発できます。

ユーザー: {
          自動フェッチ: false、
      }, 

プロキシ設定

プロジェクトのバックエンドインターフェースは、バックエンドローコードプラットフォームとJavaインターフェースに基づいています。インターフェースの先頭の名前は一貫していませんが、プロキシを介して処理でき、クロスドメインの問題も解決できます。

	アクシオス:
    // // ベースURL:''
    プロキシ: true、
    プレフィックス: '/'、
    // 資格情報: false、
  },
   プロキシ： {
    '/ビジネス': {
      ターゲット: 'http://xxlb/',
      パス書き換え: {
        '^/biz': '/biz/',
        changeOrigin: true // クロスドメインかどうかを示します}
    },
    '/フロント'： {
      ターゲット: 'http://xxlb/',
      パス書き換え: {
        '^/front': '/api/front',
        changeOrigin: true // クロスドメインかどうかを示します}
    },

傍受を要求する

	アクシオス:
    // // ベースURL:''
    プロキシ: true、
    プレフィックス: '/'、
    // 資格情報: false、
  },
   プロキシ： {
    '/ビジネス': {
      ターゲット: 'http://xxlb/',
      パス書き換え: {
        '^/biz': '/biz/',
        changeOrigin: true // クロスドメインかどうかを示します}
    },
    '/フロント'： {
      ターゲット: 'http://xxlb/',
      パス書き換え: {
        '^/front': '/api/front',
        changeOrigin: true // クロスドメインかどうかを示します}
    },

異なるプレフィックスを持つインターフェースの処理

dev はローカル開発環境に使用され、サーバーにデプロイされた場合は使用できません。
例えばapiPrefix.jsというファイルを定義します
このファイルでは、すべての異なるインターフェースとそのプレフィックスの対応を列挙します。

定数temp = {
API: ['/front/login', 'xxxxxx', 'xxxxx'],
api2: ['/test', 'xxxxxx'],
xxx: […]
}

これは、プレフィックスを使用する必要があるすべてのインターフェースを明示的にリストすることと同じです。
axios のリクエスト インターセプションでは、現在のリクエスト URL に従って temp をトラバースし、どのプレフィックスに属しているかを判断してアセンブルします。
この temp で見つからないリクエストについては、デフォルトでプレフィックスは不要であり、無視できます。

これには3つの利点があります。
まず、メンテナンス時に、どのインターフェースにどのようなプレフィックスを付ける必要があるかを一目で確認できます。次に、ページでリクエストを開始するときに、各 URL で変更することなく、同じ呼び出し方法を確保できます。
第三に、バッチプレフィックスが後で変更された場合、簡単に変更できます。

実稼働環境で他のサーバー インターフェイスを呼び出す必要がある場合は、特定のルールが必要です。ルールがある場合は、ルールを一致させてから変更します。
またはインターフェースの一部。この場合も、上記と同様の方法を使用することができ、それは

定数temp = {
http://10.0.0.1/api: ['/front/login', 'xxxxxx', 'xxxxx'],
http://10.0.0.1/api2: ['/test', 'xxxxxx'],
http://10.0.0.1/xxx: […]、
…
http://10.0.1.111/api: ['/sth/xxx']
}

プレフィックスの範囲を拡張してプロトコルとドメイン名を含める

動的ルーティング構成

https://www.nuxtjs.cn/guide/routing
users-id という名前のルート パスに :id? パラメータがあり、ルートがオプションであることがわかります。必須ルートにしたい場合は、users/_id ディレクトリに index.vue ファイルを作成する必要があります。

nuxt-distは自動的にパッケージ化して設定を生成します

リダイレクトと認証権限

ミドルウェア
ここで言われているのは、認証権限の検証をグローバルに、または各ルートに配置できるということです。ミドルウェアがチェックをスキップするようにオフにすることもできます。最後に、ゲストモードという使用法も紹介します。つまり、このルートにアクセスするためにログインする必要はありませんが、ログインしたユーザーがこのページにアクセスすると、redirect.home によって設定されたルートにリダイレクトされます。

一部のシナリオでは、アクセスするためにログインする必要があります。そうでない場合は、/login ページにリダイレクトされます。処理が完了したので、auth: false を設定して、一部のページがログインにリダイレクトされないように処理できます。たとえば、現在表示されているページでは、登録前にバックグラウンドで登録リンクが生成されます。このページでは、トークン情報は必要ありません。

vue-nuxt ログイン認証の実装に関するこの記事はこれで終わりです。vue-nuxt ログイン認証に関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き閲覧してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。