20191219のlaravelに関する記事は7件です。

投稿日：2019-12-19T21:05:58+09:00

【 Eagerロード】コメントと、コメントに対する返信について、それぞれユーザー名を取得したい

【 Eagerロード】コメント＆コメントに対する返信について、それぞれユーザー名を別テーブルから取得したい

2019年11月から、Laravel歴数ヶ月の初心者が投稿型ナレッジベースのコミュニティサイトを作るというチャレンジ中。作りたいアプリケーション→機能を因数分解→ググる→先人の轍をたどる（写経する）→ぬかるみにはまる→エラー解消の神を探す→解決を繰り返す日々( ·ㅂ·)و 。備忘録として、Qiitaに投稿しています。

今回はハマったポイントを共有

投稿に対し、コメントがつけられ、さらにそのコメントに対して返信ができるような機能を実装しようとしていた時のこと。

一つの投稿に紐づいているコメントとそれに対する返信を全て取得し、viewファイルへ渡してあげたい。その際、コメントしたユーザーと返信したユーザーについて、それぞれ名前をusers_tableから引っ張ってきたいと思ったが、コメントのユーザー名まではうまくいったけど、返信したユーザー名を取得するところで詰まった。

前提

テーブルは以下のような設計になっており、投稿にコメントを書くことができ、一つ一つのコメントに対して返信ができるような構造。コメント、返信のいずれもuser_idでusers_tableと紐づいています。

posts_table

id

title

body

user_id

comments_table

id

post_id(posts_tableのidに紐付き)

body

user_id(users_tableのidに紐付き)

replies_table

id

comment_id(comments_tableのidに紐付き)

body

user_id(users_tableのidに紐付き)

users_table

id

name

リレーションの設定

リレーションは、以下のような関係性になっています。

投稿は複数のコメントを持ち、コメントは一つの投稿に従属

コメントは複数のリプライを持ち、リプライは一つのコメントに従属

ユーザーは複数の投稿・コメント・リプライを持ち、投稿・コメント・リプライのいずれも一人の投稿者に従属する

それぞれ、モデルに以下のように設定しています。
＊余談・・・テーブルデザイン・リレーションについては、きっともっと賢い書き方があると思います。どなたかいい方法をご存知でしたら教えてくれると嬉しいです(、._. )、
#Post.php
class Post extends Model
{
    // 投稿は複数のコメントを持ち、コメントは一つの投稿に従属
    public function comments()
    {
        return $this->hasMany('App\Comment');
    }

    // 投稿は一人の投稿者に従属
    public function user()
    {
        return $this->belongsTo('App\User');
    }
}

#Comment.php
class Comment extends Model
{
    // 投稿は複数のコメントを持ち、コメントは一つの投稿に従属
    public function post()
    {
        return $this->belongsTo('App\Post');
    }

    // コメントは一人の投稿者に従属
    public function user()
    {
        return $this->belongsTo('App\User');
    }

    // コメントは複数のリプライを持ち、リプライは一つのコメントに従属
    public function replies()
    {
        return $this->hasMany('App\Reply');
    }
}

#Reply.php
class Reply extends Model
{
    // リプライは一人の投稿者に従属
    public function user()
    {
        return $this->belongsTo('App\User');
    }

    // コメントは複数のリプライを持ち、リプライは一つのコメントに従属
    public function comment()
    {
        return $this->belongsTo('App\Comment');
    }
}

#User.php
class User extends Model
{
    // 投稿者は複数の投稿を持つ。
    public function posts()
    {
        return $this->hasMany('App\Post');
    }

    // 投稿者は複数のコメントを持つ。
    public function comments()
    {
        return $this->hasMany('App\Comment');
    }

    // 投稿者は複数のリプライを持つ。
    public function replies()
    {
        return $this->hasMany('App\Reply');
    }
}
コントローラー

投稿のid($post_id)を指定し、DBからデータを取得して行きましょう。

親のモデルに対するクエリと同時にリレーションを取得してしまう「Eagerロード」という、スッキリした書き方があるそうです。

Eagerロードについては、laravelでwithを使ってSQLの読み込み回数を減らすに詳しく書いてあります。
#PostsController.php
public function show($post_id)
    {
        $comments = Comment::with(['user', 'replies', 'replies.user'])
            ->where('comments.post_id', $post_id)
            ->get();

        return view('posts.show', [
            'comments' => $comments,
        ]);
    }
with後の丸括弧内に入っている３つが、取得したいリレーション先（テーブル）になります。

'user'（←Comment.phpモデルの"public function user()"で指定したメソッド名）
'replies'（←Comment.phpモデルの"public function replies()"で指定したメソッド名）
'replies.user'（←Reply.phpモデルの"public function user()"で指定したメソッド名）

comment->userとcomment->repliesは直接の従属関係にありますが、comment->replies->userへと、祖孫関係にあるところまでリーチできるという便利さに感動！！٩(๑′∀ ‵๑)۶•¨•.¸¸♪

参照

こちらに答えがありました〜！！ありがとうございます٩(ˊᗜˋ*)و
[Laravel] Eloquent リレーションと Eager Loading
Laravel with（Eagerロード）の使い方・サンプル付き

反省

そもそも、Eagerロードという名前・書き方にたどり着くまでにかなり時間がかかってしまった。一つ一つ経験を積み上げないとダメだなぁ・・・(´;ㅿ;｀)

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T20:13:39+09:00

Laravel で Rails の抽象 ActiveModel みたいなやつが欲しくなった

TL;DR

車輪の再発明してしまったのでソースコードの墓場にする記事

内容

データベースを使わないけど， app/Services 配下に置くような外部 API サービスのレスポンスエンティティを Eloquent ライクに使いたいニーズがあった。

最初 Eloquent Model を継承することも考えたが，意味のないメソッドがごちゃごちゃ入ってくるのが鬱陶しいので

HasAttributes
HidesAttributes
GuardsAttributes

の3つのトレイトをベースに，足りないものや動作修正の必要があるものを適宜ケアして，最小限の記述で作ってみたのでここにぶん投げます。IDE でチェックしながらメソッド埋めやったのでエラーとかは起こらないはず…

<?php

namespace App\AbstractEntities;

use Illuminate\Contracts\Support\Arrayable;
use Illuminate\Database\Eloquent\Concerns\GuardsAttributes;
use Illuminate\Database\Eloquent\Concerns\HasAttributes;
use Illuminate\Database\Eloquent\Concerns\HidesAttributes;
use Illuminate\Database\Eloquent\MassAssignmentException;
use Illuminate\Support\Collection;
use LogicException;

abstract class Entity implements Arrayable
{
    use HasAttributes, HidesAttributes, GuardsAttributes;

    public const CREATED_AT = 'created_at';
    public const UPDATED_AT = 'updated_at';

    /**
     * @var bool
     */
    public $timestamps = true;

    /**
     * @var bool
     */
    public $incrementing = true;

    /**
     * @var string
     */
    protected $primaryKey = 'id';

    /**
     * @var string
     */
    protected $keyType = 'int';

    /**
     * @var array
     */
    protected $relations = [];

    /**
     * Create an existing Entity instance.
     *
     * @param array $attributes
     * @return static
     */
    public static function hydrate(array $attributes = [])
    {
        return (new static())->forceFill($attributes)->syncOriginal();
    }

    /**
     * Create existing Entity instances.
     *
     * @param array $attributesArray
     * @return \Illuminate\Support\Collection|static[]
     */
    public static function hydrateMany(array $attributesArray = []): Collection
    {
        $collection = new Collection();
        foreach ($attributesArray as $key => $attributes) {
            $collection[$key] = static::hydrate($attributes);
        }
        return $collection;
    }

    /**
     * Create a new Entity instance.
     *
     * @param array $attributes
     */
    public function __construct(array $attributes = [])
    {
        $this->fill($attributes);
    }

    /**
     * Apply updates to an existing Entity instance.
     *
     * @param array $attributes
     * @return $this
     */
    public function apply(array $attributes)
    {
        return $this->forceFill($attributes)->syncOriginal();
    }

