Under_the_hood on ララジャパン

【Under the hood】エラーバッグの構造

Mon, 05 Jun 2023 01:50:26 +0900

普段、エラーバッグからエラーを取得する際、$errors->first(’name’)などとしますが、この時裏ではどんな処理が行われているかご存知でしょうか？私自身、全然意識せずに使っていましたが、調べてみると実はdefaultという名前付きエラーバッグからエラーを取得している事が分かりました。

前回の記事、名前付きエラーバッグによるエラー管理の執筆時にエラーバッグの構造について調べたのでまとめます。久々にUnder the hoodシリーズ（？）です。前回の記事の内容が多く含まれているのでまだの方は先にそちらを読むことをオススメします。

$errorsの構造

どう言うことか？$errorsの構造を紐解きながら説明します。エラー発生時にblade側でdd($errors)とすると以下の様な出力が確認できます。

Illuminate\Support\ViewErrorBag {#1285 ▼
  #bags: array:1 [▼
    "default" => Illuminate\Support\MessageBag {#1286 ▼    // ← key が default
      #messages: array:1 [▼
        "name" => array:1 [▼
          0 => "名前を入力してください。"
        ]
      ]
      #format: ":message"
    }
  ]
}

これを見て分かることは

$errorsの実態はViewErrorBagのインスタンスである
ViewErrorBagの$bagsプロパティにMessageBagがdefaultというキーで格納されている
エラーメッセージはMessageBagの$messagesプロパティに格納されている

つまり、$errors->first(’name’) とした時は、bagsプロパティの、defaultキーの、（MessageBagの）messagesプロパティの、nameキーの最初のエラーを取得している訳ですね。想像してたより深い構造をしています。

$errors->first(...)の処理を追う

構造からデータへアクセスする際のイメージが掴めたので実際のコードを追ってみましょう。$errors->first(…)とした時、$errorsはViewErrorBagのインスタンスなのだから、ViewErrorBagにfirst()メソッドが定義されているのだろう、と普通は思いますよね。ところが、ViewErrorBagにはそんなメソッドがありません。代わりに以下のマジックメソッドがcallされています。

vendor/laravel/framework/src/Illuminate/Support/ViewErrorBag.php

...
    /**
     * Dynamically call methods on the default bag.
     *
     * @param  string  $method
     * @param  array  $parameters
     * @return mixed
     */
    public function __call($method, $parameters)
    {
        return $this->getBag('default')->$method(...$parameters);
    }
...

マジックメソッド __call() についての詳しい解説はPHPのドキュメントを確認して頂きたいのですが、簡潔に説明すると、

クラスに存在しないメソッドがcallされた場合に実行されるメソッド
第一引数（$method）は実行しようとしたメソッド名
第二引数（$parameters）は実行しようとしたメソッドに渡す予定だった引数

なので例えば、$errors->first(’name’) 実行時は$method が first、　$parameters が [’name’]となります。getBag()は指定のkeyのMessageBagを$bagsから取得するメソッドです。従って、$errors->first(…) はdefaultというキーに紐づいた MessageBagクラスのfirst()をcallしているという事ですね。

名前付きエラーバッグの場合

今度は名前付きエラーバッグの場合の処理を追ってみましょう。前回の記事のおさらいになりますが、名前付きエラーバッグからエラーを取得する際は$errors->エラーバッグ名->first(…) などとします。例えば、エラーバッグ名がuserなら、

$errors->user->first('name');

です。

このコードを見ると、userプロパティがあるのかな？と思いがちですが、（Again！）そんなプロパティはViewErrorBagに存在しません。今度は__get()というマジックメソッドがcallされます。

vendor/laravel/framework/src/Illuminate/Support/ViewErrorBag.php

...
    /**
     * Dynamically access a view error bag.
     *
     * @param  string  $key
     * @return \Illuminate\Contracts\Support\MessageBag
     */
    public function __get($key)
    {
        return $this->getBag($key);
    }
...

getBag() は前項でも出てきましたね。ここでは紐づいたMessageBagを返しているだけの様です。

まとめ

通常のエラーバッグと名前付きエラーバッグ、どちらもエラー参照時にはgetBag()にてMessageBagを取得していることが分かりました。違いは、通常のエラーバッグ時はハードコードされたdefaultというキーを使用しているのに対し、名前付きエラーバッグは任意のキーを使用しているという点のみで、処理自体に違いはありません。冒頭で、通常のエラーバッグがdefaultという名前付きエラーバッグである、と言ったのはそういう意味です。なので実は以下の様にエラーを参照することもできます（意味は全く無いですが）

$errors->default->first('name');

【Under the hood】url.intendedはいつどこでセットされたのか？

Wed, 04 May 2022 07:59:30 +0900

