Day 5・入力の検証と横断的関心事 — バリデーション・ミドルウェア・Blade
ミドルウェア — リクエストが通る共通の関所
認証・CSRF・ログのような横断的関心事を、パイプラインで一箇所にまとめる。
横断的関心事という考え方
「ログインしていないと見せない」「CSRFトークンを確認する」「アクセスをログに残す」——これらは特定の画面だけでなく、多くのリクエストに共通して必要な処理です。こうした、機能をまたいで横断的に必要になる処理を『横断的関心事』と呼びます。
は、この横断的関心事をコントローラの外側にまとめて置く仕組みです。リクエストがコントローラに届く前(と、レスポンスが返る後)に、共通処理を挟み込みます。
パイプラインのイメージ
リクエストは、複数のミドルウェアを順番に通り抜けてからコントローラに到達します。玉ねぎの層のように、外側から一枚ずつ通過し、コントローラで折り返して、また各層を通って返っていくイメージです。
class EnsureUserIsAdmin
{
public function handle(Request $request, Closure $next): Response
{
// --- コントローラに届く「前」の処理 ---
if (! $request->user()?->isAdmin()) {
abort(403, '管理者のみアクセスできます。');
}
// $next() を呼ぶと、次のミドルウェア(最終的にコントローラ)へ進む
$response = $next($request);
// --- レスポンスが返る「後」の処理 ---
// 例: ここでレスポンスヘッダーを足すこともできる
return $response;
}
}なぜ共通処理をミドルウェアに切り出すのか
認証チェックを各コントローラに書くと、書き忘れた一箇所が重大な穴になります。共通処理を関所として一元化すれば、『このグループのルートは必ず認証を通る』と宣言的に保証でき、コントローラ本体は本来の仕事に集中できます。付け忘れによる事故を仕組みで防ぐのが狙いです。
ルートへの適用
// auth を通ったユーザーだけがアクセスできるグループ
Route::middleware(['auth'])->group(function () {
Route::get('/dashboard', [DashboardController::class, 'index']);
// さらに admin ミドルウェアを重ねる
Route::middleware(['admin'])->group(function () {
Route::get('/admin/users', [AdminUserController::class, 'index']);
});
});代表的なミドルウェア
- auth: 未ログインならログイン画面へ。認証の関所。
- CSRF検証: フォーム送信が正規のものか トークンで確認する。
- throttle: 一定時間内のリクエスト回数を制限(総当たり対策)。
- ログ記録: アクセス内容を記録して後から追える化する。
CSRFとの関係
Laravelはフォーム由来のPOSTに対し、標準でCSRF検証ミドルウェアを通します。これは『そのリクエストが本当に自分のサイトのフォームから来たか』を確認する横断的関心事の代表例です。詳しい仕組みは用語集 を参照してください。
面接ではこう言う
「認証やCSRF、ログのような、機能をまたいで共通に必要な処理はミドルウェアに寄せます。リクエストが通るパイプラインの関所として一箇所にまとめることで、コントローラ本体を本来の仕事に集中させられますし、認証の付け忘れのような事故を仕組みで防げます」
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
ミドルウェアが担うのに最も適した処理はどれですか。
ミドルウェアの『パイプライン』という考え方を、認証を例に説明してください。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。