    /**
     * Fill the model with an array of attributes.
     *
     * @param array $attributes
     * @throws \Illuminate\Database\Eloquent\MassAssignmentException
     * @return $this
     */
    public function fill(array $attributes)
    {
        $totallyGuarded = $this->totallyGuarded();

        foreach ($this->fillableFromArray($attributes) as $key => $value) {
            if ($this->isFillable($key)) {
                $this->setAttribute($key, $value);
            } elseif ($totallyGuarded) {
                throw new MassAssignmentException(sprintf(
                    'Add [%s] to fillable property to allow mass assignment on [%s].',
                    $key,
                    get_class($this)
                ));
            }
        }

        return $this;
    }

    /**
     * Fill the model with an array of attributes. Force mass assignment.
     *
     * @param array $attributes
     * @return $this
     */
    public function forceFill(array $attributes)
    {
        return static::unguarded(function () use ($attributes) {
            return $this->fill($attributes);
        });
    }

    /**
     * Determine if the given relation is loaded.
     *
     * @param string $key
     * @return bool
     */
    public function relationLoaded(string $key): bool
    {
        return array_key_exists($key, $this->relations);
    }

    /**
     * Set the given relationship on the model.
     *
     * @param string $key
     * @param mixed $value
     * @return $this
     */
    public function setRelation(string $key, $value)
    {
        $this->relations[$key] = $value;

        return $this;
    }

    /**
     * Determine if the model uses timestamps.
     *
     * @return bool
     */
    public function usesTimestamps(): bool
    {
        return $this->timestamps;
    }

    /**
     * Get the value indicating whether the IDs are incrementing.
     *
     * @return bool
     */
    public function getIncrementing(): bool
    {
        return $this->incrementing;
    }

    /**
     * Get the primary key for the model.
     *
     * @return string
     */
    public function getKeyName(): string
    {
        return $this->primaryKey;
    }

    /**
     * Get the auto-incrementing key type.
     *
     * @return string
     */
    public function getKeyType(): string
    {
        return $this->keyType;
    }

    /**
     * Get the format for database stored dates.
     *
     * @return string
     */
    public function getDateFormat(): string
    {
        return $this->dateFormat ?? 'Y-m-d H:i:s';
    }

    /**
     * Get the database connection for the model.
     */
    public function getConnection(): void
    {
        throw new LogicException(static::class . ' is not an Eloquent Model; Database Connection is not available.');
    }

    /**
     * Dynamically retrieve attributes on the model.
     *
     * @param string $key
     * @return mixed
     */
    public function __get(string $key)
    {
        return $this->getAttribute($key);
    }

    /**
     * Dynamically set attributes on the model.
     *
     * @param string $key
     * @param mixed $value
     */
    public function __set(string $key, $value): void
    {
        $this->setAttribute($key, $value);
    }

    /**
     * Determine if an attribute or relation exists on the model.
     *
     * @param string $key
     * @return bool
     */
    public function __isset(string $key): bool
    {
        return $this->getAttribute($key) !== null;
    }

    /**
     * Unset an attribute on the model.
     *
     * @param string $key
     */
    public function __unset(string $key): void
    {
        unset($this->attributes[$key]);
    }

    /**
     * Convert the model instance to an array.
     *
     * @return array
     */
    public function toArray(): array
    {
        return array_replace($this->attributesToArray(), $this->relationsToArray());
    }
}

機能制約

データベース絡む系は全部無し
- リレーションは手動で setRelation() するのみ
APIレスポンスとしてそのまま返すことも無いと思うのでインタフェースは Jsonable とかは実装せず Arrayable のみ
- ArrayAccess も基本使わないので無し
existing() で外部 API からの取得結果レスポンスからのインスタンス生成を想定
apply() で外部 API からの更新結果レスポンスをインスタンスに反映することを想定

既存のライブラリ

jenssegers/model: This model provides an eloquent-like base class that can be used to build custom models in Laravel and other frameworks

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T14:00:54+09:00

【Laravel】イベントとリスナーの関係について整理する

Laravelには、イベントとリスナーという機能があります。

Laravelの公式サイトには、イベントとリスナーの作成方法は書かれているものの、イベントとはなにか、リスナーとは何かについては書かれていないようです。

エンジニアとして基礎中の基礎だから教えるまでもないということなのでしょうか。
残念ながら僕はその基礎ができていないようなのでイベントとリスナーについて調べてみました。

イベントとリスナーの関係性

https://www.ritolab.com/entry/35
こちらの記事を参考にすると、こう説明されています。

オブザーバパターンとは、デザインパターンの一つで、簡単に言うと監視される側と監視する側の関係を持つプログラム構造で、監視される側の変化（イベント=発行）を、監視する側（リスナー=購読）がキャッチして処理を行う。

イベントとリスナーの関係のことをオブザーバーパターンというらしいです。
そして、毎回混乱するのは、監視される・監視するの意味です。

監視の定義が曖昧すぎて、もっと噛み砕いてもらわないとわかりません。
なので、僕なりに噛み砕いてみました。

イベントとリスナーの書き方

イベントは監視される側らしいのですが、まず誰に監視されるのかというと、リスナーですね。ここまではわかります。
そして、何を監視されるのか、これは、イベントの中身です。

イベントは、以下のようなeventヘルパを利用することで呼び出すことができます。
event(new AccessDetection(str_random(100)));

そして、EventServiceProvider.phpにイベントが起こった時にリスナーを発動させるよう登録をしておきます。
EventServiceProvider.php
<?php

namespace App\Providers;

use Illuminate\Support\Facades\Event;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        'App\Events\Event' => [
            'App\Listeners\EventListener',
        ],
        // アクセス時にイベントを発行する側
        'App\Events\AccessDetection' => [
            // テキストを生成＆書き込みを行うリスナー側
            'App\Listeners\MakeTextListener',
        ],
    ];

    /**
     * Register any events for your application.
     *
     * @return void
     */
    public function boot()
    {
        parent::boot();

        //
    }
}
app/Events/AccessDetection.phpの中身に、値の受け渡しなどを記述しておきます。
そうすると、イベントが呼び出されたときに、リスナーで値を使うことができます。

最後に、リスナーの内容を記述します。
app/Listeners/MakeTextListener.php
<?php

namespace App\Listeners;

use App\Events\AccessDetection;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;

class MakeTextListener
{
    /**
     * Create the event listener.
     *
     * @return void
     */
    public function __construct()
    {
        //
    }

    /**
     * Handle the event.
     *
     * @param  AccessDetection  $event
     * @return void
     */
    public function handle(AccessDetection $event)
    {
      // テキストファイル作成
       $file = sprintf('%s/%s.txt', storage_path('texts'), date('Ymd-His'));
      touch($file);
      // 書き込み
       $current = file_get_contents($file);
      $current .= $event->param;
      file_put_contents($file, $current);
    }
}
イベントからリスナーが発動するまでの流れ

イベントが起こって、リスナーが発動するまでの流れを整理しておきます。

コントローラーでeventヘルパを使って、イベントを起こす

プロバイダーに登録してあるイベントが呼び出される

イベントに記述した値がリスナーに受け渡される

リスナーが発動する

このような流れになります。

イベントとリスナーの使いみち

一般的には、コントローラーをコンパクトにするために使われます。

例えばメール送信機能は、ユーザ登録時、購入時、更新時などで共通して使われますが、それをコントローラーに書いていたら内容が重複してしまいます。

なので、イベントとリスナーに記述しておいて、それぞれのコントローラからイベントを起こすだけで、メール送信ができるようにしておくのです。

使いみちはいろいろありますが、メールやslackへの通知の際に使うのが一般的かなと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T10:37:41+09:00

PHP7.4対応版Laradockを、ビルドしただけの話（2019/12/17時点）

この内容は2019/12/17時点の話です。
あなたがこの記事をご覧になっているころには、LaraDockが対策済みになっているかもしれません。
（きっとこの記事を書いている最中にでも修正されているに違いない。）

始めに

本記事はDocker ComposeのプロジェクトであるLaradockのPHP7.4対応版の、以下のサービスを動作させることを目的としています。

workspace

nginx

php-fpm

php-worker

mysql

他のコンテナの動作については言及しません。

各コンテナをビルドする際に変更したファイルと変更箇所

1. mysql/my.cnf