前回の記事、ログイン後のリダイレクト先、その２では未ログインの状態でログインが必要なページにアクセスした場合、ログインページへ飛ばされ、ログインすると元々アクセスしたかったページへリダイレクトされる挙動について確認し、sessionのurl.intendedにセットされた値によってログイン後のリダイレクト先が決定する事が理解できました。しかし、url.intendedは一体いつどこでsessionにセットされたのでしょうか？気になったので処理を追ってみました。

注意

今回の記事に掲載しているソースコードはLaravel8から引用しました。Laravel9ではPHP8.0の記法が導入され一部異なりますが行っている処理は同じなのでそちらを使う場合でも参考になるかと思います。

Illuminate\Auth\Middleware\Authenticate.php

ルートのmiddlewareにauthを指定すると、そのページにリクエストが投げられた際にこのクラスのauthenticate()が実行されます。まずはここから見ていきましょう。このメソッドでは$this->auth->guard($guard)->check()にてユーザがログイン済みか否かを確認し、未ログインであればその後の$this->unauthenticated($request, $guards);が実行されます。unauthenticatedはAuthenticationExceptionをスローします。

vendor/laravel/framework/src/Illuminate/Auth/Middleware/Authenticate.php

    /**
     * Determine if the user is logged in to any of the given guards.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function authenticate($request, array $guards)
    {
        if (empty($guards)) {
            $guards = [null];
        }

        foreach ($guards as $guard) {
            if ($this->auth->guard($guard)->check()) {    // ログイン済みかチェック
                return $this->auth->shouldUse($guard);
            }
        }
        $this->unauthenticated($request, $guards);    // 未ログインならこちらを実行
    }

    /**
     * Handle an unauthenticated user.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function unauthenticated($request, array $guards)
    {
        throw new AuthenticationException(    // 専用の例外をスロー
            'Unauthenticated.', $guards, $this->redirectTo($request)
        );
    }

Illuminate/Foundation/Exceptions/Handler.php

Laravelの全ての例外はApp\Exceptions\Handlerクラスにて処理されます。実際に実行される処理は親クラスである、Illuminate\Foundation\Exceptions\Handlerクラスに定義されています。例外をHTTPレスポンスに変換するrender()を見てみると、AuthenticationExceptionが投げられた場合の処理が記述されています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    /**
     * Render an exception into an HTTP response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Throwable  $e
     * @return \Symfony\Component\HttpFoundation\Response
     *
     * @throws \Throwable
     */
    public function render($request, Throwable $e)
    {
        ...

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);    // ←AuthenticationExceptionが投げられた場合の処理
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        ...
    }

そして、同じクラス内のunauthenticated()を呼び出しています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    ...

    /**
     * Convert an authentication exception into a response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Illuminate\Auth\AuthenticationException  $exception
     * @return \Symfony\Component\HttpFoundation\Response
     */
    protected function unauthenticated($request, AuthenticationException $exception)
    {
        return $this->shouldReturnJson($request, $exception)
                    ? response()->json(['message' => $exception->getMessage()], 401)
                    : redirect()->guest($exception->redirectTo() ?? route('login'));
    }

    ...

ajaxリクエストの場合はjsonレスポンスを返し、そうでない場合は、redirect()->guest(…)が実行されます。

Illuminate\Routing\Redirector

guest()はコメントにある通り、カレントのURLをセッションにセットしリダイレクトレスポンスを作成します。このカレントのURLというのがアクセスしようとしていたURLの事であり、setIntendedUrl()によってsessionのurl.intendedにセットされるのです。

vendor/laravel/framework/src/Illuminate/Routing/Redirector.php

    /**
     * Create a new redirect response, while putting the current URL in the session.
     *
     * @param  string  $path
     * @param  int  $status
     * @param  array  $headers
     * @param  bool|null  $secure
     * @return \Illuminate\Http\RedirectResponse
     */
    public function guest($path, $status = 302, $headers = [], $secure = null)
    {
        $request = $this->generator->getRequest();

        $intended = $request->method() === 'GET' && $request->route() && ! $request->expectsJson()    // ←カレントURLを取得
                        ? $this->generator->full()
                        : $this->generator->previous();

        if ($intended) {
            $this->setIntendedUrl($intended);
        }

        return $this->to($path, $status, $headers, $secure);
    }

    ...
    /**
     * Set the intended url.
     *
     * @param  string  $url
     * @return void
     */
    public function setIntendedUrl($url)
    {
        $this->session->put('url.intended', $url);    // sessionのurl.intendedにセット
    }

url.intendedは色々なクラスの色々なメソッドを介して最終的にセットされているため、少し複雑でしたが処理の流れを把握できてスッキリしました。お疲れさまでした。