L6.x on ララジャパン

DNSを使ってメールアドレスをチェック

Sun, 09 Jan 2022 01:43:32 +0900

「お客さんにメールが届かないのでどうかして？」というＣＳからの質問。見てみるとexample@yahoo.comであるところ、example@yahpo.comになっていたりします。たった１文字違いですが、会員登録してもこのためにメールが届かないばかりか、次回からは多分ログインもできません。もちろんお客さんの間違いですが、登録時にこれが通ってしまうというのは問題です。これをどうかしたいです。

緩いメールアドレスのバリデーション

Laravelのデフォルトのメールアドレスのバリデーションemailは、結構緩いです。どれだけ緩いが実例見てみましょう。以下は、tinkerを使って、test@gmailという不正なメールアドレスチェックします。

>>> $v = validator(['email' => 'test@gmail'], ['email' => 'required|email'])
=> Illuminate\Validation\Validator {#3534
     +customMessages: [],
     +fallbackMessages: [],
     +customAttributes: [],
     +customValues: [],
     +excludeUnvalidatedArrayKeys: null,
     +extensions: [],
     +replacers: [],
   }
>>> $v->passes()
=> true

あっさり、通ってしまいます。

また、example.comとかのドメイン名は実在しないのに、これも通ります。

>>> $v = validator(['email' => 'test@example.com'], ['email' => 'required|email'])
...
>>> $v->passes()
=> true

email:dnsの登場

メールアドレスの＠マークの後ろの部分、例えば、test@example.comなら、example.comの部分、はドメイン名と言ってインターネットでは非常に重要なデータなのですが、このドメインが実在するかどうか、そしてメールを受け取るかどうかがわかれば、少なくともメールアドレスのタイポは登録時に警告できますね。

それを利用したのが、email:dnsのバリデーションルールです。早速、tinkerで試してみましょう。