MySQL8を使いたいのでデフォルトに認証方式を変更する。
mysql/my.cnfの最終行に追記
+ default_authentication_plugin=mysql_native_password
2. php-fpm/Dockerfile

--with-libzipオプションがなくなったから削除。
php-fpm/Dockerfileの54行目付近
-     docker-php-ext-configure zip --with-libzip && \
+     docker-php-ext-configure zip && \ 
3. php-worker/Dockerfile

oniguruma-devが必要らしい。
php-worker/Dockerfileの32行目付近
-  supervisor
+  supervisor \
+  oniguruma-dev
--with-libzipオプションがなくなったから削除。
php-worker/Dockerfileの70行目付近
-    docker-php-ext-configure zip --with-libzip && \
+    docker-php-ext-configure zip && \
追伸1

LaradockはPHPのiniファイルで、error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICTと指定されているため、arrayかstring以外の型に対して配列スタイルでアクセルするとNotice警告でエラー扱いになります。
依存関係のライブラリが対応していないケースがあるため、しっかり動作検証を行う必要がありそうです。
（実際に手元の開発環境で発生しました…。）

追伸2

php本家ドキュメント(https://www.php.net/)の調子が悪いように感じる…。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T10:36:05+09:00

Laravel 6.3 でリクエストのAPIキーへの検証・スロットリングをする

こちらは Fusic その2 Advent Calendar 2019 - Qiita の19日目の記事です

GETでJSONを取得するAPIサーバを構築しているのですが、リクエストパラメータに付与されたAPIキーを使ってアクセス回数制限を行いたいという話になりました。

やりたいこと

LaravelへのリクエストをAPIキーをもとに回数制限（スロットリング）を行いたい
- そもそもAPIキーがないリクエストは落としたい
- そもそもAPIキーの検証もしたい
- APIキーごとに制限回数は可変としたい
- ~~Laravel標準のThrottleRequestsを何とかして楽したい~~
本番はアプリケーションサーバは複数台構成のため
- キーの管理には DynamoDB を使いたい ←
- キャッシュも DynamoDB を使いたい ←

環境

Laravel : 6.3
aws-sdk-php : 3.112.28

Illuminate\Routing\Middleware\ThrottleRequests について

Laravel では何もしなければ最初から APIリクエストに対してスロットルが有効になっています。

設定箇所

app/Http/Kernel.php に記載があります。

<?php

    /**
     * The application's route middleware groups.
     *
     * @var array
     */
    protected $middlewareGroups = [
        ...
        'api' => [
            'throttle:60,1',
            'bindings',
        ],
        ...
    ];

Laravel / ThrottleRequests の云々とかオーバーライドとか｜開発室ブログ｜株式会社アクセスジャパン
こちらの記事に中の挙動や詳しい解説書かれています。大変助かりました。

具体的な処理

Illuminate\Routing\Middleware\ThrottleRequests::handle で行われている処理を見てみます。

<?php

    public function handle($request, Closure $next, $maxAttempts = 60, $decayMinutes = 1, $prefix = '')
    {
        // アクセス元ごとに、アクセス回数を管理するためのキーを発行する
        $key = $prefix.$this->resolveRequestSignature($request);

        // app/Http/Kernel.phpの記載 または リクエストしたユーザの情報から、最高試行回数を取得
        $maxAttempts = $this->resolveMaxAttempts($request, $maxAttempts);

        // キャッシュに記録されているキーのアクセス回数が最高試行回数を超えていないかチェック
        if ($this->limiter->tooManyAttempts($key, $maxAttempts)) {
            // 超えていた場合は 429 Too Many Requests を返却
            throw $this->buildException($key, $maxAttempts);
        }

        // キャッシュにキーのアクセスを加算
        $this->limiter->hit($key, $decayMinutes * 60);

        $response = $next($request);

        // ヘッダーに最高試行回数と残りアクセス可能な回数を追加
        return $this->addHeaders(
            $response, $maxAttempts,
            $this->calculateRemainingAttempts($key, $maxAttempts)
        );
    }

やってみる

やりたいことは、APIキーごとの検証・制限となるため APIキーをキャッシュに書き込むキーとすればよさそう

方針

APIキーの存在チェック: handleの最初にやる
APIキーの検証 : DynamoDBへ存在確認する
APIキーごとに制限回数は可変としたい : maxAttempts を DynamoDBから取得する。
- DynamoDB はシンプルに key, max_attempts の２つを使うようにする
- 最高試行回数 -1 はもう利用できないAPIキーとする

実装

準備

ローカルでもAWSでもいいので、キャッシュ用のDynamoDBとAPIキー管理用のDynamoDBが必要です。

キャッシュにDynamoDBを使う

Laravel5.8 からキャッシュストアにDynamoが公式で対応しているので簡単です。
envの値などは各自の環境で追加する必要があります。
こっちのDynamoは DYNAMODB_CACHE_TABLE に定義

config/cache.php に追記

<?php

return [
        ...
        'dynamodb' => [
            'driver' => 'dynamodb',
            'key' => env('AWS_ACCESS_KEY_ID'),
            'secret' => env('AWS_SECRET_ACCESS_KEY'),
            'region' => env('AWS_DEFAULT_REGION', 'ap-northeast-1'),
            'table' => env('DYNAMODB_CACHE_TABLE', 'cache'),
            'endpoint' => env('DYNAMODB_ENDPOINT'),
        ],
        ...
];

.env の CACHE_DRIVER をdynamodbに変更

CACHE_DRIVER=dynamodb

APIキーでスロットルするMiddlewareを作成

Illuminate\Routing\Middleware\ThrottleRequests を継承した ThrottleByApikey を作成し、handleの内容をオーバライド、必要な関数の追加

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Routing\Middleware\ThrottleRequests;
use RuntimeException;

Class ThrottleByApikey extends ThrottleRequests
{
    /**
     * Handle an incoming request. | override
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @param  int|string  $maxAttempts
     * @param  float|int  $decayMinutes
     * @param  string  $prefix
     * @return \Symfony\Component\HttpFoundation\Response
     *
     * @throws \Illuminate\Http\Exceptions\ThrottleRequestsException
     */
    public function handle($request, Closure $next, $maxAttempts = 60, $decayMinutes = 60, $prefix = '')
    {
        // APIキーがなければエラー
        if (empty($request->query('key'))) {
            return response("400 Bad Request. Missing API Key", 400)->header('Content-Type', 'text/plain');
        }

        // APIキー管理用のDynamoDBから最高試行回数を取得
        $maxAttempts = $this->getMaxAttemptsByDynamoDB($request);

        // 回数制限が-1 = 利用停止または不正なキーのためエラー
        if ($maxAttempts === -1) {
            return response("400 Bad Request. Invalid API Key", 400)->header('Content-Type', 'text/plain');
        }

        // APIキーからアクセス回数を管理するためのキーを発行する
        $key = $prefix . $this->resolveRequestSignature($request);

        if ($this->limiter->tooManyAttempts($key, $maxAttempts)) {
            $retryAfter = $this->getTimeUntilNextRetry($key);

            return response("400 Bad Request. Too Many Requests. Please retury after ${retryAfter} seconds", 400)->header('Content-Type', 'text/plain');
        }

        $this->limiter->hit($key, $decayMinutes * 60);

        $response = $next($request);

        return $this->addHeaders(
            $response, $maxAttempts,
            $this->calculateRemainingAttempts($key, $maxAttempts)
        );
    }


    /**
     * DynamoDB から APIキー ごとの回数制限を取得する
     *
     * @param  \Illuminate\Http\Request  $request
     * @return int
     */
    protected function getMaxAttemptsByDynamoDB($request)
    {
        $dynamodb = new \Aws\DynamoDb\DynamoDbClient([
            'version'  => '2012-08-10',
            'key' => env('AWS_ACCESS_KEY_ID'),
            'secret' => env('AWS_SECRET_ACCESS_KEY'),
            'region' => env('AWS_DEFAULT_REGION', 'ap-northeast-1'),
            'endpoint' => env('DYNAMODB_ENDPOINT'),
        ]);

        $result = $dynamodb->getItem([
            'TableName' => env('DYNAMODB_API_KEY_TABLE'),
            'Key' => [
                'key' => ['S' => $request->query('key')],
            ],
        ]);

        $maxAttempts = !is_null($result['Item']) ? $result['Item']['max_attempts']['N'] : -1;

        return (int) $maxAttempts;
    }

    /**
     * Resolve request signature. | Override
     *
     * @NOTE 回数を管理するテーブルのキーをAPIキーにする
     *
     * @param  \Illuminate\Http\Request  $request
     * @return string
     *
     * @throws \RuntimeException
     */
    protected function resolveRequestSignature($request)
    {
        if ($apiKey = $request->query('key')) {
            return sha1($apiKey);
        }

        throw new RuntimeException('Unable to generate the request signature. Route unavailable.');
    }
}

アプリケーションへの適用

上で作ったMiddlewareを app/Http/Kernel.php で割り当てます。

<?php

    protected $middlewareGroups = [
        ...
        'api' => [
            'throttle' => \App\Http\Middleware\ThrottleByApikey::class,
            'bindings',
        ],
        ...
    ];

参考

Laravel / ThrottleRequests の云々とかオーバーライドとか｜開発室ブログ｜株式会社アクセスジャパン
本実装を行うにあたり大変参考にさせていただきました。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T02:04:20+09:00

PHPStanによる静的解析をLaravelアプリケーションに導入するためにやったこと（レベル1編）

この記事はLaravel #2 Advent Calendar 2019の19日目です。
そして去年のアドベントカレンダーの記事の続きです。

PHPStanによる静的解析をLaravelアプリケーションに導入するためにやったこと

はじめに

弊社サービス「リネット¹」のLaravelアプリケーションのPHPStanをレベル1に上げました。
そのためにやったことについて書きます。

使用しているソフトウェアのバージョン

この記事で使用しているソフトウェアのバージョンは下記の通りです。

ソフトウェアバージョン

PHP 7.2.12

Laravel 5.5.44

PHPStan 0.10.5

Laravel 5 IDE Helper Generator 2.5.1

Laravel 5.6以上を使っている人は、この記事を読まずLarastanを使うのが良いと思います。
Larastanを使えばこの記事でやっているようなことを自分でやらなくて良いはずです。多分。

Laravel 5.5を使っている人には参考になると思います。

PHPStanのレベル1で検知できること

PHPStanをレベル1にすると、下記のことが検知可能になります。²

1. 存在しないマジックメソッドとマジックプロパティの呼び出し

2. 未定義の可能性がある変数の使用
if ($flag) {
    $hoge = 'hoge';
}
echo $hoge; // $flagの値次第で未定義の可能性がある
Variable $hoge might not be defined.
3. 存在しない定数の使用
date(w); // date('w')の間違い
Constant w not found.
4. 無駄なisset関数の使用
$hoge = 'hoge';
isset($hoge); // 常にtrueになるので無駄
Variable $hoge in isset() always exists and is not nullable.
1を除いては、検知されたら粛々と修正すればOKです。

しかし、1は誤検知が多いと思います。
Eloquentのマジックメソッド（findやwhere）が誤検知されてしまいますし、自分でマジックメソッドやマジックプロパティを使っている箇所も同様です。

マジックメソッドやマジックプロパティの存在をPHPStanに教える方法

1. エクステンションを書く

PHPStanにはエクステンションという機構があります。³
エクステンションを書くことで、マジックメソッドやマジックプロパティの存在をPHPStanに教えることができます。

リネットでは次のようなエクステンションを書いてみました。
これがベストな書き方なのかはまったく自信がありませんので参考程度でお願いします。
Eloquentモデルのメソッド・リフレクション用のエクステンション
<?php
declare(strict_types=1);

use Eloquent;
use Illuminate\Database\Eloquent\Model;
use PHPStan\Analyser\OutOfClassScope;
use PHPStan\Reflection\ClassReflection;
use PHPStan\Reflection\MethodReflection;
use PHPStan\Reflection\MethodsClassReflectionExtension;
use PHPStan\Type\ObjectType;

class EloquentModelMethodsClassReflectionExtension implements MethodsClassReflectionExtension
{
    public function hasMethod(ClassReflection $classReflection, string $methodName): bool
    {
        // 無限ループ防止
        if ($classReflection->getName() == Eloquent::class) {
            return false;
        }

        if (!$this->isEloquentModel($classReflection)) {
            return false;
        }

        return $this->findMethod($methodName) !== null;
    }

    public function getMethod(ClassReflection $classReflection, string $methodName): MethodReflection
    {
        assert($this->isEloquentModel($classReflection));
        $method = $this->findMethod($methodName);
        assert(null !== $method);

        return $method;
    }

    private function findMethod(string $methodName): ?MethodReflection
    {
        $type = new ObjectType(Eloquent::class);

        if (!$type->hasMethod($methodName)) {
            return null;
        }

        return $type->getMethod($methodName, new OutOfClassScope());
    }

    private function isEloquentModel(ClassReflection $classReflection): bool
    {
        $parents = $classReflection->getParents();

        foreach ($parents as $parent) {
            // \Illuminate\Database\Eloquent\ModelのサブクラスであればEloquentモデル
            if ($parent->getName() == Model::class) {
                return true;
            }
        }

        return false;
    }
}
リネットのクラスのメソッド・リフレクション用のエクステンション
<?php
declare(strict_types=1);

use PHPStan\Analyser\OutOfClassScope;
use PHPStan\Reflection\ClassReflection;
use PHPStan\Reflection\MethodReflection;
use PHPStan\Reflection\MethodsClassReflectionExtension;
use PHPStan\Type\ObjectType;

class LenetMethodsClassReflectionExtension implements MethodsClassReflectionExtension
{
    private $reflect = [
        // リフレクション元 => リフレクション先
        SomePresenter::class => SomeModel::class,
    ];

    public function hasMethod(ClassReflection $classReflection, string $methodName): bool
    {
        $reflectFrom = $classReflection->getName();
        $reflectTo = $this->reflect[$reflectFrom] ?? null;

        if (is_null($reflectTo)) {
            return false;
        }

        return $this->findMethod($methodName, $reflectTo) !== null;
    }

    public function getMethod(ClassReflection $classReflection, string $methodName): MethodReflection
    {
        $reflectFrom = $classReflection->getName();
        assert(isset($this->reflect[$reflectFrom]));
        $reflectTo = $this->reflect[$reflectFrom];

        $method = $this->findMethod($methodName, $reflectTo);
        assert(null !== $method);

        return $method;
    }

    private function findMethod(string $methodName, string $reflectTo): ?MethodReflection
    {
        $type = new ObjectType($reflectTo);

        if (!$type->hasMethod($methodName)) {
            return null;
        }

        return $type->getMethod($methodName, new OutOfClassScope());
    }
}
2. PHPDocコメントを書く

PHPStanはPHPDocコメントを理解します。
エクステンションではなくPHPDocコメントでマジックメソッドやマジックプロパティの存在を教えることもできます。

リネットではPHPで列挙型(enum)を作るで紹介されている列挙型を利用させてもらっていますが、列挙型のファクトリメソッドについては列挙可能なのでPHPDocコメントを書いています。
<?php
declare(strict_types=1);

/**
 * @method static self irui()
 * @method static self futon()
 * @method static self hokan()
 * @method static self kutsu()
 */
class ServiceCode
{
    use EnumTrait;

    private const ENUM = [
        'irui'  => '1',
        'futon' => '2',
        'hokan' => '3',
        'kutsu' => '5',
    ];
}
こちらのブログにはエクステンションで対応する方法が紹介されていました。
https://medium.com/@hatajoe/how-to-use-phpstan-940ba1de6832

まとめ

Laravel 5.5のアプリケーションのPHPStanをレベル1に上げるためにやったことを書きました。
レベル2に上げる頃にはリネットもLaravel 6になっていると思うので、Larastanを使っていると思います。多分。

「宅配クリーニングの『リネット』」「クリーニング×保管の『リネット保管」「布団クリーニングの『ふとんリネット』」「靴クリーニングの『くつリネット』」の4サービス。 ↩

ソースコードを読む限りそう見えますが、間違っているかもしれません。ドキュメントがほしい。 ↩

https://github.com/phpstan/phpstan#extensibility ↩

ソフトウェア	バージョン
PHP	7.2.12
Laravel	5.5.44
PHPStan	0.10.5
Laravel 5 IDE Helper Generator	2.5.1

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T00:35:00+09:00

バリデーションエラー/POST送信時のLaravelの挙動を追う

本記事はうるる Advent Calendar 2019 19日目の記事です。

はじめに

Laravelでは、フォームリクエストにルールを定義することで、フォームバリデーションを容易に作成することができます。

バリデーションに引っかかった場合、エラー内容はフラッシュメッセージとしてセッションに保存され、ビューテンプレート上に表示させることができます。（あるいは、AJAXリクエストが使用されている場合はステータスコード422が返却されます）

この時、Laravelの裏側で起きている中身については、書籍や記事などの情報が少なかったので、調査してみました。

サンプル

ごく単純なフォーム送信を、サンプルコードとして扱います。
フォームのname属性としてはname・numberを要素に持ち、それぞれに対してバリデーションルールを設定しています。
また、バリデーションルールは今回はフォームリクエストに定義しています。
<?php

namespace App\Http\Controllers\Vali;

use App\Http\Controllers\Controller;
use App\Http\Requests\ValidateRequest;

class ValidatesController extends Controller
{
    public function index()
    {
        if ($this->sessionExists()) {
            session()->forget(['name', 'number']);
        }
        return view('validateForm');
    }

    public function store(ValidateRequest $request)
    {
        session([
            'name' => $request->input('name'),
        ]);
        session([
            'number' => $request->input('number'),
        ]);
        return redirect()->route('validateSuccess');
    }

    public function show()
    {
        if (! $this->sessionExists()) {
            return redirect()->route('validate');
        }
        return view('validateSuccess', [
            'name' => session('name'),
            'number' => session('number')
        ]);
    }

    private function sessionExists(): bool
    {
        return (session()->exists('name') || session()->exists('number'));
    }
}
<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class ValidateRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => 'required',
            'number' => 'required|integer',
        ];
    }
}
テンプレートとしては、フォーム入力時（validateForm.blade.php）・バリデーション通過後（validateSuccess.blade.php）の2種類を用意しています。
（bodyタグ以下のみ記載）
<body>
    <div>
        <h2>フォーム</h2>
        <p>内容を入力してください</p>
    </div>
    <div>
        <form action="{{ route('validateStore') }}" method="post">
            {{ csrf_field() }}
            <div>
                <label for="name">名前：</label><br>
                <input type="text" name="name" size="30">
            </div>
            <div>
                <label for="kind">数値：</label><br>
                <input type="number" name="number">
            </div>
            <div>
                <input type="submit" value="送信">
            </div>
        </form>
    </div>
    <div>
        @if(count($errors) > 0)
            {{ $errors }}
        @endif
    </div>
