私は開発しているAPIを持っており、いくつかのルートは明らかにサーバー上の要求を完全に完了するためにユーザーインスタンスが必要です側。Laravel 5.4特定のルート上の個人アクセストークンの使用を制限します
私が疑問に思うのは、laravelの特定のルートを制限して、個人用のアクセストークンではなく完全なoauthトークンを必要とする方法があるかどうかです。 これをフィルタリングする瞬間の唯一の方法は、トークンスコープを追加することです。しかし、私はむしろ私が理解だけでなく、
思考...
おかげ
Citti
....ちょうどクライアント対個人アクセストークンの使用をフィルタリングするためにスコープを追加しません個人アクセストークンは特定のユーザーに割り当てられます。 docsから
個人アクセスクライアントを作成したら、ユーザーモデルインスタンスのcreateTokenメソッドを使用して、特定のユーザーのトークンを発行できます。
パーソナルアクセストークンは、特定のユーザーのために発行されます
Route::get('/user', function() {
return Auth::user();
})->middleware('auth:api');
そして正確になります応答：
$user = App\User::find(1);
// Creating a token without scopes...
$token = $user->createToken('Token Name')->accessToken;
このように、あなたは/userルートにBearer $tokenとの要求を行っていますPATが作成されたユーザー。したがって、ユーザーがAPIサーバーで認証された場合は、認証されたユーザーを返すauth:apiミドルウェア
でルートを保護するだけで済みます。 APIはステートレスでなければなりません。誰も技術的にログインすることができませんでした。なぜなら、渡されたトークンを介して区別する必要があるからです... – Citti
Ok @Cittiので、ユーザーがログインしていないときにこのルートにアクセスしようとすると、 'Unauthorized 401'レスポンス。だから、この場合にはログインのポップアップを表示するかもしれない –
そう、私はそれを取得、私はむしろそれをやっていない。私のアプリケーションは両方のシナリオを正しく処理できます...ユーザーの代わりに行動を起こしたい場合は、クライアントを作成し、通常のoauthプロセスを実行します。データをプルする必要がある場合や、ユーザーアクションを必要としない作成ルートを処理する必要がある場合は、個人アクセストークンを使用してください。私がしたくないことは、既存のワークフローを置き換える機能を追加することです。私はちょうど彼らがヒットしようとしているルートに基づいてどちらかを使用することを阻止したい。ルート1はパーソナルトークン+ oauthを受け入れます。 Route2はoauth – Citti