>>> $v = validator(['email' => 'test@gmail'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

>>> $v = validator(['email' => 'test@example.com'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

>>> $v = validator(['email' => 'test@yahpo.com'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

素晴らしいです、みな通りません！

email:dnsの使用において注意が必要なのは、それを利用するには、以下の国際化関数、intlのライブラリが必要です。 https://www.php.net/manual/ja/book.intl.php

dns_get_record()

ちょっとemail:dnsの仕組みを探ってみましょう。Laravelのマニュアルによると、egulias/email-validatorのパッケージを使用しているそうな。そこから関心のコードの一部を掲載します。

https://github.com/egulias/EmailValidator/blob/3.x/src/Validation/DNSCheckValidation.php

...
class DNSCheckValidation implements EmailValidation
{
    /**
     * @var int
     */
    protected const DNS_RECORD_TYPES_TO_CHECK = DNS_MX + DNS_A + DNS_AAAA;

    /**
     * Reserved Top Level DNS Names (https://tools.ietf.org/html/rfc2606#section-2),
     * mDNS and private DNS Namespaces (https://tools.ietf.org/html/rfc6762#appendix-G)
     */
    const RESERVED_DNS_TOP_LEVEL_NAMES = [ //これらのドメイン名はみなエラーとなります
        // Reserved Top Level DNS Names
        'test',
        'example',
        'invalid',
        'localhost',

        // mDNS
        'local',

        // Private DNS Namespaces
        'intranet',
        'internal',
        'private',
        'corp',
        'home',
        'lan',
    ];
   ...

 private function validateDnsRecords($host) : bool
    {
        // A workaround to fix https://bugs.php.net/bug.php?id=73149
        /** @psalm-suppress InvalidArgument */
        set_error_handler(
            static function (int $errorLevel, string $errorMessage): ?bool {
                throw new \RuntimeException("Unable to get DNS record for the host: $errorMessage");
            }
        );

        try {
            // Get all MX, A and AAAA DNS records for host
            $dnsRecords = dns_get_record($host, static::DNS_RECORD_TYPES_TO_CHECK);
        } catch (\RuntimeException $exception) {
            $this->error = new InvalidEmail(new UnableToGetDNSRecord(), '');

            return false;
        } finally {
            restore_error_handler();
        }
...

上の４５行目見てください。dns_get_record()なるphp関数があったのですね。 https://www.php.net/manual/ja/function.dns-get-record.php

上の説明によると、こんなしてドメイン情報取得できるようです。

>>> dns_get_record("yahpo.com", DNS_MX);
=> [
     [
       "host" => "yahpo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 0,
       "target" => "",
     ],
   ]
>>> dns_get_record("yahoo.com", DNS_MX);
=> [
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta5.am0.yahoodns.net",
     ],
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta6.am0.yahoodns.net",
     ],
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta7.am0.yahoodns.net",
     ],
   ]

最初のタイポのドメイン名のtargetは存在しないけれど、正式なドメインは３つtargetを返しています。Laravelのemail:dnsはこれを利用しているのですね。

最後に

メールのバリデーションには、email:dnsの他にもrfcとかstrictとかspoofとかあります。 emailとemail:rfcは同じです。また、email:rfc,dnsとように合わせての使用も可能です。

あと大事なのは、バリデーションでは必ず弾かれてしまうが、test.@docomo.ne.jpのようにドットが不正な場所にあるにもかかわらず実在するメールアドレスの対応です。docomo.ne.jpやezweb.ne.jpではその不正を許す必要あります。まだ使っている人いるんですよ。

Laravel 7.x更新で発見したこと（3）ルートのキャッシュ

Sun, 21 Mar 2021 04:16:59 +0900

Laravelはプログラム実行において読み込むファイルの数は非常に多いです。実行速度を最適化するにはいろいろな方法がありますが、一番簡単に実行できる方法があります。遠い昔にも紹介しましたが、ルートのキャッシュです。しかし、バージョン７への更新によりちょっと問題が発生です。

ルートのキャッシュ

お客さんのプロジェクトでは、routes/web.phpやapi.phpで定義されているルート（routeのことです）は結構あります。現在445あります。毎回毎回これを読み込みLaravelが処理するにはシステムに負荷がかかります。Laravelでは以前から、それを最適化してキャッシュするコマンドがあります。

まず、L7.xでプロジェクトを作成して、その時点で動作確認したところで、ルートをキャッシュしまするのですが、

その前にちょっとした作業が必要です。なぜなら、そのキャッシュのコマンドはクロージャのルートでエラーとなってしまうからです。それはL6.xでも同じことです。

ということで、以下の２つのファイルにおいてコメントアウトが必要です。

routes/api.php

...
// 以下コメントアウト
// Route::middleware('auth:api')->get('/user', function (Request $request) {
//    return $request->user();
// });

routes/web.php

...
// 以下コメントアウト
// Route::get('/', function () {
//    return view('welcome');
//});

Auth::routes();

Route::get('/home', 'HomeController@index')->name('home');

これでルートのキャッシュ化のコマンドを実行です。

$ php artisan route:cache
Route cache cleared!
Routes cached successfully!

成功しましたね。そしてディレクトリには以下のように、

bootstrap/cache
├── packages.php
├── routes-v7.php
└── services.php

キャッシュされたroutes-v7.phpのファイルが作成されています。L6.xではファイル名は、routes.phpでした。

重複のルート名はL6.xではOKだったのに

L7.xになってこのコマンドの実行において前バージョンから１つ変わったことあります。L6.xにおいては、ルート名の重複が許されていたのですが、L7.xではそれが許されません。比較してみましょう。

まず、L6.xの環境で、以下のようなルートの設定をします。

routes/web.php

// Route::get('/', function () {
//     return view('welcome');
// });

// Auth::routes(); // 左の関数から以下を抽出
Route::get('login', 'Auth\LoginController@showLoginForm')->name('login');
Route::post('login', 'Auth\LoginController@login')->name('login');

// Route::get('/home', 'HomeController@index')->name('home');

Auth::routes()で設定されているルートから、loginのルート定義を取り出して、意図的にgetとpostに同じloginという名前となるように設定します。->name(’login’)の部分です。

$ php artisan route:list

を実行すると、

+--------+----------+-------+-------+---------------------------------------------------------+------------+
| Domain | Method   | URI   | Name  | Action                                                  | Middleware |
+--------+----------+-------+-------+---------------------------------------------------------+------------+
|        | GET|HEAD | login | login | App\Http\Controllers\Auth\LoginController@showLoginForm | web,guest  |
|        | POST     | login | login | App\Http\Controllers\Auth\LoginController@login         | web,guest  |
+--------+----------+-------+-------+---------------------------------------------------------+------------+

そして、キャッシュのコマンドの実行もOKです。

$ php artisan route:cache
Route cache cleared!
Routes cached successfully!

重複のルート名でも、GETとPOSTと使用されるメソッドが違うので使用には問題がありませんでした。

以上は、L6.xでの話ですが、L7.xでは。。。

L7.xでの問題

L7.xにおいて、先と同じようにルートをweb.phpで設定して、

$ php artisan route:list

を実行すると、

+--------+----------+-------+-------+---------------------------------------------------------+------------+
| Domain | Method   | URI   | Name  | Action                                                  | Middleware |
+--------+----------+-------+-------+---------------------------------------------------------+------------+
|        | GET|HEAD | login | login | App\Http\Controllers\Auth\LoginController@showLoginForm | web        |
|        |          |       |       |                                                         | guest      |
|        | POST     | login | login | App\Http\Controllers\Auth\LoginController@login         | web        |
|        |          |       |       |                                                         | guest      |
+--------+----------+-------+-------+---------------------------------------------------------+------------+

OKそうですね。そして、キャッシュのコマンドを実行すると、

Route cache cleared!

   LogicException 

  Unable to prepare route [login] for serialization. Another route has already been assigned name [login].
...

と、「もうloginの名前は使われているよ」というエラーが表示されます。

そうなら、重複とならないようにルートの名前を変えてみます。

...
Route::get('login', 'Auth\LoginController@showLoginForm')->name('login');
Route::post('login', 'Auth\LoginController@login')->name('login-post');
...

今度はキャッシュのコマンドの実行はOKとなりました。

$ php artisan route:cache
Route cache cleared!
Routes cached successfully!

そして、今度はpostのルートの名前を外してみます。オリジナルの定義と同じです。

...
Route::get('login', 'Auth\LoginController@showLoginForm')->name('login');
Route::post('login', 'Auth\LoginController@login');
...

これでも、キャッシュのコマンドの実行は成功となります。

どうなっているのか？と以下を実行してみると、

$ php aritsan route:list
+--------+----------+-------+-----------------------------+---------------------------------------------------------+------------+
| Domain | Method   | URI   | Name                        | Action                                                  | Middleware |
+--------+----------+-------+-----------------------------+---------------------------------------------------------+------------+
|        | GET|HEAD | login | login                       | App\Http\Controllers\Auth\LoginController@showLoginForm | web        |
|        |          |       |                             |                                                         | guest      |
|        | POST     | login | generated::Jhj05XtQrWTdgVlP | App\Http\Controllers\Auth\LoginController@login         | web        |
|        |          |       |                             |                                                         | guest      |
+--------+----------+-------+-----------------------------+---------------------------------------------------------+------------+

名が無かったルートには、 generated::Jhj05XtQrWTdgVlPと自動で名前が付けられていました。便利ですね。

最後に

ルート名がそのキャッシュ化において重複を許さなくなったL7.xの更新は、既存のコードをブレイクするという報告がいくつか出ていました。もちろんこれにより私のプロジェクトでも変更がいくつか必要となりました。ここの部分更新時には注意要です。

それから、ルートのキャッシュでもうひとつ注意することは、ルートの定義ファイルを変更したら必ず、キャッシュコマンドを再実行する必要があります。

ときどきこれを忘れてどうして変更が反映していないのか考え込んでしまう経験が過去にありました。それゆえに私の開発環境ではキャッシュせずに、本環境のみにおいてキャッシュ化を実行するようにしています。

メンテナンス画面：php artisan up & down

Sun, 08 Nov 2020 05:10:45 +0900

Laravelの経験が長くなると、つまり初期のバージョンから使用していると、昔のやり方しか知らずに過ごしていることがあります。以前にメンテナンス画面の裏口のポストがありますが、それはバージョン5.1の話で、大昔です。ということでやり方学びなおします。

メンテンナンス画面

プログラムの更新をインストールしたり、データベースに変更をしたりするときは、誰にも作業中にアクセスしてもらいたくありません。そのときに、以下を実行します。

$ php artisan down

これを実行すると、アクセスしてきたら、以下のような画面が表示されます。それで安心して、プログラムを更新したり、データベースを変更したり、など好き勝手なことできます。

メンテナンスが完了したら、

$ php artisan up

を実行して、皆にアクセスできるようにします。

メンテンナンス画面にメッセージを表示したいなら、

$ php artisan down --message="メンテナンス中です。午前３時に終了します。"

と実行すると以下のように、メッセージが表示されます。

便利ですね。

私がアクセスしたい

メンテナンスの間、好き勝手なことをするのはいいのですが、私自身がサイトにアクセスできないと困ります。プログラムの更新をテストすることなどができません。

特定のIPアドレスからアクセスできるようにする、つまり裏口を作る必要あります。

ここが以前（古いLaravelのバージョン）と最近のバージョンが違うところです。

$ php artisan down --message="メンテナンス中です。午前３時に終了します。" --allow=192.168.56.1

のように、–allowの引数で自分のIPアドレスを指定するだけで、私にとってはアクセス可能となります。

さらに、毎回毎回コマンドラインで指定するのが面倒なら、以前のように

app/Http/Middleware/CheckForMaintenanceMode.php

namespace App\Http\Middleware;

use Closure;
use Symfony\Component\HttpFoundation\IpUtils;

use Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode as Middleware;

class CheckForMaintenanceMode extends Middleware
{
    /**
     * The URIs that should be reachable while maintenance mode is enabled.
     *
     * @var array
     */
    protected $except = [
    	//
    ];

    protected $allowed = [
    	'192.168.56.1'　// ここで許可するIPを登録
    ];

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     *
     * @throws \Symfony\Component\HttpKernel\Exception\HttpException
     * @throws \Illuminate\Foundation\Http\Exceptions\MaintenanceModeException
     */
    public function handle($request, Closure $next)
    {
        if ($this->app->isDownForMaintenance()) {

            if (IpUtils::checkIp($request->ip(), (array) $this->allowed)) {
                return $next($request);
            }
        }

        return parent::handle($request, $next);　// ここで親の関数を呼ぶ
    }
}

と編集します。

メンテナンス画面をカスタマイズしたいなら

メンテナンス画面をカスタマイズしたいなら、まず、以下を実行してブレードを作成します。

$ php artisan vendor:publish --tag=laravel-errors

resources/viewsのディレクトリにerrorsサブディレクトリが作成されて以下のファイルがコピーされます。

errors
├── 401.blade.php
├── 403.blade.php
├── 404.blade.php
├── 419.blade.php
├── 429.blade.php
├── 500.blade.php
├── 503.blade.php
├── illustrated-layout.blade.php
├── layout.blade.php
└── minimal.blade.php

メンテナンス画面のカスタマイズのために編集するファイル、503.blade.phpです。503は、Service Unavailable、つまり「サービスは利用できません」のウェブステータスです。

artisanのコマンドは実行できる？

最後に、メンテナンス中に、クロンで設定されているphp artisanのコマンドは実行されるかどうかですが、php aritsan upが実行できるのだからもちろん実行可能です。ということは、メンテナンス中においてクロンのサービスをいったん止めることも必要かもしれません。ご注意を。

abort()を使ってリダイレクト

Sat, 25 Jul 2020 00:01:46 +0900

Laravelのコントローラにおいて、abort(404)のヘルパーをコールすることで簡単に予期しないアクセスを、Not Foundのエラーページの表示ができます。しかし、Not Foundページの代わりにリダイレクトして違うページに飛ばしたいときには、redirect()のヘルパーをabort()同様に好きな場所で使うことはできません。

そう書いても何を言っているかわからないと思いますので、まず、商品（Product）の情報を閲覧するコントローラを使って、abort()とredirect()の紹介から。

abort()は以下のように単独でコードに配置します。

namespace App\Http\Controllers;

use App\Product;
use App\Http\Controllers\Controller;

class ProductController extends Controller
{
    public function show(Product $product)
    {
        if ($product->active_flag == 'N') { // 無効な商品なら、
    	    abort(404); // Not Foundページを表示
        }

        return view('user.product.show')->with(compact('product')); // 商品のページを表示
    }
}

しかし、redirect()は、以下のようにreturnが必要です。

...
class ProductController extends Controller
{
    public function show(Product $product)
    {
        if ($product->active_flag == 'N') { // 無効な商品なら、
    	    return redirect('home'); // ホームページにリダイレクト
        }

        return view('user.product.show')->with(compact('product')); // 商品のページを表示
    }
}

この違いは、abort()がHttp Exceptionをthrowするのに対して、redirect()は、\Illuminate\Http\RedirectResponseのオブジェクトを返すからです。

さて、上のコントローラを変更して、以下のように条件文を新規のメソッドに移します。現在の条件は簡単だけれど将来はたいそう複雑になるぞ、という仮定です。

...
class ProductController extends Controller
{
    public function show(Product $product)
    {
        $this->checkProduct($product); // 条件文が複雑になるので新規の関数を作成

        return view('user.product.show')->with(compact('product')); // 商品のページを表示
    }

    private function checkProduct($product)
    {
        if ($product->active_flag == 'N') { // 無効な商品なら、
    	    return redirect('home'); // ホームページにリダイレクト
        }
    }
}

一見たわいもない変更ですが、これを実行すると、なんと無効である商品の表示ページが表示されます。ホームページにリダイレクトはされません。問題は、checkProduct()がRedirectResponseを返すのに、コールした側でreturnが使用されていないからなのですね。

しかし、

...
class ProductController extends Controller
{
    public function show(Product $product)
    {
        return $this->checkProduct($product);

        return view('user.product.show')->with(compact('product')); // 商品のページを表示
...

こうすると、商品が有効なときもそこでリターンするために商品のページが表示されずに問題です。さてさて、どうしたらよいでしょう？

ということで、あれこれ調べていたら、abort()を使用してリダイレクトが可能なことがわかりました。以下のように、abort()の引数に404のようなHttpステータスのコードの代わりにredirect()を渡すことが可能なのです。以下が変更後のコードです。素晴らしい！

...
class ProductController extends Controller
{
    public function show(Product $product)
    {
        $this->checkProduct($product); // 条件文が複雑になるので新規の関数を作成

        return view('user.product.show')->with(compact('product')); // 商品のページを表示
    }

    private function checkProduct($product)
    {
        if ($product->active_flag == 'N') { // 無効な商品なら、
    	    abort(redirect('home')); // ホームページにリダイレクト
        }
    }
}

Laravel 6.xのインストール

Sat, 18 Jul 2020 06:23:09 +0900

最新のLaravelはバージョン7.xですが、バージョン6.xは以下の表に見られるように２年間のサポート(LTS)があります。管理を頻繁に行う必要がないなら、新規のプロジェクトでは6.xバージョンをインストールするのが良いです。ということで、久しぶりに初心に戻ってLaravelのプロジェクトの作成手順を書きます。

新規プロジェクトの作成

composerはすでにシステムにインストールされていると仮定して、以下のコマンドがl6xのディレクトリ名でLaravelをインストールします。

$ composer create-project --prefer-dist laravel/laravel l6x "6.*"

ウェブサーバーなどが書き込みを行うディレクトリにはパーミッションが必要です。

$ cd l6x
$ chmod -R a+w storage

以下でページを見ることができるか確認です。

$ php artisan serve

l6x/publicのディレクトリがウェブルートと仮定して、ブラウザで、http://local:8000にアクセスすると、以下のページが表示されます。

必要なら、この時点でパージョン管理をするのも良いアイデアです。

$ cd l6x
$ git init
$ git add .
$ git commit -am "init"

認証のパッケージ

6.x以前のバージョンでは、ユーザー認証のデモに必要なファイルは以下のコマンドで作成できました。

$ php artisan make:auth

もうそのコマンドは存在しません。その代わりに以下のパッケージをインストールします。

$ composer require laravel/ui "^1.0"

注意：ここ間違いありで編集されています。--devなしで実行が必要です。

~~$ composer require laravel/ui "^1.0" --dev~~

次に、以下を実行して会員登録画面やログイン画面などを作成します。boostrapだけでなく、vueやreactの指定も可能です。

$ php artisan ui bootstrap --auth

今度は、javascriptやcssのトランスパイルのために、nodeのパッケージのインストールとwebpackの実行です。

$ npm install && npm run dev

次はDBの設定です。mysqlのコマンドを実行して、l6xのデータベースを作成します。

$ mysql -u root -p
mysql> create database l6x;

.envファイルを次のように編集してDB情報を入れます。

DB_DATABASE=l6x DB_USERNAME=DBユーザー名 DB_PASSWORD=DBパスワード

以下のコマンドを実行してDBテーブルを作成します。

$ php artisan migrate

以下のように、４つのテーブルが作成されます。

mysql> show tables;
+-----------------+
| Tables_in_l6x   |
+-----------------+
| failed_jobs     |
| migrations      |
| password_resets |
| users           |
+-----------------+
4 rows in set (0.00 sec)

再度、ブラウザでhttp://localhost:8000/registerにアクセスします。

と入力して、「Register」ボタンをクリックすると、

新規会員登録成功で、動作確認完了です。

Laravelへの移行（１）他のプログラムの認証セッションを認識

Sun, 12 Jul 2020 07:52:38 +0900

長いこと開発者をやっていると自分が開発した古いphpのプログラムの管理が悩みの種になります。なぜならLaravelのフレームワークが使われていないからです。年々新しい機能を追加したりしていると複雑になってくるし、ある昔のフレームワークで書かれたプロジェクトではphpunitも使えなく検証も容易にできません。このままで進んでいくにはますます管理において頭が痛くなります。しかし、すべて書き直してLaravelへの移行となると、日数とコストは大変なものです。さらに、外見がほとんど変わらずに中身だけの変更なので、お客さんを説得するのも難しい。

しかし、機会は訪れるもので、その悩みのプロジェクトのひとつにおいて、お客さんから大きな新規のリクエストが来ました。その新規のリクエストは現在の機能とは独立して扱える部分が多いので、こちらを独立させてLaravelで開発することにして、完成したら現行の機能を徐々にLaravelに移行していく、ということになりました。

嬉しい前進ですが、このプロジェクトに関して１つの必須条件は、現行のプログラムの認証を使用して（まだ使われるので）、新規のLaravelのプログラムの方では再度ログインを必要としてはいけない、というものです。

現行のプログラムの認証セッション

現行のプログラムもLaravelと同様に、ユーザー認証後ブラウザのクッキーを使用してそのユーザーのためだけの認証セッションを作成します。

以下は、現行のプログラムの認証セッションをシミュレートするプログラムですが、ログインしたユーザーの情報（ここでは、user_id）をセッションの情報に保存します。

start.php

ini_set('session.save_path', "/usr/www/repos/session");
ini_set('session.cookie_secure', '1'); // only secure
ini_set('session.name', 'admin');

session_start();
$_SESSION = ['user_id' => 1];

このプログラムをウェブでアクセスすると、アクセスしたクライアント、つまりブラウザでは、そのドメインで、adminという名前のクッキーが作成され、t20fa2tc05dd5gda1sfs1tsrofのような値が保存されます。そして、サーバー側では、指定した場所、つまり、/usr/www/repos/sessionのディレクトリに、sess_t20fa2tc05dd5gda1sfs1tsrofのセッションファイルが作成されます。その中身は以下のようになります。phpの$_SESSION変数の中身がそこで保存されています。

$ sudo cat /usr/www/repos/session/sess_t20fa2tc05dd5gda1sfs1tsrof
user_id|i:1;

認証セッションの認識

さて、問題は先の他のphpプログラムでの認証セッションをどうやってLaravelで認識して、あたかも自分の認証とするか、です。しかし、phpのセッションの構造は、Laravelの認証後に作成されるセッションとは違い、Laravelで簡単に共有というわけにはいきません。

そこで、私が考えたのは、まず、新規のLaravelのプログラムが認証を必要するときに、現行のプログラムですでに作成された認証セッションを認識して、それが正しいものなら、改めてLaravelの認証を実行することです。幸い、Auth::login($user);のようにログイン画面を通さずに認証する関数もあります。

まず、routeの設定部分を見てみましょう。

routes/web.php

Route::get('/', function () {
    return view('welcome');
});

Auth::routes();

Route::get('/home', 'HomeController@index')->name('home');

上では、/homeにアクセスすると、ログイン画面、/loginにリダイレクトされますが、それはHomeControllerのコンストラクタで以下のようにガードされているからです。

app/Http/Controlers/HomeController.php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class HomeController extends Controller
{
    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('auth:admin');　// ここで保護
    }

    /**
     * Show the application dashboard.
     *
     * @return \Illuminate\Contracts\Support\Renderable
     */
    public function index()
    {
        return view('home');
    }
}

しかし、以下のようにAuthenticateのミドルウェアのauthenticate()を上書き定義すると、

app/Http/Middleware/Authenticate.php

namespace App\Http\Middleware;

use Illuminate\Auth\Middleware\Authenticate as Middleware;

use Auth;
use App\User;

class Authenticate extends Middleware
{
    /**
     * 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];
        }

       if (in_array('admin', $guards)) {
            // すでにLaravel側で認証されているなら、OK
            if ($this->auth->guard('admin')->check()) {
                return $this->auth->shouldUse('admin');
            }

            // 現行のプログラムの認証セッションから情報を取得

            ini_set('session.save_path', "/usr/www/repos/session");
            ini_set('session.cookie_secure', '1'); // only secure
            ini_set('session.name', 'admin');

            session_start();

            if (isset($_SESSION['user_id'])) {
                if ($user = User::find($_SESSION['user_id'])) {
                    // ユーザーが存在するなら、Laravelで認証
                    Auth::guard('admin')->login($user);
                }
            }
        }

        foreach ($guards as $guard) {
            if ($this->auth->guard($guard)->check()) {
                return $this->auth->shouldUse($guard);
            }
        }

        $this->unauthenticated($request, $guards);
    }
...

すでに、現行のプログラムで認証されているなら、そのセッションの値を取得してLaravel側でも認証とします。

注意点としては、現行のプログラムと新規のLaravelのプログラムとで２つの認証セッションが存在することになります。両方とも違うセッションでお互いの存在を知らないので、セッションの期間が異なることになります。現行の方の認証が期限切れとなってもLaravelの方ではまだ期限内かもしれません。しかし、逆にLaravelのセッションが期限切れとなっても現行のプログラムのセッションが期限内なら、再度Laravelでセッションを作成するので問題はありません。

それから、現行のプログラムもLaravel側でも認証されていなときに、Laravel側にアクセスされたら、現行のプログラムのログイン画面にリダイレクトすることが必要です。それは以下のように、先のAuthenticateのクラスで、unauthenticated()を定義することにより可能です。

app/Http/Middleware/Authenticate.php

...
   /**
     * Handle an unauthenticated user.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function unauthenticated($request, array $guards)
    {
        if (in_array('admin', $guards)) {
           throw new AuthenticationException(
                'Unauthenticated.', $guards, 'http://localhost/app/admin/login' //現行のログイン画面
            );
        }
    }
...

最後に、現行のプログラムも新規のLaravelでも、セッションのクッキーパスが同じとすることをお忘れずに。そうでないと、新規のLaravelでは現行のプログラムのセッションにアクセスできません。上では両方ともクッキーパスはデフォルトの/となっています。

UUID　ユニークなID

Sun, 28 Jun 2020 07:29:45 +0900

商品のページのURLが例えばhttps://localhost/product/5734とかだと、5734はproductsテーブルのidの値だな、とわかってしまいます。しかしこれが、商品のIDではなく会員のIDや注文のIDなら大きな問題です。もちろん通常は認証で保護してログインした人のみしか閲覧できないようにしますが、プログラムのバグで認証が外れていたら。。。そんなときにIDがシーケンスの数字でなかったら、例えば、043a9c43-26cd-432f-bb25-a0eb045815b7とかのわけのわからない数字だったら安心です。今回はidの難読化のためのuuidを紹介です。

UUIDとは

wikiによると、

UUID（Universally Unique Identifier）とは、ソフトウェア上でオブジェクトを一意に識別するための識別子である。UUIDは128ビットの数値だが、16進法による550e8400-e29b-41d4-a716-446655440000というような文字列による表現が使われることが多い。元来は分散システム上で統制なしに作成できる識別子として設計されており、したがって将来にわたって重複や偶然の一致が起こらないという前提で用いることができる。

とあります。「重複が起こらないという前提で用いる」、これがidの代わりとして使用できる理由です。

Laravelで使用するには

phpにはuuidを作成する関数はないのですが、Laravelではもちろんパッケージを通して対応しています。

まず、migrationを使用してproductsのDBテーブルの項目として追加してみます。プライマリキーのidはキープして、ユニークなキーを持つuuidとして別に定義します。そうでないと、joinする他のDBテーブルのjoin keyも36文字の長い値を保存することになり効率的ではありません。

database/migrations/2020_06_25_172420_create_products.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateProducts extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('products', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->uuid('uuid')->unique();
            $table->char('name', 100);
            $table->decimal('price', 10, 0);
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('products');
    }
}

これをmigrateして、

$ php artisan migrate

mysqlで作成されたテーブルの定義を見ると、

mysql> describe products;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| id         | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| uuid       | char(36)            | NO   | UNI | NULL    |                |
| name       | char(100)           | NO   |     | NULL    |                |
| price      | decimal(10,0)       | NO   |     | NULL    |                |
| created_at | timestamp           | YES  |     | NULL    |                |
| updated_at | timestamp           | YES  |     | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+

36文字長のユニークなキーを持つuuidの項目が作成されています。

早速、DBレコードを作成してみます。

まず、Productのモデルを作成して、

app/Product.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    protected $fillable = [
        'uuid', 'name', 'price',
    ];
}

そして、tinkerでレコード作成してみます。

>>> Product::create(['uuid' => (string) Str::uuid(), 'name' => '商品名', 'price' => 1000]);
=> App\Product {#3986
     uuid: "043a9c43-26cd-432f-bb25-a0eb045815b7",
     name: "商品名",
     price: 1000,
     updated_at: "2020-06-25 18:03:45",
     created_at: "2020-06-25 18:03:45",
     id: 1,
   }

Str::uuid()はLaravelのヘルパーです。ヘルパーはLaravelが使用しているパッケージのオブジェクトを返すので、stringで文字列にキャストしています。

idを隠す

せっかく、uuidの項目があるのだから、プライマリキーのidが表に出ないように隠しましょう。

モデルにおいて、hiddenの属性にidを入れます。

app/Product.php

...
class Product extends Model
{
    protected $fillable = [
        'uuid', 'name', 'price',
    ];

    protected $hidden = [
    	'id'
    ];
}

idが隠れているか、tinkerで確認です。

>>> Product::find(1);
=> App\Product {#3996
     uuid: "043a9c43-26cd-432f-bb25-a0eb045815b7",
     name: "商品名",
     price: "1000",
     created_at: "2020-06-25 18:03:45",
     updated_at: "2020-06-25 18:03:45",
   }

idの項目表示されないですね。

しかし、直接ならアクセスできます。

>>> Product::find(1)->id;
=> 1

しかし、配列として変換などするとidの値は入ってきません。

>>> Product::find(1)->toArray();
=> [
     "uuid" => "043a9c43-26cd-432f-bb25-a0eb045815b7",
     "name" => "商品名",
     "price" => "1000",
     "created_at" => "2020-06-25 18:03:45",
     "updated_at" => "2020-06-25 18:03:45",
   ]

コントローラからuuidでアクセス

以下のように、getRouteKeyNane()で、uuidを指定すると、コントローラのURLでuuidを指定してレコードの取得可能です。

app/Product.php

...
class Product extends Model
{
    protected $fillable = [
        'uuid', 'name', 'price',
    ];

    protected $hidden = [
    	'id'
    ];

    public function getRouteKeyName()
    {
    	return 'uuid';
    }
}

コントローラを作成して、

app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

use App\Product;
use App\Http\Controllers\Controller;

class ProductController extends Controller
{
    public function show(Product $product)
    {
        return $product;
    }
}

ルートを設定します。

routes/web.php

...
Route::resource('/product', 'ProductController')->only('show');
...

通常のように、uuidでなくidの値でhttps::/local/product/1としてアクセスすると、

>>> $option = [ 'ssl' => ['verify_peer' => false, 'verify_peer_name' => false]];　//これはSSL認証のエラーを抑えるために必要。
=> [
     "ssl" => [
       "verify_peer" => false,
       "verify_peer_name" => false,
     ],
   ]
>>> file_get_contents('https://localhost/product/1', false, stream_context_create($option));
PHP Warning:  file_get_contents(https://localhost/product/1): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
 in Psy Shell code on line 1
=> false

404のページが見つからない、のエラーです。

しかし、https://localhost/product/043a9c43-26cd-432f-bb25-a0eb045815b7のようにuuidでアクセスすると、以下のようにレコードを取得してくれます。

>>> file_get_contents('https://localhost/product/043a9c43-26cd-432f-bb25-a0eb045815b7', false, stream_context_create($option));
=> "{"uuid":"043a9c43-26cd-432f-bb25-a0eb045815b7","name":"\u5546\u54c1\u540d","price":"1000","created_at":"2020-06-25 18:03:45","updated_at":"2020-06-25 18:03:45"}"
>>>

ダウンロードファイル名禁止文字に対応

Sun, 14 Jun 2020 08:58:25 +0900

Windows 10では、ファイル名として使用してはいけない文字がいくつかあります。入力しようとすると、「ファイル名に次の文字は使えません」とエラーになります。さて、ダウンロードのファイルにこれらの禁止文字が使用されていたらどうしましょう？

例えば、サーバーにアップされているファイル名は「567.jpg」と商品ID.jpgのフォーマットとします。しかし、ユーザーがダウンロードする時には「世界一おいしい? りんご、4/1から販売.jpg」と商品名.jpgにしたいときです。しかし、商品名に含まれる、?（半角疑問符）や/（半角バックスラッシュ）が禁止文字なのです。

手っ取り早いのは、半角の禁止文字を皆全角に置き換えてしまえばよいです。

ということでヘルパーの関数を作成します。

app/Helpers/MyHelper.php

namespace App\Helpers;

class MyHelper
{
    /**
     * 禁止半角文字を全角に
     * @param  string $value
     * @return  string
     */
    public static function convertToValidFilename($value)
    {
        $from = ['\\', '/', ':', '*', '?', '"', '>', '<', '|'];
        $to = ['￥', '／', '：', '＊', '？', '”', '＞', '＜', '｜'];

        $patterns = array_map(function($val) { return '#\\'.$val.'#'; }, $from);

        return preg_replace($patterns, $to, $value);
    }
}

preg_replace()の最初の引数に、その前の行のarray_map()で作成された配列を与えているところに注意してください。

通常は、

>>> preg_replace('/123/', 'xyz', '01234');
=> "0xyz4"

のように、パターンには/（半角スラッシュ）で囲んだ文字列を与えますが、配列を与えて複数の置き換えをすべて実行することもできます。

convertToValidFilename()では、$patternsが以下のような配列となり、

Array
(
    [0] => #\\#
    [1] => #\/#
    [2] => #\:#
    [3] => #\*#
    [4] => #\?#
    [5] => #\"#
    [6] => #\>#
    [7] => #\<#
    [8] => #\|#
)

これらは、以下の対応する$toに、

Array
(
    [0] => \
    [1] => /
    [2] => :
    [3] => *
    [4] => ?
    [5] => "
    [6] => >
    [7] => <
    [8] => |
)

に置き換えます。

パターンにおいて、通常使われる/（半角バックスラッシュ）の代わりに、#（半角シャープ）で囲まれているのは、/（半角バックスラッシュ）がパターン内の文字としてありエスケープ文字となってしまうからです。preg_replace()のパターンの境界文字は、そのように必要に応じて変えることができるのです。

早速、tinkerを使用して試してみましょう。

>>> use App\Helpers\MyHelper;
>>> MyHelper::convertToValidFileName('世界一おいしい? りんご、4/1から販売.jpg');
=> "世界一おいしい？ りんご、4／1から販売.jpg"

禁止文字が半角から全角に置き換わりましたね。

最後に、これを用いたコントローラのダウンロードメソッドは、こんな感じとなります。

public function download(Product $product)
{
    Storage::download(storage_path().'/'.$product->product-id.'.jpg',     
        MyHelper::convertToValidFileName($product->name).'jpg');
}

DB変更履歴の作成（４）パッケージ

Sun, 07 Jun 2020 04:55:17 +0900

DB変更の履歴の作成をトレイトで簡単にEloquentのモデルに装着できるとしたころまでが前回ですが、巷では似たような仕組みでより良いパッケージがすでにあります。今回はそれを紹介します。

Laravel Auditing

パッケージは、Laravel Auditingという名でララベル専用です。

独自のサイトもあります。

http://www.laravel-auditing.com/

まずはインストール、

$ composer require owen-it/laravel-auditing

次に設定ファイルのパブリッシュ。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="config"

config/audit.phpが作成されます。

DBテーブルの作成が必要なので、以下を実行してmigrationファイルを作成します。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="migrations"

作成されたファイルを見てみましょう。

database/migrations/2020_06_05_152546_create_audits_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audits', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('user_type')->nullable();
            $table->unsignedBigInteger('user_id')->nullable();
            $table->string('event');
            $table->morphs('auditable');
            $table->text('old_values')->nullable();
            $table->text('new_values')->nullable();
            $table->text('url')->nullable();
            $table->ipAddress('ip_address')->nullable();
            $table->string('user_agent', 1023)->nullable();
            $table->string('tags')->nullable();
            $table->timestamps();

            $table->index(['user_id', 'user_type']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('audits');
    }
}

これを見ると、作成するDBテーブルの名前はauditsで、 user_type, user_idは、アクセスしたユーザーの情報、 old_valuesとnew_valuesはモデルの古い値と新規の値が入る、 url、ip_address, user_agentはウェブのどこからアクセスされたかの情報、などと検討できますが、その他の項目はどう使われるが興味あるところです。特に、morphs(‘auditable’)の部分はなんでしょう？見たことないですね。

とりあえず、migrateしてテーブルを作成します。

$ php artisan migrate       
Migrating: 2020_06_05_152546_create_audits_table
Migrated:  2020_06_05_152546_create_audits_table (0.04 seconds)

作成されたテーブルの構造を見ると、

mysql> describe audits;
+----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| id             | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| user_type      | varchar(255)        | YES  |     | NULL    |                |
| user_id        | bigint(20) unsigned | YES  | MUL | NULL    |                |
| event          | varchar(255)        | NO   |     | NULL    |                |
| auditable_type | varchar(255)        | NO   | MUL | NULL    |                |
| auditable_id   | bigint(20) unsigned | NO   |     | NULL    |                |
| old_values     | text                | YES  |     | NULL    |                |
| new_values     | text                | YES  |     | NULL    |                |
| url            | text                | YES  |     | NULL    |                |
| ip_address     | varchar(45)         | YES  |     | NULL    |                |
| user_agent     | varchar(1023)       | YES  |     | NULL    |                |
| tags           | varchar(255)        | YES  |     | NULL    |                |
| created_at     | timestamp           | YES  |     | NULL    |                |
| updated_at     | timestamp           | YES  |     | NULL    |                |
+----------------+---------------------+------+-----+---------+----------------+

$table->morphs(‘auditable’);は、auditable_typeとauditable_idの２つの項目が作成される結果となっていますが、何の値が入るのでしょうね。

モデルでの設定

さて、実際にモデルに設定してみましょう。私の仕組みと同様にトレイト(Auditable)を使用しますが、同じ名前のインターフェース(Auditable)も使われています。以下の「これが必要！」の部分です。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

use OwenIt\Auditing\Contracts\Auditable; // これが必要！

class User extends Authenticatable implements Auditable　// これが必要！
{
    use Notifiable;
    use \OwenIt\Auditing\Auditable; // これが必要！

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    /**
     * ここで監査したい項目を指定！
     *
     * @var array
     */
    protected $auditInclude = [
        'name',
        'email',
    ];

早速、tinkerで実行してみましょう。 tinkerはコンソールの実行なので、設定ファイルを以下のように変更する必要あります。

config/audit.php

...
   /*
    |--------------------------------------------------------------------------
    | Audit Console
    |--------------------------------------------------------------------------
    |
    | Whether console events should be audited (eg. php artisan db:seed).
    |
    */

    'console' => true,
];

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> User::truncate(); //　リセットして空にします。
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3995
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-06-05 17:01:38",
     created_at: "2020-06-05 17:01:38",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->audits; // 作成した監査レコードを取得
=> Illuminate\Database\Eloquent\Collection {#4005
     all: [
       OwenIt\Auditing\Models\Audit {#4021
         id: 1,
         user_type: null,
         user_id: null,
         event: "created",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "[]",
         new_values: "{"name":"name1","email":"test1@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:38",
         updated_at: "2020-06-05 17:01:38",
       },
       OwenIt\Auditing\Models\Audit {#4026
         id: 2,
         user_type: null,
         user_id: null,
         event: "updated",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "{"email":"test1@example.com"}",
         new_values: "{"email":"test2@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:43",
         updated_at: "2020-06-05 17:01:43",
       },
     ],
   }

なるほど、

         auditable_type: "App\User",
         auditable_id: 1,

これらの項目には、何のモデルのどのレコードの履歴という情報を残しているのですね。

引き続いて、レコード削除も試みると、

>>> $user->delete();
=> true
>>> DB::table('audits')->get();
=> Illuminate\Support\Collection {#3986
     all: [
       {#4019
         +"id": 1,
         +"user_type": null,
         +"user_id": null,
         +"event": "created",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "[]",
         +"new_values": "{"name":"name1","email":"test1@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:38",
         +"updated_at": "2020-06-05 17:01:38",
       },
       {#4025
         +"id": 2,
         +"user_type": null,
         +"user_id": null,
         +"event": "updated",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"email":"test1@example.com"}",
         +"new_values": "{"email":"test2@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:43",
         +"updated_at": "2020-06-05 17:01:43",
       },
       {#4032
         +"id": 3,
         +"user_type": null,
         +"user_id": null,
         +"event": "deleted",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"name":"name1","email":"test2@example.com"}",
         +"new_values": "[]",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:04:27",
         +"updated_at": "2020-06-05 17:04:27",
       },
     ],
   }

削除されたレコードゆえにUser::find()では取得できないので、クエリビルダーで取得しましたが、３番目のauditsのレコードが作成されていること確認できます。また、eventの項目に注目してもらうと、created, updated, deletedという値が入っていることも確認できます。

今回はここまでですが、他にもタグを追加できる機能や、古いレコードを自動的に削除する機能など将来紹介したい機能がたくさんあります。また、クラス定義のインターフェイス、つまり、implementsや、よく知らないmorphsのトピックも将来扱いたいです。

DB変更履歴の作成（３）トレイト

Sun, 31 May 2020 01:34:51 +0900

前回のDB変更履歴保存のメカニズムは、Userのモデルのためだけですが、どのモデルでも同様なことが簡単にできるようにトレイトを作成してみます。

まず、audit_logsのテーブルを作成し直します。

どのモデルかわかるように項目を増やしました。前回、Userモデルのキーという意味でuser_idとしたところは、使用した会員のidの値が入るように変更しました。そして、モデルのキーは、model_keyという項目となっています。

database/migrations/2020_05_28_171205_create_audit_logs_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('route')->nullable(); // 実行したプログラムのルート
            $table->string('path')->nullable(); // 実行したプログラムのパス名
            $table->string('model')->nullable; // モデルのクラス名
            $table->unsignedBigInteger('model_key')->nullable(); // モデルのプライマリキー
            $table->unsignedBigInteger('user_id')->nullable(); // ユーザーのid
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }
}

次に、トレイトを作成します。

前回、boot()の関数名が、bootAuditTrait()と、‘boot’ + ‘AuditTrait’（トレイト名）となっていることに注意してください。

app/AuditTrait

namespace App;

use Request;
use Route;

trait AuditTrait
{
	/**
	 * Bootイベント
	 *
	 * 関数名は、boot()でなく'boot' + トレイト名
	 *
	 * @return void
	 */
	public static function bootAuditTrait()
	{
	    // parent::boot()はコールしない

        static::created(function ($model) {
            $model->addAuditLog('created');
        });

        static::updated(function ($model) {
            $model->addAuditLog('updated');
        });

        static::deleted(function ($model) {
            $model->addAuditLog('deleted');
        });
	}

    public function addAuditLog($event)
    {
        $route = optional(Route::getCurrentRoute())->getName();
        $path = Request::path();
        $model = get_class($this);
        $model_key = $this->id;
        $user_id = optional(auth()->user())->id;

        $old_value = $new_value = null;

        if (in_array($event, ['created', 'updated'])) {
            $new_value = serialize($this->attributes);
        }

        if (in_array($event, ['updated', 'deleted'])) {
            $old_value = serialize($this->original);
        }

        AuditLog::create([
            'route'      => $route,
            'path'       => $path,
            'model'      => $model,
            'model_key'  => $model_key,
            'user_id'    => $user_id,
            'old_value'  => $old_value,
            'new_value'  => $new_value,
        ]);
    }
}

上のトレイトにより、Userのクラスでは、use AuditTraittの１行の追加だけで済みます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

class User extends Authenticatable
{
    use Notifiable;
    use AuditTrait;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];
}