</body>
<body>
    <div>
        <h2>バリデーション成功</h2>
        <p>{{ $name }}</p>
        <p>{{ $number }}</p>
    </div>
</body>
ルーティングは、下記の3つを用意しています。
Route::get('validate', 'Vali\ValidatesController@index')->name('validate');

Route::post('validate', 'Vali\ValidatesController@store')->name('validateStore');

Route::get('success', 'Vali\ValidatesController@show')->name('validateSuccess');
処理の動きとしては、下記のようになります。

【フォーム入力時】

【バリデーション成功時】

【バリデーション失敗時（フォームに何も入力しなかった場合）】

これらの一連の処理について、内部で何が起きているのかを順に説明していきます。

バリデーションエラー/POST送信時の内部の動きを追う

リクエストはどこへ行くのか

送信されたHTTPリクエストは、エントリポイントであるpublic/index.phpで最初の処理が行われます。これはLaravelのライフサイクルの話です。public/index.phpは、下記のような記述がなされているファイルです。（コメントは省略）
<?php

define('LARAVEL_START', microtime(true));

require __DIR__.'/../vendor/autoload.php';

$app = require_once __DIR__.'/../bootstrap/app.php';

$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

$response->send();

$kernel->terminate($request, $response);
上記の中で、HTTPリクエストはIlluminate\Http\Request::capture()の部分でRequestオブジェクトが生成されます。そこで、このメソッドの記述をみてみます。
/**
 * Create a new Illuminate HTTP request from server variables.
 *
 * @return static
 */
