ナビゲーションガードでVueルートを保護します

Webアプリケーションのセキュリティ認証は非常に重要です。パーソナライズされたエクスペリエンスを有効にし、ユーザー固有のコンテンツ（ログインステータスなど）をロードし、許可を評価して許可されていないユーザーが個人情報にアクセスするのを防ぐために使用することもできます。

通常、アプリケーションは、特定のルートの下にコンテンツを配置し、リダイレクトルールを構築することにより、コンテンツを保護し、ユーザーにアクセス権に基づいてリソースにアクセスするように指示します。保護されたルートの背後にコンテンツを確実に配置するには、独立した静的ページを構築する必要があります。このようにして、リダイレクトルールはリダイレクトを正しく処理できます。

VUEなどの最新のフロントエンドフレームワークで構築されたシングルページアプリケーション（SPA）の場合、リダイレクトルールを使用してルーティングを保護することはできません。すべてのページは、ブラウザの視点からの単一のエントリファイルから来ているため、1つのページのみがあります：index.html。 SPAでは、ルーティングロジックは通常、ファイルをルーティングします。この記事は、主にここで認証を構成します。 Vueのナビゲーションガードに特に依存して、認証固有のルートを処理するために、ルートが完全に解析される前に選択されたルートにアクセスするのに役立ちます。それがどのように機能するかを掘り下げましょう。

ルーティングの基本

ナビゲーションガードは、ルーティングの解決方法に関する追加機能を提供するVueルーターの特定の機能です。それらは主にエラー状態を処理し、ワークフローを突然中断することなくシームレスにユーザーをガイドするために使用されます。

Vueルーターには、グローバルガード、ルーター限定ガード、コンポーネントガードの3つの主要なカテゴリがあります。名前が示すように、グローバルガードは、ナビゲーションをトリガーするとき（つまり、URLが変更されたとき）と呼ばれます。これは、関連するルートを呼び出すとき（つまり、URLが特定のルートと一致するとき）、ルートのコンポーネントの作成、更新、または破壊時にコンポーネントガードが呼び出されます。各カテゴリには、アプリケーションルーティングをより詳細に制御する他の方法があります。 Vueルーターの各ナビゲーションガードで利用可能なすべての方法の迅速な内訳を次に示します。

グローバルガード

• beforeEach ：任意のルートに入る前に操作（このスコープにアクセスできません）
• beforeResolve ：ナビゲーション確認前のアクションですが、コンポーネントガードの後（以前と同じ、この範囲にアクセスできます）
• afterEach ：ルーティングの解決後の操作（ナビゲーションに影響を与えることはできません）

ルート専用ガード

• beforeEnter ：特定のルートに入る前に操作（グローバルガードとは異なり、このガードはこれにアクセスできます）

コンポーネントガード

• beforeRouteEnter ：ナビゲーション確認前およびコンポーネント作成の前に実行されるアクション（これにアクセスできません）
• beforeRouteUpdate ：同じコンポーネントを使用して新しいルートを呼び出すと実行された操作
• beforeRouteLeave ：ルートを出る前に操作

ルーティングを保護します

それらを効果的に実装するには、特定のシナリオでいつ使用するかを知ることが役立ちます。たとえば、分析のためにページビューを追跡する場合は、ルートの後にトリガーされ、関連するコンポーネントが完全に解析されるため、グローバル後のガードを使用することをお勧めします。ルートの解析の前にデータをVuexストレージにプレフィングする場合は、前のルート専用ガードを使用してそうすることができます。

