Laravel 5.2 以降、組み込みの Auth 認証システムは複数のロール認証をサポートできます。つまり、管理者と一般ユーザーの 2 つの役割がある場合、同じ認証システムを通じて認証を実現できます。
#1 コードを自動的に生成しますLaravel 独自の Auth は、1 行のコマンドで関連する認証コントローラー、テンプレート、ルートを生成できます:
php artisan make:auth
この方法 AuthController 認証を生成しますコントローラーと HomeController 一般コントローラーは役に立ちません。ログインと登録に必要なテンプレート ファイルもいくつかあります。また、関連する認証ルートも生成されます。ルーティング ファイル内のソース コードは IlluminateRoutingRouter::auth(); にあり、実際にいくつかのログインおよび登録関数を構成します:
public function auth() { // Authentication Routes... $this->get('login', 'Auth\AuthController@showLoginForm'); $this->post('login', 'Auth\AuthController@login'); $this->get('logout', 'Auth\AuthController@logout'); // Registration Routes... $this->get('register', 'Auth\AuthController@showRegistrationForm'); $this->post('register', 'Auth\AuthController@register'); // Password Reset Routes... $this->get('password/reset/{token?}', 'Auth\PasswordController@showResetForm'); $this->post('password/email', 'Auth\PasswordController@sendResetLinkEmail'); $this->post('password/reset', 'Auth\PasswordController@reset'); }
#2 auth.php ファイル構成 Thisは認証に関連する設定ファイルであり、ガードやプロバイダなどの一部の概念を理解できない人が多いと推測され、ドキュメントは基本的に書かれていません。では、ガードとは一体何でしょうか?これは、guards 配列内の各項目がロールであると理解できます。デフォルトのものは Web と API であり、これらの 2 つのロールが現在認証システムを使用していることを意味します。もちろん、これら 2 つは絶対に要件を満たさないため、通常はいくつかのガードをカスタマイズします。カスタマイズも非常に簡単です。ガード配列に項目を追加するだけです。ドライバーは、この認証のユーザー ステータスを通常セッション内で保存する方法を示します。プロバイダーは以下のプロバイダー配列内の項目です。プロバイダー?これは理解しやすいです。ユーザー認証を実装したい場合は、ユーザー名とパスワードを保存する必要があります。その後、プロバイダーはユーザー情報がどのテーブルに保存されているかを Laravel に伝え、ドライバーは Laravel を操作するためにどのメソッドを使用するかを伝えます。データベース。
#3 認証 実際、Laravel によって自動生成されたコードはすでにログインと登録のニーズを満たすことができますが、各ガードには AuthController が必要なので、認証コントローラーを共有するにはどうすればよいでしょうか?ここでガードが使用されているのは、さまざまなロジックを実行するためにユーザーの ID を表すことができるためです。ただし、このガードは認証コントローラーでは取得できないため、ルーティング パラメーターを通じて実現できます。ルーティング グループを定義します。
Route::group(['prefix'=>'{guard}'],function(){ Route::auth();});
このルーティング グループでは、現在のガードを AuthController で取得できるように、ガード パラメーターにプレフィックスを設定します。一般に、Request インスタンスへの依存関係注入を通じてルーティング パラメーターを取得しますが、ここにも落とし穴があります。バージョン 5.1 より前では、ルーティング パラメーターは
$request->input('key')
を通じて取得できましたが、5.2 では機能しなくなりました。
$request->key
を介して取得する必要があります。または、ルーティング インスタンスから直接取得することもできます。その理由はわかりません。いくつかのトレイトは AuthController コントローラで使用されます。これらのトレイトは、コントローラの一部のプロパティを書き換えることで、ロジックをカスタマイズできます。 $redirectTo、$guard、$username などを含めると、1 つ目はログイン成功後にジャンプすること、2 つ目は現在使用されているガードを定義すること、3 つ目は使用されるユーザー名フィールドであることが一目でわかります。認証用。したがって、認証コントローラーでガードを取得することでカスタマイズできます。
#4 ルート保護 一般に、認証システムを作成する人はルートを保護する必要があります。では、ルートを保護するにはどうすればよいでしょうか?ドキュメントには、保護する必要があるルートに認証ミドルウェアを追加するように記載されていますが、実際はどうですか?これは確かに事実ですが、この文書には、認証ミドルウェア によって保護されたルートには Web ミドルウェア も追加する必要があり、 も Web ミドルウェア を追加する必要があるとは記載されていません。 Web ミドルウェア も追加する必要があります。重要なことは 3 回言わなければなりません。そうしないとどのような問題が発生しますか?認証が成功しても失敗しても、/ ルートにジャンプします。この大きな落とし穴に注意してください。もちろん、ミドルウェアでガードを指定して、どのガードを介して認証するかを Laravel に知らせることもできます。指定されていない場合は、構成ファイル内のデフォルトのガードが使用されます:
Route::get('profile', [ 'middleware' => 'auth:api', 'uses' => 'ProfileController@show']);
#5 Getユーザー インスタンス 認証に合格した後、Auth ファサードを通じて現在認証されているユーザー インスタンスを取得できます。
$user = Auth::user();
$user = Auth::guard('guard')->user();
#6 要約 一般的に言えば、Laravel 5.2 に付属の Auth システムは依然として非常に使いやすいですが、ドキュメントでは明確に説明されていない落とし穴がいくつかあります。何度か繰り返すと、非常に慣れてくるので、開発時間を大幅に節約できます。