public static function capture()
{
    static::enableHttpMethodParameterOverride();

    return static::createFromBase(SymfonyRequest::createFromGlobals());
}
上記は、Illuminate\Http\Requestクラスに定義されています。この記述だけだと、何が起きているのか分かりません。この処理の実体は、Illuminate\Http\Requestクラスが継承しているSymfony\Component\HttpFoundation\Requestクラスにあります。
/**
 * Creates a new request with values from PHP's super globals.
 *
 * @return static
 */
public static function createFromGlobals()
{
    $request = self::createRequestFromFactory($_GET, $_POST, [], $_COOKIE, $_FILES, $_SERVER);

    if (0 === strpos($request->headers->get('CONTENT_TYPE'), 'application/x-www-form-urlencoded')
        && \in_array(strtoupper($request->server->get('REQUEST_METHOD', 'GET')), ['PUT', 'DELETE', 'PATCH'])
    ) {
        parse_str($request->getContent(), $data);
        $request->request = new ParameterBag($data);
    }

    return $request;
}
ここで、createRequestFromFactory()の引数として、スーパーグローバル変数が渡されていることが分かります。この部分で、HTTPリクエスト情報がLaravelに渡されています。
そして、createRequestFromFactory()によって同クラスのインスタンスとして、各プロパティに格納されます。
private static function createRequestFromFactory(array $query = [], array $request = [], array $attributes = [], array $cookies = [], array $files = [], array $server = [], $content = null)
{
    if (self::$requestFactory) {
        $request = (self::$requestFactory)($query, $request, $attributes, $cookies, $files, $server, $content);

        if (!$request instanceof self) {
            throw new \LogicException('The Request factory must return an instance of Symfony\Component\HttpFoundation\Request.');
        }

        return $request;
    }

    return new static($query, $request, $attributes, $cookies, $files, $server, $content);
}
例えば、バリデーション時に参照されるPOSTリクエストの値については、同ファイルのプロパティである$requestに情報が格納されます。（厳密には、Symfony\Component\HttpFoundation\ParameterBagクラスに引き渡されています）

バリデーションはどこで行われているのか

続いて、実際にバリデーションロジックを実行している箇所です。

今回はフォームリクエストを利用していますが、その際には下記のIlluminate\Foundation\Providers\FormRequestServiceProviderの処理が動きます。
public function boot()
{
    $this->app->afterResolving(ValidatesWhenResolved::class, function ($resolved) {
        $resolved->validateResolved();
    });

    $this->app->resolving(FormRequest::class, function ($request, $app) {
        $request = FormRequest::createFrom($app['request'], $request);

        $request->setContainer($app)->setRedirector($app->make(Redirector::class));
    });
}
まず、FormRequest::classのインスタンス（フォームリクエストは継承している親クラスのインスタンス）が生成された直後に、resolvingメソッドの第2引数のクロージャが実行されます。
ここでは、Illuminate\Http\RequestクラスのcreateFromメソッドによって、リクエストインスタンスが生成されます。

そして、resolvingメソッドの実行後にafterResolvingメソッドが実行されますが、こちらでは第1引数であるValidatesWhenResolvedクラスのインスタンス生成が終わった直後にクロージャが実行され、validateResolved()メソッドが実行されます。

validateResolved()メソッドは、Illuminate\Validation\ValidatesWhenResolvedTraitに実体が記述されており、中身は下記のようになっています。
/**
* Validate the class instance.
*
* @return void
*/
public function validateResolved()
{
    $this->prepareForValidation();

    if (! $this->passesAuthorization()) {
        $this->failedAuthorization();
    }

    $instance = $this->getValidatorInstance();

    if ($instance->fails()) {
        $this->failedValidation($instance);
    }
}
この処理については、内部でより細かい処理が動いているので、分けて説明していきます。

Validatorクラスのインスタンスが作成されるまで

