よくよく考えれば当り前なんだけど、解説されてなくて気づけなかった...
フォームリクエストとは？
バリデーション 5.8 Laravelのフォームリクエストバリデーションセクションに説明があります。
HTTPリクエストをバリデーションしたりできるものです。
フォームリクエストクラスのできること
Requestクラスで使えるメソッドがすべて使える
$this->input('hoge');
// /posts/{post} とかになってるURLの{post}の部分にアクセス
$this->post;
Requestを継承しているのでもちろん使えるんですよね（自戒）
{post}にあたる部分の名前に自信がない場合はphp artisan route:listで確認できます。
authorize()のできること
bool型で認証の可否を判断
trueを返せば認証が成功したとして、処理を継続する。
falseを返せば認証に問題があるとして、403を返す。
DIされられる
public function authorize(HogeRepository $repository){
$repository->fuga();
// ...
return $bool;
}
クラスをDIして、それを使ったオレオレ認証処理を作れる。
組み合わせる
こんなテーブルがあるとする
| カラム名 | 役割 |
|---|---|
| id | 主キー |
| message | メッセージ |
| edit_key | ハッシュ化された編集キー |
フォームでメッセージと編集キーを入力すると、データベースにそれが保存され、それを消したり、編集したりしたくば編集キーを使って認証をするという感じ。
URLは/messages/{message}として、HTTPリクエストヘッダに編集キーを付け、PUTリクエストでアクセスされたものと想定。
authorize()メソッドで認証
public function authorize(){
$model = Message::findOrFail($this->message);
return Hash::check($this->header('edit-key', $model->edit_key);
}
$this->messageにはレコードのIDを含ませる。
そこからレコードを取得し、保存していたハッシュ化された編集キーと送信された生の編集キーをHash::check()で照合する。
Hash::check()は2値が同じものであればtrueを、異なるものであればfalseを返すので、これに認証の可否を任せています。
もっと複雑な認証ロジックを実装する場合は、それを他のクラスへ切り出し、authorize()へDIしてやればスッキリさを維持しつつ、理想的な処理を行えると思います。
Laravelはとても便利だ... ありがたや...