この例では、ユーザーアクセス権に基づいて特定のルートの保護を扱っているため、コンポーネントガード、つまり前のフックを使用します。このナビゲーションガードにより、解析が完了する前に正しいルートにアクセスできます。これは、ユーザーが渡す前にデータを取得するか、データがロードされているかどうかを確認できることを意味します。実装の仕組みの詳細を掘り下げる前に、既存のルーティングファイルに前のフックがどのように組み込まれているかを簡単に見てみましょう。以下は、保護されたルートを含むサンプルルーティングファイルです。以前のフックを次のように追加します。

 const router = new Vuerouter（{
  ルート：[
    ...
    {
      パス：「/保護」、
      名前：「保護」、
      コンポーネント：import（/ * webpackchunkname： "Protected" */'./pretected.vue'）、
      前の（へ、から、次へ）{
        //ここにロジック}
    }
  ]
}）

ルーティング構造

Beforyenterの構造は、Vueルーターで利用可能な他のナビゲーションガードと変わりません。次の3 toのパラメーターを受け入れます。アプリケーションが去る「現在/差し迫った過去」ルートfrom 。 next 、ルートを正常に解決するために呼び出さなければならない関数。

一般に、Vueルーターを使用する場合、次は引数なしで呼び出されます。ただし、これは永続的な成功状態を想定しています。私たちの場合、不正なユーザーが保護されたリソースにアクセスできず、適切にリダイレクトできる代替パスがあることを確認したいと考えています。これを行うには、パラメーターを次に渡します。これを行うには、ルート名を使用してユーザーをナビゲートします。

次（{
  名前：「ダッシュボード」
}）

この例には、ユーザーの承認トークンを保存するVuexストアがあると仮定しましょう。ユーザーが権限を持っているかどうかを確認するには、このストアを確認し、適切にまたはルートを介して失敗します。

前の（へ、から、次へ）{
  // vuexストレージを確認する//
  if（store.getters ["auth/haspermission"]）{
    次（）
  } それ以外 {
    次（{
      名前：「ダッシュボード」//セキュアルートに戻る//
    }）;
  }
}

イベントが同期して発生し、VUEX操作が完了するまでルートが時期尚早にロードされないようにするために、ナビゲーションガードを変換してAsync/awaitを使用しましょう。

 async beforeder（to、from、next）{
  試す {
    var haspermission = await store.dispatch（ "auth/haspermission"）;
    if（haspermission）{
      次（）
    }
  } catch（e）{
    次（{
      名前：「ダッシュボード」//セキュアルートに戻る//
    }）
  }
}

ソースを覚えておいてください

これまでのところ、当社のナビゲーションガードは、許可されていないユーザーを出身地（つまり、ダッシュボードページ）にリダイレクトすることにより、保護されたリソースにアクセスできないようにする目的を達成してきました。それでも、そのようなワークフローは破壊的です。リダイレクトは予想外であるため、ユーザーはそれがユーザーエラーであると考え、ルートに繰り返しアクセスしようとする場合があります。最終的にアプリケーションが破損していると考えます。この問題を解決するために、ユーザーがいつ、なぜリダイレクトされるのかをユーザーに知らせる方法を作成しましょう。

クエリパラメーターを次の関数に渡すことでこれを行うことができます。これにより、保護されたリソースパスをリダイレクトURLに添付できます。したがって、ユーザーにアプリにログインするように促したり、停止した場所を覚えていないように適切な権限を取得するように促したい場合は、そうすることができます。以下に示すように、以前の機能に渡されたルートオブジェクトを介して、保護されたリソースのパスにアクセスできます。

 async beforeder（to、from、next）{
  試す {
    var haspermission = await store.dispatch（ "auth/haspermission"）;
    if（haspermission）{
      次（）
    }
  } catch（e）{
    次（{
      名前：「ログイン」、//セキュアルートに戻る//
      クエリ：{redirectfrom：to.fullpath}
    }）
  }
}

通知します

ユーザーが保護されたルートにアクセスできないワークフローを強化する次のステップは、メッセージを送信してエラーと問題の解決方法を通知することです（正しい許可をログインまたは取得することにより）。これを行うには、リダイレクトが発生したかどうかを確認するために、特にbeforerouteenterを使用してコンポーネントガードを使用できます。リダイレクトパスをクエリパラメーターとしてルーティングファイルに渡すため、ルーティングオブジェクトをチェックしてリダイレクトが発生したかどうかを確認できます。

 beforerouteenter（to、from、next）{
  if（to.query.redirectfrom）{
    //何かをする//
  }
}

先に述べたように、すべてのナビゲーションガードは、ルートを解決するために隣に電話しなければなりません。以前に見たように、次の関数の利点は、オブジェクトを渡すことができることです。わからないかもしれないことは、次の関数でVUEインスタンスにアクセスできるということです。おお！これがどのように見えるかです：

 next（（）=> {
  console.log（this）//これはvueインスタンスです}）

あなたは、前に使用するとき、あなたは技術的にこの範囲にアクセスしていないことに気づいたかもしれません。これは事実かもしれませんが、VMを機能に渡すことでVueインスタンスにアクセスできます。

 next（vm => {
  console.log（vm）//これはvueインスタンスです}）

これは、追加の構成なしで関連するエラーメッセージを使用してデータプロパティを簡単に作成して適切に更新できるため、これは特に便利です。この方法を使用して、次のようなコンポーネントが取得されます。

<template><div>
    {{errormsg}}

    ...

  </div>
</template>

<script>
export default {
  name: "Error",
  data() {
    return {
      errorMsg: null
    }
  },
  beforeRouteEnter(to, from, next) {
    if (to.query.redirectFrom) {
      next(vm => {
        vm.errorMsg =
          "对不起，您没有访问请求路由的权限"
      })
    } else {
      next()
    }
  }
}
</script>

結論は

認証をアプリケーションに統合するプロセスは難しい場合があります。許可されていないユーザーがルートにアクセスしないようにする方法と、ユーザーのアクセス許可に基づいてワークフローを構築する方法を説明し、ユーザーを保護されたリソースにリダイレクトします。これまでのところ、私たちの仮定は、アプリケーションで認証を構成していることです。まだ構成しておらず、すぐに起動して実行したい場合は、認証をサービスとして使用することを強くお勧めします。 Netlifyの認証ウィジェットやAuth0のロックなど、一部のプロバイダーがあります。

以上がナビゲーションガードでVueルートを保護しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。