さて、tinkerの出番です。変更をテストみましょう。

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;

>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3990
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-28 18:36:06",
     created_at: "2020-05-28 18:36:06",
     id: 1,
   }

>>> $user->update(['email' => 'test2@example.com']);
=> true

>>> $user->delete();
=> true

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#4015
     all: [
       App\AuditLog {#4016
         id: 1,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:06",
         updated_at: "2020-05-28 18:36:06",
       },
       App\AuditLog {#4017
         id: 2,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:10",
         updated_at: "2020-05-28 18:36:10",
       },
       App\AuditLog {#4018
         id: 3,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-28 18:36:14",
         updated_at: "2020-05-28 18:36:14",
       },
     ],
   }
>>>

前回と同様に、レコードの作成、編集、削除のすべてが、audit_logsのレコードに記録されています。

DB変更履歴の作成（２）監査のデータを保存

Sun, 24 May 2020 03:33:06 +0900

前回においては、Eloquentのbootメソッドを利用してDB変更の情報（監査の情報）を取得することができました。今回は、これをDBに記録する部分を考えてみましょう。

監査のデータを保存するテーブル

監査のデータを保存するテーブルを、audit_logsとしてmigrationファイルを作成します。

$ php artisan make:migration create_audit_logs_table  
Created Migration: 2020_05_20_024714_create_audit_logs_table

