なぜ隔離を行います
同じ項目の複数laravelエンド(モバイル端末管理側は......)JWTの使用が必要な場合、ユーザ認証を行うユーザテーブルには、複数(通常はそこを)持っている場合、あなたはトークン分離を行う必要があり、または発生しますトークン、携帯端末にも権限のないユーザーで、その結果、問題の経営側に要求することができます。
この問題につながる理由は、主キーのみ可能ストアデータテーブルのJWTトークンのデフォルト値のlaravelある、とテーブルを区別しませんでした。テーブルにユーザーIDで運ばれたトークンが存在する限り、それは不正な検証につながります。
私たちは、元のJWTトークンのルックlaravelを取ります:
1 2 3 4 5 6 7 8 9 |
|
データを搬送するサブフィールドであり、他のフィールドは、JWT検証フィールドです。
私たちは、1の値をサブ参照、およびバリデータであるテーブルまたはその指定されていませんでした。このトークンは(laravelは、ドキュメントを守る理解を参照してください)異なるガードは、ユーザID 1に対応するテーブルを取得することができます、あなたが使用し、ご確認のミドルウェアを渡します。
ソリューション
限り、私たちがどのテーブルまたは生成を確認している区別して、私たちのカスタムフィールドの遵守を確認するために、独自のミドルウェアを書き込むために使用される当社のトークンカスタムフィールドの上に置くと、権限のないユーザーの問題を解決したいです期待。
トークンにカスタム情報を追加します。
私たちは、あなたがJWT認証を使用したいことを知って、ユーザーモデルは(コードはJWT文書を撮影したものです)JWTSubjectインターフェイスを実装する必要があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
私たちは、達成するためにこれらの2つの方法の役割を見ることができます。
- getJWTIdentifier:アクセスがJWT文を識別するために保存され、実際に、私たちはテーブルのユーザー名を識別する主キーフィールドに戻りたい、ここでは主キー「ID」のリターンがあり、
- getJWTCustomClaims:、配列のカスタムJWTの宣言に追加するキーと値を返します。ここでは空の配列を返し、任意のカスタム情報を追加しませんでした。
その後、我々はユーザモデルの実現getJWTCustomClaims方法で私たちのカスタム情報を追加することができます。
管理者モデル:
1 2 3 4 5 6 7 8 9 |
|
エンド・ユーザー・モデルの移動:
1 2 3 4 5 6 7 8 9 |
|
ここでは、ユーザーIDと役割名を追加します。
だから管理者は、このようなトークンを生成します。
1 2 3 4 5 6 7 8 9 10 |
|
このように生成され、エンドユーザーのモバイルトークン:
1 2 3 4 5 6 7 8 9 10 |
|
我们可以看到这里多了一个我们自己加的role字段,并且对应我们的用户模型。
接下来我们自己写一个中间件,解析token后判断是否是我们想要的角色,对应就通过,不对应就报401就好了。
编写jwt角色校验中间件
这里提供一个可全局使用的中间件(推荐用在用户验证中间件前):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|
注册jwt角色校验中间件
在app/Http/Kernel.php中注册中间件:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
使用jwt角色校验中间件
接下来在需要用户验证的路由组中添加我们的中间件:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
至此完成jwt多表用户验证隔离。