上記処理の中で、$instanceに格納される$this->getValidatorInstance()は、Illuminate\Foundation\Http\FormRequestに実体が記述されています。
/**
* Get the validator instance for the request.
*
* @return \Illuminate\Contracts\Validation\Validator
*/
protected function getValidatorInstance()
{
    if ($this->validator) {
        return $this->validator;
    }

    $factory = $this->container->make(ValidationFactory::class);

    if (method_exists($this, 'validator')) {
        $validator = $this->container->call([$this, 'validator'], compact('factory'));
    } else {
        $validator = $this->createDefaultValidator($factory);
    }

    if (method_exists($this, 'withValidator')) {
        $this->withValidator($validator);
    }

    $this->setValidator($validator);

    return $this->validator;
}
上記処理においては、Illuminate\Contracts\Validation\Validatorクラスのインスタンスが返却されています。
実際にインスタンスを作成しているのは、同じくFormRequestクラスに定義されている、createDefaultValidator()メソッドです。
/**
* Create the default validator instance.
*
* @param \Illuminate\Contracts\Validation\Factory $factory
* @return \Illuminate\Contracts\Validation\Validator
*/
protected function createDefaultValidator(ValidationFactory $factory)
{
    return $factory->make(
        $this->validationData(), $this->container->call([$this, 'rules']),
        $this->messages(), $this->attributes()
    );
}
ここで、$factory->make()の引数については、下記のようになっています（今回の処理の場合）
// $this->validationData()の返り値（フォームの入力値）
array: [
  "_token" => "省略"
  "name" => "hoge"
  "number" => null
]

// $this->container->call([$this, 'rules’])の返り値（バリデーションルール）
// フォームリクエストに定義した関数rule()の、returnによる返却値が返される。
array: [
  "name" => "required"
  "number" => "required|integer"
]

// $this->messages()・$this->attributes()は、空配列が返却される
array: []
今回の場合、フォームのname属性の各要素に対する入力値の情報が$this->validationData()によって渡され、それぞれ定義したバリデーションルールが$this->container->call([$this, 'rules’])によって渡されていることが分かります。
フォームの入力値については、$this->validationData()内部で、リクエストインスタンスをall()で取得する処理によって中身が取得されています。
バリデーションルールは現時点では、フォームリクエストに記述したそのままの形が返却されています。

上記の引数が渡された$factory->make()メソッドは、Illuminate\Validation\Factoryクラスに実体が記述されています。その中でも実処理が行われているのは、同クラスに定義されているresolve()メソッドです。
/**
 * Resolve a new Validator instance.
 *
 * @param  array  $data
 * @param  array  $rules
 * @param  array  $messages
 * @param  array  $customAttributes
 * @return \Illuminate\Validation\Validator
 */
protected function resolve(array $data, array $rules, array $messages, array $customAttributes)
{
    if (is_null($this->resolver)) {
        return new Validator($this->translator, $data, $rules, $messages, $customAttributes);
    }

    return call_user_func($this->resolver, $this->translator, $data, $rules, $messages, $customAttributes);
}
上記によって、Validatorクラスのインスタンスが作成されます。
実際に作成されるインスタンスは、下記のような情報を含んでいます。
Validator {
  ...
  #failedRules: []
  #messages: null
  #data: array: [
    "_token" => "省略"
    "name" => "hoge"
    "number" => null
  ]
  #initialRules: array: [
    "name" => "required"
    "number" => "required|integer"
  ]
  #rules: array: [
    "name" => array:1 [
      0 => "required"
    ]
    "number" => array: [
      0 => "required"
      1 => "integer"
    ]
  ]
...
}
この時、

フォームのname属性の要素名

フォームの入力値

それぞれに設定されたルール（バリデーション）

という3つの情報が含まれていることに着目してください。

バリデーション処理が実行される箇所

バリデーションインスタンスによって、バリデーションインスタンスが作成される処理までを見てきました。
再度、バリデーション処理の本体であるvalidateResolved()メソッドに話を戻します。
public function validateResolved()
{
    $this->prepareForValidation();

    if (! $this->passesAuthorization()) {
        $this->failedAuthorization();
    }

    $instance = $this->getValidatorInstance();

    if ($instance->fails()) {
        $this->failedValidation($instance);
    }
}
$instance->fails()によって、条件分岐構文に処理が移されています。fails()は、Illuminate\Validation\Validatorクラスに定義されたメソッドです。
/**
* Determine if the data fails the validation rules.
*
* @return bool
*/
public function fails()
{
    return ! $this->passes();
}
処理を見ると、$this->passes()の真偽値を返却しているようです。そこで、同クラスに定義されたpasses()の中身を見てみます。
/**
* Determine if the data passes the validation rules.
*
* @return bool
*/
public function passes()
{
    $this->messages = new MessageBag;

    [$this->distinctValues, $this->failedRules] = [[], []];

    // We'll spin through each rule, validating the attributes attached to that
    // rule. Any error messages will be added to the containers with each of
    // the other error messages, returning true if we don't have messages.
    foreach ($this->rules as $attribute => $rules) {
        $attribute = str_replace('\.', '->', $attribute);

        foreach ($rules as $rule) {
            $this->validateAttribute($attribute, $rule);

                if ($this->shouldStopValidating($attribute)) {
                    break;
                }
        }
    }


    // Here we will spin through all of the "after" hooks on this validator and
    // fire them off. This gives the callbacks a chance to perform all kinds
    // of other validation that needs to get wrapped up in this operation.
    foreach ($this->after as $after) {
        call_user_func($after);
    }

    return $this->messages->isEmpty();
}
処理を見ると、$this->messagesの有無によって、真偽値を返却していることが分かります。
$this->messagesには、バリデーションに引っかかった際のエラーメッセージが格納されていきます。
つまり、エラーメッセージの有無によって、trueを返すかfalseを返すかが分かれているのです。

もう少し処理を詳しく見ていくと、どうやら$this->rulesを展開しているforeach構文の中で、実際にバリデーションロジックの処理が行われていることが分かります。
ここで、$rulesというのはValidatorクラスのプロパティになります。$rulesの中身としては、先ほどみたValidatorインスタンスの「rules」と同値になります。
array: [
  "name" => array:1 [
    0 => "required"
  ]
  "number" => array:2 [
    0 => "required"
    1 => "integer"
  ]
]
そのため、foreach構文の中においては、$attributeがフォームのname属性の各要素名を表し、$rulesがそれに対して設定されたバリデーションルールを示すこととなります。

validateAttribute()メソッドの中身

foreach構文の中で、実際にバリデーション処理が実行されているのは$this->validateAttribute($attribute, $rule)の部分です。
/**
 * Validate a given attribute against a rule.
 *
 * @param  string  $attribute
 * @param  string  $rule
 * @return void
 */
protected function validateAttribute($attribute, $rule)
{
    $this->currentRule = $rule;

    [$rule, $parameters] = ValidationRuleParser::parse($rule);

    if ($rule == '') {
        return;
    }

    // First we will get the correct keys for the given attribute in case the field is nested in
    // an array. Then we determine if the given rule accepts other field names as parameters.
    // If so, we will replace any asterisks found in the parameters with the correct keys.
    if (($keys = $this->getExplicitKeys($attribute)) &&
        $this->dependsOnOtherFields($rule)) {
        $parameters = $this->replaceAsterisksInParameters($parameters, $keys);
    }

    // input value to form
    $value = $this->getValue($attribute);

    // If the attribute is a file, we will verify that the file upload was actually successful
    // and if it wasn't we will add a failure for the attribute. Files may not successfully
    // upload if they are too large based on PHP's settings so we will bail in this case.
    if ($value instanceof UploadedFile && ! $value->isValid() &&
        $this->hasRule($attribute, array_merge($this->fileRules, $this->implicitRules))
    ) {
        return $this->addFailure($attribute, 'uploaded', []);
    }

    // If we have made it this far we will make sure the attribute is validatable and if it is
    // we will call the validation method with the attribute. If a method returns false the
    // attribute is invalid and we will add a failure message for this failing attribute.
    $validatable = $this->isValidatable($rule, $attribute, $value);

    if ($rule instanceof RuleContract) {
        return $validatable
                ? $this->validateUsingCustomRule($attribute, $value, $rule)
                : null;
    }

    $method = "validate{$rule}";

    if ($validatable && ! $this->$method($attribute, $value, $parameters, $this)) {
        $this->addFailure($attribute, $rule, $parameters);
    }
}
処理が長いため、重要な箇所だけ抜粋して取り上げていきます。
まず、処理内において、同クラスに定義されたgetValue()メソッドによって、フォームの入力値が取得されます。
// input value to form
// $attribute: フォームのname属性の要素名
$value = $this->getValue($attribute);
続いて、こちらも同クラスに定義されたisValidatable()メソッドによって、バリデーション可能かどうかを判定しています。返り値では真偽値が返却されます。
// If we have made it this far we will make sure the attribute is validatable and if it is
// we will call the validation method with the attribute. If a method returns false the
// attribute is invalid and we will add a failure message for this failing attribute.
// $rule: バリデーションルール
// $attribute: フォームのname属性の要素名
// $value: フォームの入力値
$validatable = $this->isValidatable($rule, $attribute, $value);
この時$ruleが、フォームリクエストに設定したバリデーションルールを表していることに着目してください。今回の実装ではたとえば、formのname要素に対して「required」のルールを付与していました。