作成されたファイルを編集して、テーブルの項目定義を入れます。

database/migrations/2020_05_20_024714_create_audit_logs_table

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('user_id')->default(0)->index(); // Userモデルのid
            $table->string('path')->default(''); // 実行したプログラムのパス名
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }

old_valueとnew_valueには、レコードの項目のすべての値をserializeして入れるために大きいデータタイプとしています。

以下を実行してテーブルを作成します。

$ php artisan migrate
Migrating: 2020_05_20_024714_create_audit_logs_table
Migrated:  2020_05_20_024714_create_audit_logs_table (0.02 seconds)

AuditLogのクラスも作成します。

app/AuditLog

namespace App;

use Illuminate\Database\Eloquent\Model;

class AuditLog extends Model
{
    protected $guarded = [];
}

そして、Userクラスのプログラムを書き替えます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

use Request;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    protected static function boot()
    {
        parent::boot();

        static::created(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => null,
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::updated(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::deleted(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => null,
            ]);
        });
    }
}

tinkerでレコードの作成、Eメールアドレスの変更、そしてレコードの削除を実行します。

Psy Shell v0.10.2 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3058
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-20 03:28:18",
     created_at: "2020-05-20 03:28:18",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->delete();
=> true

AuditLogのレコードを取り出してみると、すべてのの変更履歴、監査の情報が保存されています。

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#3072
     all: [
       App\AuditLog {#3073
         id: 1,
         user_id: 1,
         path: "/",
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:18",
         updated_at: "2020-05-20 03:28:18",
       },
       App\AuditLog {#3074
         id: 2,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:38",
         updated_at: "2020-05-20 03:28:38",
       },
       App\AuditLog {#3075
         id: 3,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-20 03:28:47",
         updated_at: "2020-05-20 03:28:47",
       },
     ],
   }

DBの変更履歴の作成

Mon, 18 May 2020 11:58:18 +0900

データベースに保存されているデータはいつも現時点での値であり、過去の値は保存されていません。しかし、レコードのデータがどう変更したかという情報は重要です。どう変更したかだけではなく、誰がいつ、アプリのどの機能を使用して、さらにはどういう理由で、という情報も必要になってきます。例えば、カスタマサポートにおいて、会員の住所が変更されて注文した商品が届かなかったとき、それらの情報があれば、いついつにお客様が住所を変更しましたね、とか即答できます。さて、これらの変更イベント時の変更情報（監査あるいはAudit情報）、Laravelではどのように効率的にDBに保存することが可能でしょうか？

Eloquentのイベントメソッド

LaravelのEloquentを利用すると、DBのイベント、つまりレコードの作成、変更、削除の３つのイベントに連結したメソッドが提供されています。そして、それらのイベントが発生する前あるいは後においてユーザー定義のコードをコールバックさせることが可能です。これらを利用したら、希望するAuditの情報をキャプチャすることが簡単にできます。

さてLaravelのデフォルトのプロジェクトを使って見てみましょう。まず、UserのクラスにDBのレコード変更後のイベントのコールバックを作成します。以下のようにbootメソッドにおいて見慣れないクラスメソッドupdatedをコールすることで可能となります。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function () {
            echo "updated\n";
        });
    }
}

ちなみに、updatedは更新後にコールされるものですが、新規作成後は、created、削除後はdeletedというメソッドになります。

tinkerを使用して実行してみます。

>>> $user = User::find(1);
=> App\User {#3048
     id: 1,
     name: "近藤 篤司",
     email: "manabu.takahashi@example.net",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:31:32",
   }
>>> $user->update(['email' => 'test@example.com']);
updated
=> true

コールバックで定義したupdatedが表示されましたね！

変更前後の情報の取得

DBのレコード変更イベントでユーザー定義の関数をコールバックを確認できたら、次は変更前後でのレコードの情報をどうやって取得するかです。以下見てください。コールバックにそれらの情報を表示するコードを追加しました。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function ($model) {
            echo "updated\n";
            print_r($model->original);
            print_r($model->attributes);
        });
    }
}

tinkerで実行してみます。

>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3067
     id: 1,
     name: "近藤 篤司",
     email: "test@example.com",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:59:31",
   }
>>> $user->update(['email' => 'test2@example.com']);
updated
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 18:59:31
)
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test2@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 19:03:27
)
=> true

前後の値、キャプチャできましたね。これで変更履歴を作成するには十分な準備ができました。これらを利用すれば、変更前後の値あるいは差分を保存できますね。

DBの負荷の緩和（3）コントローラにより接続を変える

Sun, 26 Apr 2020 01:28:18 +0900

マスターDBの変更が複製DBに反映されるまでの時間差を考えると、サイトの特定のページでは複製DBのアクセスを使用したくないかもしれません。例えば、会員のログインなど会員のアカウントの情報に関わるページとか、Eコマースのチェックアウトのページとか、あるいは管理者のみがアクセスする管理ページとか。そうなると、特定のコントローラだけに複製DBコネクションを限定するにはどのようにすればよいのでしょう？

まず、マスターDBのみのDBコネクションをmysqlとして、複製DBを使用するDBコネクションをmysql_rwとして、config/database.phpで２つのコネクションを設定します。

config/database.php

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],

        'mysql_rw' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'read' => [
                'host' => env('DB_HOST_RO', env('DB_HOST', '127.0.0.1')),
                'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
                'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
            ],
            'write' => [
                'host' => env('DB_HOST', '127.0.0.1'),
                'username' => env('DB_USERNAME', 'forge'),
                'password' => env('DB_PASSWORD', ''),
            ],
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE'),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],
..

.envのファイルでは、DB_HOST_RO, DB_USERNAME_RO, DB_PASSWORD_ROの設定項目の指定が必要となります。 ROはRead Onlyという意味で読み込み専用のユーザーが複製DBにアクセスします。

また、デフォルトは、マスターDBのコネクションであることに注意してください。

次に、例えば、商品閲覧ページにおいてDBコネクションを変えるには、以下のように、コントローラのコンストラクタにおいて、コネクションのデフォルトを上書きしてDB::reconnect()で接続します。

app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

class ProductController extends Controller
{
    public function __construct()
    {
        parent::__construct();

        config(['database.default' => 'mysql_rw']);
        DB::reconnect();
..

簡単ですね。

いちいち、それぞれのコンストラクタでコネクションを変えるのが面倒なら、以下のよう親のコントローラにおいてまとめて指定することも可能です。試してはいないですが、ミドルウェアでの対応も可能なはずです。

app/Http/Controllers/Controller.php

    public function __construct()
    {
        $route = Route::currentRouteName();

        // 特定のページだけDBコネクションを変更する
        $routes = [
            'user.home',
            'user.page',
            'user.shop',
            'user.category',
            'user.collection',
            'user.product',
        ];

        if (in_array($route, $routes)) {
            config(['database.default' => 'mysql_rw']);
            DB::reconnect();
        }
...

DBの負荷の緩和（２）トランザクション

Mon, 20 Apr 2020 02:31:25 +0900

前回において、Laravelの読み込みと書き込みのDBを自動使い分け機能により、プログラムの設定だけで簡単にDB負荷を緩和できることを知りました。今回は、DBのトランザクションにおいてその機能の振る舞いをチェックしてみます。

例えば、以前の個数管理での在庫数変更の以下の例を見てます。

$product = Product::find(1);　// 複製のDBから読み込む
 
$product->update(['inventory' => $product->inventory - 1]); // マスターのDBで書き込む

上では、まず、商品の情報をDBから読み込み、そこから得る在庫数をもとに次の行で在庫数を変更します。しかし、２つのDBを使用するとなると、最初の行は複製DBからの読み込みとなり、次の行ではマスターのDBにおいての書き込みとなります。

問題は、複製のDBはマスターDBとの時間差があるので、もしかしたら最初の行で読み込んだのは最新の在庫数ではないかもしれないません。つまりデータの整合性の問題となる可能性です。

そうなら、以下のようにトランザクションで囲んでみましょう。

DB::beginTransaction();
 
$product = Product::find(1);
 
$product->update(['inventory' => $product->inventory - 1]);
 
DB::commit();

しかし、トランザクションはマスターDB内だけでの作業の整合性を保証するものなので、同じ問題となるのでは？

Laravelのコードを深く追ってみます。

まず、LaravelのDB接続のクラスでは、マスターDBの$pdoと読み込み専用の$readPdoの２つのDB接続のための変数が宣言されています。

/vendor/laravel/framework/src/Illuminate/Database/Connection.php

...
class Connection implements ConnectionInterface
{
    use DetectsDeadlocks,
        DetectsLostConnections,
        Concerns\ManagesTransactions;

    /**
     * The active PDO connection.
     *
     * @var \PDO|\Closure
     */
    protected $pdo;

    /**
     * The active PDO connection used for reads.
     *
     * @var \PDO|\Closure
     */
    protected $readPdo;
...

そして、同じクラス内で、読み込みDBの接続の取得は、以下のメソッドで定義されています。

    /**
     * Get the current PDO connection used for reading.
     *
     * @return \PDO
     */
    public function getReadPdo()
    {
        if ($this->transactions > 0) { //トランザクションがあると、マスターのDB接続を使用
            return $this->getPdo();
        }

        if ($this->recordsModified && $this->getConfig('sticky')) {
            return $this->getPdo();
        }

        if ($this->readPdo instanceof Closure) {
            return $this->readPdo = call_user_func($this->readPdo);
        }

        return $this->readPdo ?: $this->getPdo();
    }
...

トランザクションがあると、読み込み専用のDBではなく、マスターのDBが使われる条件文があります。つまり、トランザクションの中では、たとえDB実行文が読み込み（SELECT SQL文）であっても、読み込みのDB接続は使われずマスターDBしか使われないということです。

ちなみに、上のコードではstickyのときも、条件文で読み込みのDBの使用しないようになっています。これは以下のようにデータベースの設定で指定できます。そして、目的はDB更新後に、書き込みをしたマスターDBから値を読みたいときです。トランザクションと同様に、読み込み専用のDBからでは時間差の問題が生ずるからです。良く考えられていますね。

config/database.php

...
'mysql' => [
    'read' => [
        'host' => [
            '192.168.1.1',
            '196.168.1.2',
        ],
    ],
    'write' => [
        'host' => [
            '196.168.1.3',
         ],
    ],
    'sticky'    => true,
    'driver'    => 'mysql',
    'database'  => 'database',
    'username'  => 'root',
    'password'  => '',
    'charset'   => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
    'prefix'    => '',
],
...

DBの負荷の緩和

Mon, 13 Apr 2020 04:47:24 +0900

お客さんのサイトのアクセスが最近10倍以上に増えてきました。ロードバランスもなく1台にウェブもDBもメールサーバーもあるAWSの仮想マシンなので、とりあえず、仮想マシンをアップグレードしました。

しかし、アップグレードしてもDBのトランザクションでデッドロックが起きるなどの問題が起こります。これはDBやOSのカーネルの調整が必要となるか、それともやはり、ロードバランスが必要なときか、しかしそんな専門的知識もないしそれを学習や試験する時間も必要だし。。。と悩んでいるときに、DBの読み書きでDB接続を自動的に使い分ける機能がLaravelにあることを見つけました。

DBの複製は、MySQLデータベースのレプリカにAWS RDSを利用で、すでに設定してあり、これをDBの読み込み専用に使います。書き込みは本マシンのマスターのDBを使います。

さて、Laravel側で変更することは以下のDB設定の変更です。まず、新規にmysql_rwなる接続を定義します。

config/database.php

...
        'mysql_rw' => [
            'write' => [ // 書き込み
              'host' => '127.0.0.1'
            ],
            'read' => [  // 読み込み専用、複製DB
              'host' => '127.0.0.2' // RDSのendpointのURLあるいはプライベートIPアドレス
            ],
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

上の例では、複製のDBのユーザーとパスワードはマスターのDBのユーザーと同じという仮定ですが、違うなら以下のようにも指定できます。

    'write' => [
        'host' => '127.0.0.1',
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
    ],
    'read' => [
        'host' => '127.0.0.2',
        'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
        'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
    ],

さらに、複製DBが1つでは足りないときは、複数の設定も可能です。

    'read' => [
        'host' => ['127.0.0.2', '127.0.0.3', '127.0.0.4'], 
        'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
        'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
    ],

最後に、.envを編集して、

...
DB_CONNECTION=mysql_rw
...

とDB接続を変更します。

個数管理：実用を考えたケース

Sun, 05 Apr 2020 01:41:59 +0900

前回の「個数管理」のコードに少し肉付けをして実際に近いケースを考慮してみます。

例えば、Ｅコマースにおいてチェックアウトの際にカートに追加したアイテムの在庫を確保するとします。しかし、カートには複数のアイテムが含まれるかもしれないので、すべてのアイテムにおいて在庫確保成功とはいかないかもしれません。在庫数の更新失敗のアイテムがあるときにはすでに在庫確保したアイテムも元に戻す必要あります。

Checkoutというクラスを作成し、reserveInventoryというメソッドを作成します。 DBのトランザクションとカスタムExceptionに注目してください。

App/Checkout.php

namespace App;

use DB;
use Exception;
use App\Product;
use App\Exceptions\InventoryException;

use Illuminate\Database\Eloquent\Model;

class Checkout extends Model
{
    public static function reserveInventory($ids)
    {
        try {
            DB::beginTransaction();

            foreach($ids as $id  => $quantity) {
                $count = Product::query()
                    ->where('id', '=', $id)
                    ->whereRaw("inventory - $quantity >= 0")
                    ->decrement('inventory', $quantity);

                if ($count == 0) {
                    throw new InventoryException(); // 在庫がなくて在庫数を更新できなかったとき
                }
            }

            DB::commit();

        } catch (InventoryException $e) {
            DB::rollBack();

            return '購入しようとしている商品の在庫が十分にありません';

        } catch (Exception $e) {
            DB::rollBack();

            return 'DBエラーが発生しました' . $e->getMessage();
        }

        return '在庫確保成功！';
    }
}

reserveInventory()の引数は、product.idとquantityの値の配列関数です。例えば、product.id = 1で購入個数１個なら、[ 1 => 2 ]。

上で使用されている、InventoryExceptionの定義は、

App/ExceptionsInventoryException.php

namespace App\Exceptions;

use Exception;

class InventoryException extends Exception
{
    public function __construct($message = '') {
        parent::__construct($message);
    }
}

さて、tinkerで実行してみましょう。

まず、商品を２つ用意します。商品１の在庫は２で、商品２の在庫は１とします。

>>> App\Product::all()
=> Illuminate\Database\Eloquent\Collection {#3059
     all: [
       App\Product {#3083
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 2,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:06:36",
       },
       App\Product {#3071
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 1,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:05:52",
       },
     ],
   }

次に、カートのアイテムを用意して在庫確保します。

商品１を１個、商品２を１個購入です。

>>> $products = [ 1 => 1, 2 => 1 ];
=> [
     1 => 1,
     2 => 1,
   ]
>>> Cart::reserveInventory($products);
=> "在庫確保成功！"
>>> App\Product::all();
=> Illuminate\Database\Eloquent\Collection {#3060
     all: [
       App\Product {#3075
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 1,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:08:53",
       },
       App\Product {#3078
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 0,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:08:53",
       },
     ],
   }

商品１の在庫は１で、商品２の在庫は０となりました。うまく在庫数に反映されています。

更新失敗を見るために、もう１度在庫確保を実行してみます。

>>> Cart::reserveInventory($products);
=> "購入しようとしている商品の在庫が十分にありません"
>>> App\Product::all();
=> Illuminate\Database\Eloquent\Collection {#3070
     all: [
       App\Product {#3072
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 1,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:08:53",
       },
       App\Product {#3082
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 0,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:08:53",
       },
     ],
   }

今度は、在庫エラーが出ました。商品１は更新されますが、商品２においては在庫がないのでInventoryExceptionがthrowされ、トランザクションのためにDBへの変更はロールバックされて商品１の変更ももとに戻ります。

以上は、シンプル化された例なので、改良点はたくさんありそうです。エラー文に商品名を入れるとか、在庫エラーを管理者にメールで伝えるとか。

個数管理

Sat, 28 Mar 2020 05:46:15 +0900

商品の在庫数管理など一般的な個数管理に必要とされる、Eloquentのメソッドdecrementを紹介します。

準備

まず、商品テーブルの作成からです。migrationを作成します。

$ php artisan make:migration create_products_table --create=products

作成されたファイルを編集して、name, price, inventoryの項目を追加します。

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateProductsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('products', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->char('name', 100); // 商品名
            $table->decimal('price', 10, 0);　// 価格
            $table->smallInteger('inventory'); // 在庫数
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('products');
    }
}

これをmigrateしてテーブルを作成します。

$ php artisan migrate

次に、tinkerを立ち上げて商品レコードを作成します。

$ php artisan tinker
Psy Shell v0.9.12 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\Product;
>>> Product::create(['name' => '商品', 'price' => 1000, 'inventory' => 10]);
=> App\Product {#3064
     name: "商品",
     price: 1000,
     inventory: 10,
     updated_at: "2020-03-27 19:35:37",
     created_at: "2020-03-27 19:35:37",
     id: 1,
   }

トランザクションで整合性を保持

商品の在庫から購入数分だけ差し引く処理として、まず考えられるのは以下のようになります（引き続きtinkerを使用します）。

>>> use App\Product;
>>> $product = Product::find(1);
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 10,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:03:27",
   }
>>> $product->update(['inventory' => $product->inventory - 1]);
=> true
>>> $product->refresh();
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 9,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:04:56",
   }
>>>

つまり、商品をオブジェクトに読み込んで、現在の在庫数の属性（inventory）の値から、必要な個数（ここでは１個）を引いた値でDBレコードを更新（update）します。

上で実行されたSQL文を確認のために見てみましょう。レコード読み込み、更新、さらに読み込みと３つのSQL文となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 14.83,
     ],
     [
       "query" => "update `products` set `inventory` = ?, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         9,
         "2020-03-27 20:04:56",
         1,
       ],
       "time" => 5.79,
     ],
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 8.23,
     ],
   ]