処理が煩雑になっているので深くは追いませんが、上記の「required」は、処理内でValidationRuleParser::parse($rule)に引き渡されることにより、「Required」という形に変換されます。そして、変数$methodに、下記のように格納されます。
$method = "validate{$rule}";
上記で返却されるメソッド名は、validateRequiredになります。

バリデーション実部分

さて、いよいよバリデーション実部分です。
バリデーション処理は、下記の箇所で行われます。
if ($validatable && ! $this->$method($attribute, $value, $parameters, $this)) {
    $this->addFailure($attribute, $rule, $parameters);
}
上記の$this->$methodでは、整形されたメソッド名（例では「validateRequired」）です。それでは、このメソッド名はどこから呼び出されているのかというと、Validatorクラスの冒頭でuseしている、Illuminate\Validation\Concerns\ValidatesAttributesトレイトになります。
/**
 * Validate that a required attribute exists.
 *
 * @param  string  $attribute
 * @param  mixed   $value
 * @return bool
 */
public function validateRequired($attribute, $value)
{
    if (is_null($value)) {
        return false;
    } elseif (is_string($value) && trim($value) === '') {
        return false;
    } elseif ((is_array($value) || $value instanceof Countable) && count($value) < 1) {
        return false;
    } elseif ($value instanceof File) {
        return (string) $value->getPath() !== '';
    }

    return true;
}
メソッド名として取得したvalidateRequired()が、定義されていることが分かります。
上記に限らず、Laravelのバリデーションルールとして定義された実処理は、ValidatesAttributesトレイトに記述されています。

たとえば、requireルールの場合、入力値（$value）が空欄の場合に、falseが返却されます。そうでなければtrueが返却されます。
その他のルールについても、ルールに合致していればtrueが返却され、ルールに合致していなければ（バリデーションに引っかかれば）falseが返される仕組みです。

エラーメッセージが付与される処理

上記メソッドの返り値がfalseだった場合、条件分岐構文によって、下記の処理が実行されます。
$this->addFailure($attribute, $rule, $parameters);
addFailure()メソッドの中で、$this->messageにバリデーションエラーメッセージを格納していきます。実際にこの処理が行われているのは、同メソッド内の下記の部分です。
$this->messages->add($attribute, $this->makeReplacements(
    $this->getMessage($attribute, $rule), $attribute, $rule, $parameters
));
たとえば、フォームのnumber要素にrequiredのルールを設定し、このバリデーションルールに引っかかった場合、デフォルト状態では「The number field is required.」のようなメッセージが返却されるかと思います。

これらのメッセージはどこに定義されているのかというと、resources/lang/en/validation.phpに、各バリデーションルールに応じた初期状態のエラーメッセージがまとめられています。

validation.phpにおいては、フォームの要素部分はプレースホルダで記述がされています。処理の中で、実際にバリデーションルールに引っかかった要素名が、各エラーメッセージに割り振られるというわけです。

エラーメッセージが付与された後

上記の処理によって、バリデーション失敗時に$this->messagesにエラーメッセージが格納されることで、Illuminate\Validation\Validatorクラスのメソッドpasses()はfalseを返却します。なぜなら、passes()は下記を返却するメソッドだからです。
return $this->messages->isEmpty();
passes()がfalseを返却すると、同クラスのメソッドfails()はtrueを返却します。そして、大元の処理であるvalidateResolved()メソッド（Illuminate\Validation\ValidatesWhenResolvedTraitでは、failedValidation()メソッドが実行されます。
public function validateResolved()
{
    $this->prepareForValidation();

    if (! $this->passesAuthorization()) {
        $this->failedAuthorization();
    }

    $instance = $this->getValidatorInstance();

    if ($instance->fails()) {
        $this->failedValidation($instance);
    }
}
長くなりましたが、ここまでがバリデーション実処理部分になります。

バリデーションエラーメッセージの出力

最後に、バリデーションに引っかかった際、どのような動きによってエラーメッセージが出力されるのか、ということについて見ていきます。

Laravelのドキュメントを見ると、バリデーションのエラーメッセージの出力に関しては以下のように説明されています。

Laravelは自動的にユーザーを以前のページヘリダイレクトします。付け加えて、バリデーションエラーは全部自動的にフラッシュデータとしてセッションへ保存されます。

Laravelドキュメント（日本語訳）

この部分について、内部ではどのような動きをしているのかを追っていきたいと思います。
まずは、エラーメッセージがセッションに保存される箇所からです。

バリデーションエラーがセッションに保存されるまで

上でも見たように、バリデーションに引っかかって$instance->fails() = falseが返却されると、failedValidation()メソッドが実行されます。これは、Illuminate\Foundation\Http\FormRequestクラスに定義されています。
/**
 * Handle a failed validation attempt.
 *
 * @param  \Illuminate\Contracts\Validation\Validator  $validator
 * @return void
 *
 * @throws \Illuminate\Validation\ValidationException
 */
protected function failedValidation(Validator $validator)
{
    throw (new ValidationException($validator))
                ->errorBag($this->errorBag)
                ->redirectTo($this->getRedirectUrl());
}
上記をみると、ValidationExceptionのエラーが投げられていることが確認できます。
そこで、エラーハンドルに関する記述がなされているIlluminate\Foundation\Exceptions\Handlerクラスの記述を見てみます。
今回の処理に関係している記述は、まずは下記です。
/**
 * Render an exception into a response.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Exception  $e
 * @return \Illuminate\Http\Response|\Symfony\Component\HttpFoundation\Response
 */
public function render($request, Exception $e)
{
    if (method_exists($e, 'render') && $response = $e->render($request)) {
        return Router::toResponse($request, $response);
    } elseif ($e instanceof Responsable) {
        return $e->toResponse($request);
    }

    $e = $this->prepareException($e);

    if ($e instanceof HttpResponseException) {
        return $e->getResponse();
    } elseif ($e instanceof AuthenticationException) {
        return $this->unauthenticated($request, $e);
    } elseif ($e instanceof ValidationException) {
        return $this->convertValidationExceptionToResponse($e, $request);
    }

    return $request->expectsJson()
                    ? $this->prepareJsonResponse($request, $e)
                    : $this->prepareResponse($request, $e);
}
ここで、elseif ($e instanceof ValidationException)の箇所に着目してください。バリデーションエラーが投げられた際はこちらの条件に該当し、convertValidationExceptionToResponse()メソッドが実行されていることが分かります。
protected function convertValidationExceptionToResponse(ValidationException $e, $request)
{
    if ($e->response) {
        return $e->response;
    }

    return $request->expectsJson()
                ? $this->invalidJson($request, $e)
                : $this->invalid($request, $e);
    }
convertValidationExceptionToResponse()メソッドは、上記のような記述のメソッドです。（説明は省略しています。）
この中で、今回の処理ではinvalid()が実行されます。
/**
 * Convert a validation exception into a response.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Illuminate\Validation\ValidationException  $exception
 * @return \Illuminate\Http\Response
 */