このやり方、一見良さそうに見えますが、大きな問題があります。

ウェブのように同時に同じ処理が可能な環境において、レコードを読み込んだ時と書き込むときの間に在庫数がすでに更新されているかもしれないことです。その場合には在庫数は不正確になってしまいます。

これを防ぐには、上のプログラムをトランザクションで囲むことです。

DB::beginTransaction();

$product = Product::find(1);

$product->update(['inventory' => $product->inventory - 1]);

DB::commit();

トランザクションでは複数のSQL文の実行があたかも１つのように実行してくれるので、その間の作業の整合性を保持してれます。

よりシンプルに

先のトランザクションでも問題ないですが、以下のようEloquentのdecrementのメソッドを使用して同様な処理も可能です。

>>> Product::where('id', '=', 1)->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:18:48",
         1,
       ],
       "time" => 9.34,
     ],
   ]

こうなるとSQL文は１つなので、整合性保持のためのトランザクションの必要はなくなります。

さて、注意する必要があるのは、上の例を見て、以下でも同じことができるのでは？と思われることです。

>>> Product::find(1)->decrement('inventory', 1);
=> 1

しかし、このSQL文を見てみると、以下のように読み込みと更新の２つのSQL文になっています。これではトランザクションが必要となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 12.63,
     ],
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:22:48",
         1,
       ],
       "time" => 2.58,
     ],
   ]

在庫がゼロにならないようにするには

在庫数を減らすときに、在庫数がゼロにならないようにするには、チェックが必要です。これも以下のように実行するなら１つのSQL文で済みます。

>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ? and inventory - 1 >= 0",
       "bindings" => [
         "2020-03-27 20:38:46",
         1,
       ],
       "time" => 10.09,
     ],
   ]

最初の行の実行で返り値が１となっていること気づいたと思いますが、そこでは更新されたレコードの数が返っています。

もし、実行の前の在庫数がすでにゼロなら、

>>> Product::where('id', '=', 1)->update(['inventory' => 0]);
=> 1
>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 0

０が返って更新はなかった、ということです。

FormRequestでルールを共有

Tue, 24 Mar 2020 04:28:31 +0900

世界中大変なことになっていますね。私が住んでいるところも、子供たちの学校は４月いっぱい休み、レストランやバーはテイクアウトのみとなっています。それらのビジネスに携わっている人たちは本当に困っていると思います。逆に、私を含めてこのブログを読んでくれる人たちは、インターネットのおかげで忙しくなっているくらいと思います。その有難さを胸に、日々精進と行きましょう！

今回は、またもやFormRequestの話で、１つのコントローラーにおいてあるいは複数のコントローラでどうバリデーションのルールを共有の仕方を考えてみます。

ルールを共有する必要性

ルールをコントローラ間で共有する必要があるのは、重複の定義をせずに一か所で管理をして間違いを防ぎたいからです。

会員レコードを例にとると、

ユーザー画面での会員登録ユーザー画面で名前や住所などの会員情報更新ユーザー画面でパスワード変更さらに、管理画面ではユーザー画面と同様に、新規、更新、パスワード更新の機能が必要となります。

つまり、少なくともユーザー画面と管理画面で２つのコントローラーが必要で、それぞれの入力画面に異なるFormRequestを作成すれば６つ必要となります。そして、それぞれにルールの定義があるわけですが、いくつかは明らかに同じものを定義することになります。将来の管理性を考えるとどうかしたいですね。

ルールの共有の仕方

ルールを共有するにはいくつかのやり方ありますが、ここでは、以前書いた以下のブログを利用してみます。

コントローラー中でのルールの共有

そこでは、１つのコントローラ内でのルールの共有していますが、今度はFormRequest内でルールを共有します。そのために、先に書いた６つのFormRequestを作成する代わりに、１つのFormRequestを作成してそれを複数のコントローラのメソッドで共有とします。

まず、以前のコードを以下に再掲載します。

namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;
 
use App\User;
 
class UserController extends Controller
{
    public function rule($action, User $user = null)
   {
        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ];
 
       // 共有しないルール
       switch ($action) {
            case 'store':　// レコード作成のためのルールを追加
                $rules['password']      = 'required|min:8|max:20|confirmed';
                $rules['email']         = 'required|email|unique:users';
                break;
 
            case 'update': // レコード編集のためのルールを追加
                $rules['email'] = [
                    'required',
                    'email',
                    Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
                ];
                break;
        }
 
        return [
            // rules
            $rules,
            // messages
            [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
            ]
            // attributes
        ];
    }
...
    public function store(Request $request)
    {
        $request->validate(...$this->rules('store'));
        ...
    }
...
    public function update(Request $request, User $user)
    {
        $request->validate(...$this->rules('update', $user));
        ...
    }
...
}

FormRequestを使用すると、rules()の部分がUserFormRequestに移って、

...
    public function store(UserFormRequest $request)
    {
        ...
    }
...
    public function update(UserFormRequest $request, User $user)
    {
        ...
    }
...
}

となりますが、問題は、上と違って$actionや$userなどのパラメータを渡すことができません。どうしたらよいでしょう？

そこで登場するのが、$this->route()のメソッドです。UserFormRequestの中で、以下のようにそれらの情報が取り出せます。名前付きのルートがわかれば、それで条件分岐できます。

        $route= $this->route()->getName(); // 現在のrouteの名前を取得
        $user = $this->route('user'); // update(UserFormRequest $request, User $user)の$userを取得

以下が、UserFormRequestのコードです。

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserFormRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rule()
    {
        $route= $this->route()->getName(); // 現在のrouteの名前を取得
        $user = $this->route('user'); // update(UserFormRequest $request, User $user)の$userを取得

        // 共有するルール　kana, mailcode, phone_with_dashはカスタムバリデーター
        $rules = [
            'name'        => 'required',
            'name_kana'   => 'required|kana',
            'mailcode'    => 'required|mailcode',
            'prefecture'  => 'required',
            'city'        => 'required',
            'address1'    => 'required',
            'phone'       => 'required|phone_with_dash',
        ];
 
       // 共有しないルール
       switch ($route) {
            case 'user.store':　// レコード作成のためのルールを追加
                $rules['password']      = 'required|min:8|max:20|confirmed';
                $rules['email']         = 'required|email|unique:users';
                break;
 
            case 'user.update': // レコード編集のためのルールを追加
                $rules['email'] = [
                    'required',
                    'email',
                    Rule::unique('users')->ignore($user->id), //現在のレコード以外のレコードで重複がないかチェック
                ];
                break;
        }
 
        return $rules;
    }

    public function messages()
    {
        return [
                'password.min' => '8から20文字長でお願いします',
                'password.max' => '8から20文字長でお願いします'
        ];
    }
}

FormRequestで入力値を補正

Fri, 13 Mar 2020 23:59:58 +0900

FormRequestの続きです。FormRequestは、ユーザーの入力をチェックしてくれるだけでなく、入力値も変えてくれることができます。

例えば、フォームにおいて以下のようなチェックボックスがあったとき、

	<div class="form-group row">
		<label for="subscribe" class="col-md-4 col-form-label text-md-right">メルマガを購読？</label>

		<div class="col-md-6">
			<input id="subscribe" type="checkbox" class="form-control" name="subscribe" value="Y">
		</div>
	</div>

チェックをオンにすれば、リクエストにはY（Yesの意味）の値が返ってきますが、チェックがオフなら何も値が返ってきません。それゆえに、例えばチェックなしをDBにN（Noの意味）として保存したいなら、どうしましょう？

私のFormRequestの継承元のFormRequestのLaravelのコードを見ると、以下のようなメソッドがあります。

vendor/laravel/framework/src/Illuminate/Foundation/Http/FormRequest.php

...
    /**
     * Get data to be validated from the request.
     *
     * @return array
     */
    public function validationData()
    {
        return $this->all();
    }
...

このメソッドを上書きして、

app/Http/Requests/UserRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name'  => 'required',
            'email' => 'required|email',
            'subscribe' => 'string',　// これを忘れずに！
        ];
    }

    public function validationData()
    {
        $all = parent::validationData();

        //値がないなら、'N'を入れる
        if (! $this->has('subscribe')) {
            $all['subscribe'] = 'N';
        }

        return $all;
    }
}

ルールにおいては、チェックボックスの項目（subscribe）のルールが必ず必要です。

こうすれば、

namespace App\Http\Controllers;

use App\Http\Requests\UserRequest;

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
    }

    public function edit()
    {
    	$user = auth()->user();

    	return view('user_edit')->with(compact('user'));
    }

    public function update(UserRequest $request)
    {
        dd($request->validated()); // デバッグ文を入れる

    	auth()->user()->update($request->validated());

    	return redirect()->route('home');
    }
}

フォームでsubmitすると、上で入れたデバッグ文の実行は、

array:3 [▼
  "name" => "kenji"
  "email" => "kenji@lotsofbytes.com"
  "subscribe" => "N"
]

と返してくれます。

FormRequestを使う

Mon, 09 Mar 2020 11:58:03 +0900

コントローラーのファイルが大きくなってきたな、と思ったら、FormRequestを使ってみようかと真剣に考え始めました。まずは、FormRequestとは何ものかの紹介からです。

FormRequestを使わないコントローラ

FormRequestを使わないコントローラというのは、例えば以下のコードに代表されます。

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth'); //認証したユーザーのみがアクセス可能
    }

    public function edit()
    {
    	$user = auth()->user();　// 認証したユーザーの情報を取得

    	return view('user_edit')->with(compact('user'));
    }

    public function update(Request $request)
    {
       // リクエストのバリデーション
    	$validated = $request->validate([
    		'name'  => 'required',
    		'email' => 'required|email',
    	]);

        // DBの情報を更新
    	auth()->user()->update($validated);

        // ホーム画面へリダイレクト
    	return redirect()->route('home');
    }
}

このコントローラを使用する、routeは以下のように定義されます。

routes/web.php

Route::get('/', function () {
    return view('welcome');
});

Auth::routes();

Route::get('/home', 'HomeController@index')->name('home');

Route::get('/user/edit', 'UserController@edit')->name('user.edit');
Route::put('/user/edit', 'UserController@update')->name('user.update');

よく見て欲しいのは、UserController::update()のメソッド。リクエストの入力値をバリデートして、バリデーションをパスした入力値をそのまま、EloquestのUserオブジェクト(auth()->user)のupdate()に渡して更新です。

ちなみに、このコントローラは、ログインしたユーザーが自分の情報を編集するためです。Laravelのデフォルトのプロジェクトにはユーザー認証のコードがついてきますが、この機能はありません。

FormRequestを使用したら

まず、コマンドラインから、FormRequestの作成です。

$ php artisan make:request UserRequest

これで、UserRequest.phpが作成されます。それを以下のように編集します。

app/Http/Requests/UserRequest.php

amespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true; // すでにUserController::__construct()でチェックしてあるので、true
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name'  => 'required',
            'email' => 'required|email',
        ];
    }
}

見ての通り、コントローラにあったバリデーションルールが移動されています。

コントローラの方は、

namespace App\Http\Controllers;

use App\Http\Requests\UserRequest; //ここで宣言

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');
    }

    public function edit()
    {
    	$user = auth()->user();

    	return view('user_edit')->with(compact('user'));
    }

    public function update(UserRequest $request)
    {
    	auth()->user()->update($request->validated());　// １行になりました

    	return redirect()->route('home');
    }
}

FormRequestを使うことでコントローラのコードの行数は減りました。しかし、FormRequestの定義のファイルが増えて全体のコードの行数は増えたことも事実。今回のような、簡単なコードではあまり得したことにはならない感じですね。ない方がわかりやすいとも思えます。しかし、もしバリデーションルールがもっとたくさんあったら、FormRequestはベターなのは明らかです。コードが複雑になったらリファクターして新規の関数を作成するのと同じかな。

しかし、FormRequestを使うことに関して他の利点はなんでしょう？次回からそれらの利点を探ってみます。

編集のブレード

参考として、作成したブレードファイルも掲載します。resources/views/auth/register.blade.phpをもとにしましたが、Eメールの入力において、type=“email”のところ、type=“text”にしています。バリデーションエラーの表示をテストしたかったためです。

resources/views/user_edit.blade.pohp

@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row justify-content-center">
        <div class="col-md-8">
            <div class="card">
                <div class="card-header">{{ __('Register') }}</div>

                <div class="card-body">
                    <form method="POST" action="{{ route('user.edit') }}">
                        @csrf
                        @method('PUT')

                        <div class="form-group row">
                            <label for="name" class="col-md-4 col-form-label text-md-right">{{ __('Name') }}</label>

                            <div class="col-md-6">
                                <input id="name" type="text" class="form-control @error('name') is-invalid @enderror" name="name" value="{{ old('name', $user->name) }}" required autocomplete="name" autofocus>

                                @error('name')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>

                        <div class="form-group row">
                            <label for="email" class="col-md-4 col-form-label text-md-right">{{ __('E-Mail Address') }}</label>

                            <div class="col-md-6">
                                <input id="email" type="text" class="form-control @error('email') is-invalid @enderror" name="email" value="{{ old('email', $user->email) }}" required autocomplete="email">

                                @error('email')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>

                        <div class="form-group row mb-0">
                            <div class="col-md-6 offset-md-4">
                                <button type="submit" class="btn btn-primary">
                                    {{ __('Register') }}
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

ddd()

Sat, 29 Feb 2020 02:03:48 +0900

Laravelではdd()というヘルパー関数をデバッグでよく使用しますが、ddd()は初耳です。なぜなら、Laravel 6.xバージョンで新登場したデバッグの関数だからです。

dd()

新登場のddd()の比較のためと、Laravel 6.xの以前のバージョンのために、まずdd()の使用を見てみましょう。

dd()を以下のように追加すると、

routes/web.php

Route::get('/', function () {
	$user = App\User::first();
	dd($user);
    return view('welcome');
});

以下のように実行を止めて、引数で指定した変数の情報をブラウザに表示してくれます。

その時点で、実行した関数のスタックトレースをしたいなら、

routes/web.php

Route::get('/', function () {
	$user = App\User::first();
	dd(print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS),true));//面倒なら、debug_backtrace(2)でもＯＫ
    return view('welcome');
});

とすると、

Array
(
    [0] => Array
        (
            [file] => /vol1/usr/www/repos/repos/l6x/vendor/laravel/framework/src/Illuminate/Routing/Route.php
            [line] => 205
            [function] => {closure}
            [class] => Illuminate\Routing\RouteFileRegistrar
            [type] => ->
        )

    [1] => Array
        (
            [file] => /vol1/usr/www/repos/repos/l6x/vendor/laravel/framework/src/Illuminate/Routing/Route.php
            [line] => 179
            [function] => runCallable
            [class] => Illuminate\Routing\Route
            [type] => ->
        )

    [2] => Array
        (
            [file] => /vol1/usr/www/repos/repos/l6x/vendor/laravel/framework/src/Illuminate/Routing/Router.php
            [line] => 681
            [function] => run
            [class] => Illuminate\Routing\Route
            [type] => ->
        )
...

ddd()

さて、Laravel 6.xのバージョンのddd()ヘルパーを使用すると、

routes/web.php

Route::get('/', function () {
	$user = App\User::first();
	ddd($user);
    return view('welcome');
});

以下のように、とても見やすいＵＩで出力してくれます。

そればかりでなく、関数スタックのトレースもメニューを選択して表示してくれます。しかも、Laravel内部での関数の実行を隠して（拡張して見ることも可能）開発した関数だけを見せてくれます。

こういう便利な機能を追加してくれると、Laravelをアップグレードするモチベーションが上がりますね。

ユーザー認証のパスワード制限の変更

Tue, 25 Feb 2020 00:10:58 +0900

Laravel 5.8において、ユーザー認証のパスワードの長さの制限がそれまでの最低の６文字長から８文字長に変わりました。セキュリティ強化の目的です。しかし、この制限を変えたい、つまり昔の６文字長をキープしたい、あるいは８文字長でなくより強化して１０文字長としたいなら、どうするのでしょう？

5.8のコードを見ると、会員登録とパスワードを忘れた時のパスワードリセットにおいてのみ、min:8のバリデーションが使われています（不思議とログインではパスワードの長さの制限なし）。しかもトレイトで定義されているバリデーションの関数rules()を上書きすればよいだけ、と思いきや、ハードコードされていて効かない箇所がありました。

ハードコードの箇所は、パスワードリセットの機能です。そこのコントローラーから、コードを追跡してみましょう。

app/Http/Controller/Auth/ResetPasswordController

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ResetsPasswords;

class ResetPasswordController extends Controller
{
    use ResetsPasswords;

    /**
     * Where to redirect users after resetting their password.
     *
     * @var string
     */
    protected $redirectTo = '/home';

    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('guest');
    }
}

そこで使用されている、ResetPasswordsのトレイトの定義は、

vendor/laravel/framework/src/Illuminate/Foundation/Auth/ResetsPasswords.php

namespace Illuminate\Foundation\Auth;

use Illuminate\Support\Str;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Password;
use Illuminate\Auth\Events\PasswordReset;

trait ResetsPasswords
{
...
    /**
     * Reset the given user's password.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\RedirectResponse|\Illuminate\Http\JsonResponse
     */
    public function reset(Request $request)
    {
        $request->validate($this->rules(), $this->validationErrorMessages());

        // Here we will attempt to reset the user's password. If it is successful we
        // will update the password on an actual user model and persist it to the
        // database. Otherwise we will parse the error and return the response.
        $response = $this->broker()->reset(
            $this->credentials($request), function ($user, $password) {
                $this->resetPassword($user, $password);
            }
        );

        // If the password was successfully reset, we will redirect the user back to
        // the application's home authenticated view. If there is an error we can
        // redirect them back to where they came from with their error message.
        return $response == Password::PASSWORD_RESET
                    ? $this->sendResetResponse($request, $response)
                    : $this->sendResetFailedResponse($request, $response);
    }

    /**
     * Get the password reset validation rules.
     *
     * @return array
     */
    protected function rules()
    {
        return [
            'token' => 'required',
            'email' => 'required|email',
            'password' => 'required|confirmed|min:8',
        ];
    }
...

rules()では、min:8とあるから、先ほどのResetPasswordControllerで、rules()を再定義して、min:6とすれば良いということです。

しかし、そのルールを使用する21行目のvalidate()だけでなく、さらに、26行目のbrokerのreset()でもチェックが入っていたのです。その、brokerのコードを見てみましょう。

vendor/laravel/framework/src/Illuminate/Auth/Passwords/PasswordBroker.php

namespace Illuminate\Auth\Passwords;

use Closure;
use Illuminate\Support\Arr;
use UnexpectedValueException;
use Illuminate\Contracts\Auth\UserProvider;
use Illuminate\Contracts\Auth\PasswordBroker as PasswordBrokerContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;

class PasswordBroker implements PasswordBrokerContract
{
...

   /**
     * Reset the password for the given token.
     *
     * @param  array  $credentials
     * @param  \Closure  $callback
     * @return mixed
     */
    public function reset(array $credentials, Closure $callback)
    {
        // If the responses from the validate method is not a user instance, we will
        // assume that it is a redirect and simply return it from this method and
        // the user is properly redirected having an error message on the post.
        $user = $this->validateReset($credentials);

        if (! $user instanceof CanResetPasswordContract) {
            return $user;
        }

        $password = $credentials['password'];

        // Once the reset has been validated, we'll call the given callback with the
        // new password. This gives the user an opportunity to store the password
        // in their persistent storage. Then we'll delete the token and return.
        $callback($user, $password);

        $this->tokens->delete($user);

        return static::PASSWORD_RESET;
    }

    /**
     * Validate a password reset for the given credentials.
     *
     * @param  array  $credentials
     * @return \Illuminate\Contracts\Auth\CanResetPassword|string
     */
    protected function validateReset(array $credentials)
    {
        if (is_null($user = $this->getUser($credentials))) {
            return static::INVALID_USER;
        }

        if (! $this->validateNewPassword($credentials)) {
            return static::INVALID_PASSWORD;
        }

        if (! $this->tokens->exists($user, $credentials['token'])) {
            return static::INVALID_TOKEN;
        }

        return $user;
    }

    /**
     * Set a custom password validator.
     *
     * @param  \Closure  $callback
     * @return void
     */
    public function validator(Closure $callback)
    {
        $this->passwordValidator = $callback;
    }

    /**
     * Determine if the passwords match for the request.
     *
     * @param  array  $credentials
     * @return bool
     */
    public function validateNewPassword(array $credentials)
    {
        if (isset($this->passwordValidator)) {
            [$password, $confirm] = [
                $credentials['password'],
                $credentials['password_confirmation'],
            ];

            return call_user_func(
                $this->passwordValidator, $credentials
            ) && $password === $confirm;
        }

        return $this->validatePasswordWithDefaults($credentials);
    }

    /**
     * Determine if the passwords are valid for the request.
     *
     * @param  array  $credentials
     * @return bool
     */
    protected function validatePasswordWithDefaults(array $credentials)
    {
        [$password, $confirm] = [
            $credentials['password'],
            $credentials['password_confirmation'],
        ];

        return $password === $confirm && mb_strlen($password) >= 8;
    }
...

上のコードで、定義されている関数をトレースすると実行順番は、

reset() validateReset() validateNewPassword() validatePasswordWithDefaults()

最後の関数で８文字長の制限がありましたね（118行目）。しっかり、ハードコードされています。

5.8のドキュメントでは、

https://laravel.com/docs/5.8/upgrade#new-default-password-length Illuminate\Auth\Passwords\PasswordBrokeを継承して、validatePasswordWithDefaults()を上書きすればよいとありますが、ディープ過ぎて面倒です。

以下で他の人も不平述べています。

https://github.com/laravel/framework/issues/28274

より簡単な解決策はないかと、調査したら、

ベストの解決策は、ResetPasswordsのトレイトのreset()をResetPasswordControllerで上書きしてbrokerのvalidator()を無能にすることです。つまり、

app/Http/Controller/Auth/ResetPasswordController

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ResetsPasswords;

use Illuminate\Http\Request; // この追加必要！
use Illuminate\Support\Facades\Password; // この追加必要！

class ResetPasswordController extends Controller
{
...
   /**
     * Reset the given user's password.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\RedirectResponse|\Illuminate\Http\JsonResponse
     */
    public function reset(Request $request)
    {
        $request->validate($this->rules(), $this->validationErrorMessages());

        // Here we will attempt to reset the user's password. If it is successful we
        // will update the password on an actual user model and persist it to the
        // database. Otherwise we will parse the error and return the response.

        // PasswordBrokerのvalidatorをここで定義
        $this->broker()->validator(function (array $credentials) {
            return true; // rules()ですでにバリデーションを実行しているので、さらにここでバリデーションの必要はなし！
        });

        $response = $this->broker()->reset(
            $this->credentials($request), function ($user, $password) {
                $this->resetPassword($user, $password);
            }
        );

        // If the password was successfully reset, we will redirect the user back to
        // the application's home authenticated view. If there is an error we can
        // redirect them back to where they came from with their error message.
        return $response == Password::PASSWORD_RESET
                    ? $this->sendResetResponse($request, $response)
                    : $this->sendResetFailedResponse($request, $response);
    }

    /**
     * Get the password reset validation rules.
     *
     * @return array
     */
    protected function rules()
    {
        return [
            'token' => 'required',
            'email' => 'required|email',
            'password' => 'required|confirmed|min:6',　// min:8でなくmin:6に変える
        ];
    }
...

rules()も再定義して６文字長としました。

さて、この問題6.xのバージョンではどうなんでしょう？ PasswordBroker.phpのコードを見ると、

vendor/laravel/framework/src/Illuminate/Auth/Passwords/PasswordBroker.php

namespace Illuminate\Auth\Passwords;

use Closure;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;
use Illuminate\Contracts\Auth\PasswordBroker as PasswordBrokerContract;
use Illuminate\Contracts\Auth\UserProvider;
use Illuminate\Support\Arr;
use UnexpectedValueException;

class PasswordBroker implements PasswordBrokerContract
{
...
    /**
     * Reset the password for the given token.
     *
     * @param  array  $credentials
     * @param  \Closure  $callback
     * @return mixed
     */
    public function reset(array $credentials, Closure $callback)
    {
        $user = $this->validateReset($credentials);

        // If the responses from the validate method is not a user instance, we will
        // assume that it is a redirect and simply return it from this method and
        // the user is properly redirected having an error message on the post.
        if (! $user instanceof CanResetPasswordContract) {
            return $user;
        }

        $password = $credentials['password'];

        // Once the reset has been validated, we'll call the given callback with the
        // new password. This gives the user an opportunity to store the password
        // in their persistent storage. Then we'll delete the token and return.
        $callback($user, $password);

        $this->tokens->delete($user);

        return static::PASSWORD_RESET;
    }