protected function invalid($request, ValidationException $exception)
{
    return redirect($exception->redirectTo ?? url()->previous())
                ->withInput(Arr::except($request->input(), $this->dontFlash))
                ->withErrors($exception->errors(), $exception->errorBag);
}
withErrors()メソッドに着目します。これは、Illuminate\Http\RedirectResponseクラスに定義されたメソッドで、下記のような記述になっています。
/**
 * Flash a container of errors to the session.
 *
 * @param  \Illuminate\Contracts\Support\MessageProvider|array|string  $provider
 * @param  string  $key
 * @return $this
 */
public function withErrors($provider, $key = 'default')
{
    $value = $this->parseErrors($provider);

    $errors = $this->session->get('errors', new ViewErrorBag);

    if (! $errors instanceof ViewErrorBag) {
        $errors = new ViewErrorBag;
    }

    $this->session->flash(
        'errors', $errors->put($key, $value)
    );

    return $this;
}
こちらの記述によって、エラーメッセージがフラッシュデータとして、セッションに保存されていることが分かるかと思います。$this->session->flash()の部分で、確かに「errors」をキーとして、セッションに保存されています。

また、$errors->put($key, $value)の箇所では、MessageBagインスタンスを内包するViewErrorBagクラスが返却されており、内部にバリデーションエラーメッセージが格納されています。

自動的にユーザーを以前のページヘリダイレクトする動きについて

続いて、バリデーションエラー発生時に自動的に以前のページへリダイレクトされる処理についてです。
再び、FormRequestクラスのfailedValidation()メソッドに着目してください。
protected function failedValidation(Validator $validator)
{
    throw (new ValidationException($validator))
                ->errorBag($this->errorBag)
                ->redirectTo($this->getRedirectUrl());
}
上記処理において、redirectTo()の箇所でリダイレクトするURLを設定しています。redirectTo()自体は、Illuminate\Validation\ValidationExceptionクラスのメソッドであり、こちらのクラスの$redirectToプロパティに、引数として渡されたURLを設定します。

そこで、引数部分の$this->getRedirectUrl()に着目します。こちらのメソッドは、FormRequestクラスに下記のように定義されています。
/**
 * Get the URL to redirect to on a validation error.
 *
 * @return string
 */
protected function getRedirectUrl()
{
    $url = $this->redirector->getUrlGenerator();

    if ($this->redirect) {
        return $url->to($this->redirect);
    } elseif ($this->redirectRoute) {
        return $url->route($this->redirectRoute);
    } elseif ($this->redirectAction) {
        return $url->action($this->redirectAction);
    }

    return $url->previous();
}
設定されたリダイレクトルートに応じて、返り値を振り分ける処理です。ただし以前のページに自動的にリダイレクトする動きの場合、一番最後に記述のあるprevious()メソッドが重要な役割を持ちます。previous()メソッドは、Illuminate\Routing\UrlGeneratorに定義されたメソッドです。
/**
 * Get the URL for the previous request.
 *
 * @param  mixed  $fallback
 * @return string
 */
public function previous($fallback = false)
{
    $referrer = $this->request->headers->get('referer');

    $url = $referrer ? $this->to($referrer) : $this->getPreviousUrlFromSession();

    if ($url) {
        return $url;
    } elseif ($fallback) {
        return $this->to($fallback);
    }

    return $this->to('/');
}
$this->request->headers->get('referer')の部分で、リクエストインスタンスより、Refererヘッダー情報を取得しています。この箇所によって、直前のページ（ここでは、フォーム送信が行われたページ）のURL情報が取得されます。

ページリダイレクトが行われている箇所

上記で、ValidationExceptionクラスの$redirectToプロパティに、直前のページのURLが設定されるまでの動きを見てきました。
最後に、実際にページリダイレクトが行われている処理についてです。再度、Illuminate\Foundation\Exceptionsクラスのinvalid()メソッドの処理を記します。
protected function invalid($request, ValidationException $exception)
{
    return redirect($exception->redirectTo ?? url()->previous())
                ->withInput(Arr::except($request->input(), $this->dontFlash))
                ->withErrors($exception->errors(), $exception->errorBag);
}
冒頭で、Laravelのヘルパ関数のredirect()が記述され、引数として$exception->redirectToが渡されていますね。$exception->redirectToには直前のページのURLが設定されていますから、このページURLにリダイレクトされることが分かります。

補足：ビューの$errorsにエラー情報の紐付けを行う箇所

補足的にはなりますが、セッションにフラッシュメッセージとして保存されたバリデーションエラーを、ビューの$errorsに紐付ける処理については、Illuminate\View\Middleware\ShareErrorsFromSessionクラスのhandle()メソッド内で行われています。
/**
 * Handle an incoming request.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Closure  $next
 * @return mixed
 */
public function handle($request, Closure $next)
{
    // If the current session has an "errors" variable bound to it, we will share
    // its value with all view instances so the views can easily access errors
    // without having to bind. An empty bag is set when there aren't errors.
    $this->view->share(
         'errors', $request->session()->get('errors') ?: new ViewErrorBag
    );

    // Putting the errors in the view for every view allows the developer to just
    // assume that some errors are always available, which is convenient since
    // they don't have to continually run checks for the presence of errors.

    return $next($request);
}
確かに、$this->view->share()の部分で、セッションから'errors'のデータが取得されていることが分かります。

ざっとまとめると

少し長くなってしまいましたが、バリデーション時の挙動をざっとまとめてしまうと、

バリデーションルールごとの判定メソッドを実行し

引っかかれば、エラーメッセージに格納し

エラーメッセージがあれば、バリデーションエラーを投げる

といった動きをしていることが分かりました。

　 Tweet
Qiitaで続きを読む

20191219のlaravelに関する記事は7件です。

【 Eagerロード】コメントと、コメントに対する返信について、それぞれユーザー名を取得したい

【 Eagerロード 】コメント＆コメントに対する返信について、それぞれユーザー名を別テーブルから取得したい

今回はハマったポイントを共有

前提

リレーションの設定

コントローラー

参照

反省

Laravel で Rails の抽象 ActiveModel みたいなやつが欲しくなった

TL;DR

内容

機能制約

既存のライブラリ

【Laravel】イベントとリスナーの関係について整理する

イベントとリスナーの関係性

イベントとリスナーの書き方

イベントからリスナーが発動するまでの流れ

イベントとリスナーの使いみち

PHP7.4対応版Laradockを、ビルドしただけの話（2019/12/17時点）

始めに

各コンテナをビルドする際に変更したファイルと変更箇所

1. mysql/my.cnf

2. php-fpm/Dockerfile

3. php-worker/Dockerfile

追伸1

追伸2

Laravel 6.3 で リクエストのAPIキーへの検証・スロットリングをする

やりたいこと

環境

Illuminate\Routing\Middleware\ThrottleRequests について

設定箇所

具体的な処理

やってみる

方針

実装

準備

キャッシュにDynamoDBを使う

APIキーでスロットルするMiddlewareを作成

アプリケーションへの適用

参考

PHPStanによる静的解析をLaravelアプリケーションに導入するためにやったこと（レベル1編）

はじめに

使用しているソフトウェアのバージョン

PHPStanのレベル1で検知できること

1. 存在しないマジックメソッドとマジックプロパティの呼び出し

2. 未定義の可能性がある変数の使用

3. 存在しない定数の使用

4. 無駄なisset関数の使用

マジックメソッドやマジックプロパティの存在をPHPStanに教える方法

1. エクステンションを書く

2. PHPDocコメントを書く

まとめ

バリデーションエラー/POST送信時のLaravelの挙動を追う

はじめに

サンプル

バリデーションエラー/POST送信時の内部の動きを追う

リクエストはどこへ行くのか

バリデーションはどこで行われているのか

Validatorクラスのインスタンスが作成されるまで

バリデーション処理が実行される箇所

validateAttribute()メソッドの中身

バリデーション実部分

エラーメッセージが付与される処理

エラーメッセージが付与された後

バリデーションエラーメッセージの出力

バリデーションエラーがセッションに保存されるまで

自動的にユーザーを以前のページヘリダイレクトする動きについて

ページリダイレクトが行われている箇所

補足：ビューの$errorsにエラー情報の紐付けを行う箇所

ざっとまとめると

日付別

タグ一覧

【 Eagerロード】コメント＆コメントに対する返信について、それぞれユーザー名を別テーブルから取得したい

Laravel 6.3 でリクエストのAPIキーへの検証・スロットリングをする