    /**
     * Validate a password reset for the given credentials.
     *
     * @param  array  $credentials
     * @return \Illuminate\Contracts\Auth\CanResetPassword|string
     */
    protected function validateReset(array $credentials)
    {
        if (is_null($user = $this->getUser($credentials))) {
            return static::INVALID_USER;
        }

        if (! $this->tokens->exists($user, $credentials['token'])) {
            return static::INVALID_TOKEN;
        }

        return $user;
    }
...

validateReset()から、validateNewPassword()は削除されていますね！

これに関しては、以下で説明されています。

https://laravel.com/docs/6.x/upgrade#belongs-to-update　（Password Resetの部分）

さらに、PRとして、 https://github.com/laravel/framework/pull/29480

もう、この部分で悩むことはなさそうです。

データベースのテスト

Sat, 01 Feb 2020 02:18:37 +0900

既存のDBのそれぞれのテーブルにおいて、migrationファイルやfactoryファイルが揃ったところで、phpunitのテストを作成して実行してみましょう。

テストDBの作成

テストDBは、phpunitのためだけのDBとなるゆえに、ブラウザでアクセスする本DBとは違うDBを作成します。つまり、開発サイトでは、プロジェクト１つに対して２つのDBを持つことになります。

本DBは、mysqlで、テストのDBには、sqliteという設定がドキュメントでも一般のLaravelの記事でも書かれていますが、私はテストといえども、本DBもテストDBも同じmysqlを使用することを勧めます。条件をまったく同じとしたいからです。

まず、mysqlのコマンドで、テストDB（demo_test）を作成します。

$ echo "create database demo_test" | mysql -u root -p
Query OK, 1 row affected (0.00 sec)

次に、config/database.phpをエディターで開いて、mysqlのコネクションをコピーして、mysql_testのコネクションを作成します。

config/databse.php

use Illuminate\Support\Str;

return [
....
    'connections' => [
...
        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],

        'mysql_test' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => 'demo_test',
            'username' => 'root',
            'password' => 'secret',
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

mysql_testにおいて編集した項目は、database、username、passwordです。env()を使用せずに、固定としています。必要なら他の項目も同様に編集してください。それから、usernameに指定するmysqlのユーザーは必ず、drop table, create table, truncateのsql文と実行できる権限を持つユーザーである必要があります。それゆえに、ここではrootのmysqlユーザーを使用しています。

次に、テーブル作成のartisanコマンドを実行して、テストDBにテーブルを作成します。前回で作成したmigrationファイルがここで役立ちます。

$ php artisan migrate:fresh --database=mysql_test
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.03 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.02 seconds)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (0.01 seconds)

必ず、–databaseでmysql_testのコネクションを指定ください。指定しないと、本DBの方が空となってしまうので注意を！

phpunitの設定

テストDBをテストの実行で使用するには、phpunit.xmlの編集が必要です。

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
         backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <server name="APP_ENV" value="testing"/>
        <server name="BCRYPT_ROUNDS" value="4"/>
        <server name="CACHE_DRIVER" value="array"/>
        <server name="DB_CONNECTION" value="mysql_test"/>
        <server name="MAIL_DRIVER" value="array"/>
        <server name="QUEUE_CONNECTION" value="sync"/>
        <server name="SESSION_DRIVER" value="array"/>
    </php>
</phpunit>

DB_CONNECTIONをmysql_testと指定しています。

さて、これでphpunitを実行できます。vendor/bin/phpunitは、このプロジェクトでインストールされたバージョンのphpunitなので、必ずそのパスを使用してください。

$ vendor/bin/phpunit
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 335 ms, Memory: 16.00 MB

OK (2 tests, 2 assertions)

OKがテスト成功、という意味です。

RefreshDatabaseトレイト

先のphpunitの実行では、データベースのテストは含まれていません。作成してみましょう。

$php artisan make:test --unit UserTest
Test created successfully.

この実行で、tests/Unit/UserTest.phpのファイルが作成されますが、それを以下のように編集します。

UserTest.php

namespace Tests\Unit;

// use PHPUnit\Framework\TestCase // Laravel 6.xで生成されるが、コメントして以下を追加
use Tests\TestCase;

use Illuminate\Foundation\Testing\RefreshDatabase; // 追加

use App\User;

class UserTest extends TestCase
{
    use RefreshDatabase;

    public function test_create_a_user()
    {
        factory(User::class)->create(); // usersのDBテーブルにレコードを１つ作成

        $this->assertCount(1, User::all()); // すべてのレコードを取得してレコード数が１であることを確認
    }
}

実行してみましょう。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

成功ですね。

このテストは何回実行しても成功となります。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)
$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

試しに、use RefershDatabaseをコメントして実行してみてください。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

F                                                                   1 / 1 (100%)

Time: 324 ms, Memory: 18.00 MB

There was 1 failure:

1) Tests\Unit\UserTest::testExample
Failed asserting that actual size 2 matches expected size 1.

/vol1/usr/www/repos/repos/l6x/tests/Unit/UserTest.php:23

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

１回名は成功ですが、２回目は失敗です．なぜなら、RefereshDatabaseなしではレコードは追加されていくばかりだからです。RefereshDatabaseのトレイトを使用することによりDBテーブルが空となり、毎回同じ条件でテストを実行できます。

既存のDBからfactoryファイルを自動作成

Sat, 25 Jan 2020 07:51:08 +0900

既存のＤＢからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。

どうして、factoryのファイルが必要？

factoryのファイルが必要なのは、あらゆるテストの目的のためです。いちいち画面の入力でDBレコードを作成する代わりに、tinkerやユニットテストでfactory()のヘルパーを使用して簡単にレコードが作成できようになります。factoryのタグの記事では、たくさんの使用例を見ることできます。

しかし、現状の以下のLaravelのコマンドの実行では、

$ php artisan make:factory UserFactory --model=User

作成されるfactoryは、以下のように項目もない単なるテンプレートです。

databases/factorys/UserFactory.php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\Model;
use Faker\Generator as Faker;

$factory->define(User::class, function (Faker $faker) {
    return [
        //
    ];
});

DBテーブルがたくさんあるプロジェクトでは、いちいちこれを編集していくのはとても大変です。それゆえに、既存のDB構造をもとに、自動でfactoryファイルを生成する必要があります。

factoryファイル自動生成ツール

まずは、パッケージのインストール。以下をコマンドラインで実行します。

$ composer require --dev mpociot/laravel-test-factory-helper

factoryのファイルを作成するには、artisanの実行が必要となります。Laravel 6.x の新規プロジェクトを作成して実行しますが、すでにUserのモデルのためのfactoryファイルが、databases/factories/UserFactory.phpとして存在するので、上書きされないように改名しておきます。そして以下をコマンドラインで実行します。

$ php artisan generate:model-factory
Model factory created: database/factories/UserFactory.php

作成されたfactoryの内容は以下です。

databases/factories/UserFactory.php

/* @var $factory \Illuminate\Database\Eloquent\Factory */

use Faker\Generator as Faker;

$factory->define(App\User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->safeEmail,
        'email_verified_at' => $faker->dateTime(),
        'password' => bcrypt($faker->password),
        'remember_token' => Str::random(10),
    ];
});

元にあったファイルと比べてみましょう。以下が元のファイルです。

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

いくつか違いがありますね。しかし、これも自動生成されたmigrationファイルと同様に使用するテストに合わせて編集すればよいです。 Fakerのドキュメントは、こちらです。

factoryファイル自動作成のコマンドのartisanの実行には、いくつかのオプションを指定することができます。

すべてのモデルのfactoryを作成する代わりに、指定のモデルだけのfactoryの作成には、

$ php artisan generate:model-factory User Team

モデルのファイルがが、app/Modelsのディレクトリにあるなら、

$ php artisan generate:model-factory --dir app/Models -- User Team

と実行できます。

最後に、migrationとfactoryの自動作成ツールは、Laravelのバージョンによりインストールが違うのでここでまとめてリストします。

Laravel 6.x

$ composer require --dev oscarafdev/migrations-generator 2.0.13
$ composer require --dev mpociot/laravel-test-factory-helper

Laravel 5.5~

$ composer require --dev xethron/migrations-generator
$ composer require --dev mpociot/laravel-test-factory-helper v1.3

Larave 6.xへ更新

Sat, 18 Jan 2020 01:14:39 +0900

またまたLaravelの更新の時期がやってきました。と言っても、またしても遅れての私のキャッチアップです。Laravel 6.xのバージョンは、Laravel 5.5と同様にLTSの長期サポートまでなので、バグの修正は、9/3/2021まで、セキュリティの修正は、9/3/2022までとあるので、できるならアップグレードしたいです。また、6.xのバージョンは、新サービスのサーバーレス対応のVaporでは必須ゆえに、Laravelを実行するサーバーのスケールアップに興味があるなら、なおさら頑張ってアップグレードする必要あります。

何が変わった？

さて、バージョン6.xともなると、大きな変更は少なくなってきています。私のプロジェクトでのアップグレードで気づいたことの報告をします。

まず忘れる前に、Laravel 6.xの更新には、最低php 7.2のバージョンが必要となります。と言っても、最新のphpは、バージョン7.4です。phpもLaravelもバージョンアップのペースが速い。もう少し遅くても、とも思います。

ヘルパーの変更

Laravel 5.8に更新で登場したのですが、配列や文字列のヘルパー関数が、クラスのstaticのメソッドに代わる、という話。例えば、array_only()は、Arr::only()に代わる。その時点では、両方使用できましたが、Laravel 6.xでは、もうグローバル関数の方はデフォルトでは使用できません。

それらを使用するには、以下を実行してパッケージを追加する必要あります。

$ composer require laravel/helpers

使用していたパッケージへの影響

phpunitのバージョンは、Laravel 5.8のバージョン7からバージョン8になりました。そして悲しいことに私が愛好していたデータベースのテストのphpunit/dbunitの開発・管理が止まりました。

ここでいつか紹介しようと思っていたのですが、紹介する前に作者の意向で開発ストップです。dbunitは、xmlファイルで用意したデータをユニットテストのためにデータベースにインポートしてくれる便利な機能があります。毎回のテストの前には、データをtruncateしてくれるのでいつでも空の状態から始めることができ、でテストの再現性を実現してくれます。

しかし、そこはオープンソースの強みというか、githubなどのサービスの便利さというか、他の開発者（以下のリンク）が早速にもレポをフォークしてphpunitバージョン8に対応してくれています。残念ながら、このパッケージのメインテナーとはならないようですが。

https://github.com/kornrunner/dbunit

これで暫くは凌げそうですが、この際に、Laravelのmigrationやfactoryを使用した、RefershDatabaseのトレイトを使ったデータベースのテストに書き換えていこうとも思います。

そして、そのステップ１として、前回の既存のＤＢからmigrationファイルを自動作成のパッケージの紹介でした。

しかし、このパッケージ、残念ながらLaravel6.xでは互換性で使えない、と思ったら対応しているこれまたレポをフォークしたパッケージがありました。

https://github.com/oscarafdev/migrations-generator

捨てる神があれば、拾う神ありです。助けられます。

ユーザー認証

Laravel 5.xでは、php artisan make:authの実行でユーザー認証の機能が追加できました。

Laravel 6.xでは、以下の実行が必要となります。

$ composer require laravel/ui
$ php artisan ui bootstrap --auth

uiのタイプとしては、bootstrap, vue, reactの選択があります。これらの実行で、ユーザー認証に必要なrouteの追加や、コントローラーやブレードのファイルが作成されます。

L6.x on ララジャパン

DNSを使ってメールアドレスをチェック

緩いメールアドレスのバリデーション

email:dnsの登場

dns_get_record()

最後に

Laravel 7.x更新で発見したこと（3）ルートのキャッシュ

ルートのキャッシュ

重複のルート名はL6.xではOKだったのに

L7.xでの問題

最後に

メンテナンス画面：php artisan up & down

メンテンナンス画面

私がアクセスしたい

メンテナンス画面をカスタマイズしたいなら

artisanのコマンドは実行できる？

abort()を使ってリダイレクト

Laravel 6.xのインストール

新規プロジェクトの作成

認証のパッケージ

Laravelへの移行（１）他のプログラムの認証セッションを認識

現行のプログラムの認証セッション

認証セッションの認識

UUID ユニークなID

UUIDとは

Laravelで使用するには

idを隠す

コントローラからuuidでアクセス

ダウンロードファイル名禁止文字に対応

DB変更履歴の作成（４）パッケージ

Laravel Auditing

モデルでの設定

DB変更履歴の作成（３）トレイト

DB変更履歴の作成（２）監査のデータを保存

監査のデータを保存するテーブル

DBの変更履歴の作成

Eloquentのイベントメソッド

変更前後の情報の取得

DBの負荷の緩和（3）コントローラにより接続を変える

DBの負荷の緩和（２）トランザクション

DBの負荷の緩和

個数管理：実用を考えたケース

個数管理

準備

トランザクションで整合性を保持

よりシンプルに

在庫がゼロにならないようにするには

FormRequestでルールを共有

ルールを共有する必要性

ルールの共有の仕方

FormRequestで入力値を補正

FormRequestを使う

FormRequestを使わないコントローラ

FormRequestを使用したら

編集のブレード

ddd()

dd()

ddd()

ユーザー認証のパスワード制限の変更

データベースのテスト

テストDBの作成

phpunitの設定

RefreshDatabaseトレイト

既存のDBからfactoryファイルを自動作成

どうして、factoryのファイルが必要？

factoryファイル自動生成ツール

Larave 6.xへ更新

何が変わった？

ヘルパーの変更

使用していたパッケージへの影響

ユーザー認証

UUID　ユニークなID