L5.1 on ララジャパン

バリデーション (8) 配列をバリデーションする

Sun, 23 Oct 2016 10:47:45 +0900

laravel 5.2 で、バリデーションルールに配列を表す .* というプレースホルダーが使えるようになりました。

例えば、次のような商品オプションのバリデーションを考えます。

入力行の追加UIやドラッグ＆ドロップによるソートはjQueryなどで実装することにします（laravel から離れるので解説は省きます）

この場合、項目数がいくつになるかわからないので、エレメントの属性名を name=“option_name[{{$id}}]" などとし、配列を返すように作りますよね。

リクエストは次のようなものになるでしょう。配列のキーは編集データに依存しますので不定です（ここでは仮に 11, 12, 13 としました）

print_r($request->all());

Array
(
     [option_id] => Array
        (
            [11] => Y
            [12] => Y
            [13] => Y
        )

    [option_name] => Array
        (
            [11] => ホワイト
            [12] => ブラック
            [13] => オレンジ
        )

    [unit_price] => Array
        (
            [11] => 1000
            [12] => 1200
            [13] => 980
        )

    [inventory] => Array
        (
            [11] => 30
            [12] => 20
            [13] => 15
        )
)

最低必要なバリデーションとしては、「保存」が少なくとも１つチェックされることと、「保存」がチェックされた行は必須入力となること、そして「販売単価」と「在庫数」の数値判定です。

苦労していた配列のバリデーションですが、5.2 からは次のようなルール定義が可能になったのです。

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'required_with:option_id.*',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

$messages = [
  'option_id.required' => '保存するレコードを少なくとも１つ選択してください',
];

「オプション名」、「販売単価」、「在庫数」のルール定義には属性名に .* を加えることで、配列の値それぞれにバリデーションが適用されるようになります。

「保存」がチェックされた行だけ入力が必要なので、required_with の引数も option_id.* となります。一方で「保存」の必須チェックは配列全体の required です。

配列部分のエラーは array_dot() による配列ドット記法で返ってきますので、Bladeテンプレートのエラーメッセージ表示は次のような書き方になります。

{{ $errors->first("unit_price.$id") }}

laravel 4 や 5.1 以前での配列バリデーション

後出しジャンケンでの自慢話となってしまいますが、私たちのプロジェクトでは lavavel 4 のころから配列に対するバリデーションを、5.2 と同じルールの書き方で処理してきました。

もともと laravel のバリデーションでは、リクエストは配列のまま処理されるでのはなく、array_dot によるドット記法の一次元データに変換されて内部処理されていました。

例えば次のように、配列のキーが固定されてる入力フォームの場合ならば、

<input type="text" name="name[last]" value="{{ old('name.last') }}">
<input type="text" name="name[first]" value="{{ old('name.first') }}">

Array
(
     [name] => Array
        (
            [last] => 山田
            [first] => 太郎
        )
)

以下のようにドット記法でルールを定義することで、配列データもバリデーションできたのです。

$rules = [
  'name.last'  => 'required',
  'name.first' => 'required',
];

最初に、「5.2 で .* というプレースホルダーに対応した」と書き、配列バリデーションそのものに対応したと書かなかった意味がここにあります。このプレースホルダーの変換を自分で対応すれば、5.1 以前や 4 でも同様の処理ができるわけです。

定義するルール：

$rules = [
  'option_id'     => 'required',
  'option_name.*' => 'required_with:option_id.*',
  'unit_price.*'  => 'required_with:option_id.*|integer|min:0',
  'inventory.*'   => 'required_with:option_id.*|integer|min:0',
];

変換後のルール：

$rules = [
  'option_id'      => 'required',
  'option_name.11' => 'required_with:option_id.11',
  'option_name.12' => 'required_with:option_id.12',
  'option_name.13' => 'required_with:option_id.13',
  'unit_price.11'  => 'required_with:option_id.11|integer|min:0',
  'unit_price.12'  => 'required_with:option_id.12|integer|min:0',
  'unit_price.13'  => 'required_with:option_id.13|integer|min:0',
  'inventory.11'   => 'required_with:option_id.11|integer|min:0',
  'inventory.12'   => 'required_with:option_id.12|integer|min:0',
  'inventory.13'   => 'required_with:option_id.13|integer|min:0',
];

この変換は次のような関数で対応できます。ベースコントローラかトレイトに入れて、バリデーション直前にルールの変換を挿入してみてください。

/**
 * 配列バリデーションルールの変換
 * @param \Illuminate\Http\Request $request
 * @param array                    $rules
 * @param array                    $messages
 */
public static function setArrayRules($request, &$rules, &$messages)
{
    foreach($rules as $field => $rule)
    {
        // field文字列は foo.* か？
        if (!preg_match('/^(.+)\.\\*$/', $field, $m)) continue;

        // fooはリクエストに存在して配列か？
        $name = $m[1];
        if (!($req = $request->get($name)) || !is_array($req)) continue;

        foreach(array_keys($req) as $i)
        {
            // rulesに foo.$i を複写
            $rules["$name.$i"] = str_replace('*', $i, $rule);

            // messagesにfoo.$i.barがあれば複写
            foreach($messages as $key => $message)
            {
                if (!preg_match("/^$name\.\\*\.(.+)$/", $key, $m)) continue;
                $messages["$name.$i.{$m[1]}"] = $message;
            }
        }
        unset($rules[$field]);
    }
}

p.s.

上で紹介した setArrayRules() では、次のような配列の記述には対応してません。もし必要とするならばご自身で考えてみてくださいね。

Bladeソース:

<input type="text" name="option[{{$id}}][name]" value="old("opton.$id.name")">

バリデーションルール:

 'option.*.name' => 'required_with:option_id.*',

メンテナンス画面の裏口

Sun, 10 Jan 2016 07:17:25 +0900

先日、開発完了のLaravelのプログラムをインストールするときに、私だけのためにメンテナンス画面に裏口があったらいいなと思いました。

Laravelでは、

php artisan down

このコマンドの実行で、すべてのアクセスを以下のようなメンテナンス画面にできます。そのモードに切り替えて、DBの変更とかなどのインストールの作業を誰にも邪魔されずにするのです。

しかし、インストール後には、できる限りの動作テストを行いたいのですが、自分も含めて誰もアクセスできない状態は不都合です。せめて私や関係者だけ、つまりそれらのIPだけからは通常に見れるようにしたいのです。

私がフレームワークなしの時代に開発したプログラムでは、すべてのプログラムに共通で最初に読み込まれるPHPファイルに、以下のようなコードで、私だけが閲覧できるようにしていました。

$allow = array('xxx.xxx.xxx.xxx');

if (isset($_SERVER)) // ウェブのアクセスのみ
{
    if (isset($_SERVER["REMOTE_ADDR"]) && !in_array($_SERVER["REMOTE_ADDR"], $allow))
    {
        include_once "maintenance.php";
        exit;
    }
}

普段はこれらはコメントしておいて、メンテナンスのときにコメントを解除するのです。xxx.xxx.xxx.xxxは私の固定IPですが、そのIPだけが、メンテ画面を含むmaintenance.phpの実行をしないのです。

これと同じことをLaravelでできないでしょうか？

ちょっと調べたところ、以下のファイルにおいて、

app/Http/Kernel.php

class Kernel extends HttpKernel
{
    /**
     * The application's global HTTP middleware stack.
     *
     * @var array
     */
    protected $middleware = [
        \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
    ];
...

vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode.php

このファイルがミドルウェアとして、メンテナンスのモードかどうかをチェックしているらしい。

ということで、そのファイルをコピーして、

app/Http/Middleware/CheckForMaintenanceMode.php

として、その中味を以下のように編集します。

app/Http/Middleware/CheckForMaintenanceMode.php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Contracts\Foundation\Application;
use Symfony\Component\HttpKernel\Exception\HttpException;

class CheckForMaintenanceMode
{
    /**
     * The application implementation.
     *
     * @var \Illuminate\Contracts\Foundation\Application
     */
    protected $app;
    protected $allow = ['xxx.xxx.xxx.xxx'];
    /**
     * Create a new middleware instance.
     *
     * @param  \Illuminate\Contracts\Foundation\Application  $app
     * @return void
     */
    public function __construct(Application $app)
    {
        $this->app = $app;
    }

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {

        if ($this->app->isDownForMaintenance()) {
            if (!in_array($request->getClientIp(), $allow)) {
                throw new HttpException(503);
            }
        }

        return $next($request);
    }
}

基本的には、先のコードと同様なメカニズムです。

そして先のKernel.phpを

app/Kernel.php

...
    protected $middleware = [
        \App\Http\Middleware\CheckForMaintenanceMode::class,
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
    ];
...

と編集する。簡単な変更ですが有用です。

ちなみに、メンテナンスの解除をするには、

php artisan up

これを実行するのみなのですが、ちょっとメカニズムに興味ありますね。

調べたところ、downでは、

storage/framework/down

という空のファイルを作成されます。そしてupの実行ではこのファイルが削除されます。意外とシンプルですね。

最後に、メンテナンスの画面は以下のファイルを編集します。

resources/views/errors/503.blade.php

ユーザー認証（８）ユーザーの有効・無効を考慮

Sun, 27 Dec 2015 12:33:42 +0900

まだまだ続くユーザ認証。今まではいわば基礎編みたいなもので、教科書通りの紹介。今回は、実践として、こういうときはどうする？みたいな応用編です。

まずはDBテーブルusersの構成を見るところから。

+----------------+------------------+------+-----+---------------------+----------------+
| Field          | Type             | Null | Key | Default             | Extra          |
+----------------+------------------+------+-----+---------------------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL                | auto_increment |
| active_flag    | char(1)          | NO   |     |                     |                |
| name           | varchar(255)     | NO   |     | NULL                |                |
| email          | varchar(255)     | NO   | UNI | NULL                |                |
| password       | varchar(60)      | NO   |     | NULL                |                |
| remember_token | varchar(100)     | YES  |     | NULL                |                |
| created_at     | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
| updated_at     | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
+----------------+------------------+------+-----+---------------------+----------------+

ごく簡単な構成です。しかし、実際にはユーザーはすでに退会したかとか、問題があるユーザーをブロックする必要がある、のような理由で、有効・無効のフラッグをつけるのが一般的です。

ということで、active_flagとしてusersのフィールドを追加してみましょう。このactive_flagは、char(1)として有効はY、無効はNの値とします。

migrationを作成して、以下のように編集して実行。

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

class AddActiveFlagToUsers extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function ($table) {
            $table->char('active_flag', 1)->after('id');
        });
    }
...
}

さて、今度は認証のプログラムの変更です。ユーザーのログインとパスワードがマッチかつユーザーが有効のときだけに認証を成功としたいです。さて、どこを変更すればよいのでしょうか？

これは以下のAuthController.phpにトレイトで定義されているメソッドの追加となります。

namespace App\Http\Controllers\Auth;

use App\User;
use Validator;
use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ThrottlesLogins;
use Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers;
use Illuminate\Http\Request;

class AuthController extends Controller
{
    use AuthenticatesAndRegistersUsers, ThrottlesLogins {
        getCredentials as getCredentialsTrait;
    }

    public function __construct()
    {
        $this->middleware('guest', ['except' => 'getLogout']);

        $this->maxLoginAttempts = 5;
        $this->lockoutTime = 60;
    }

    protected function getCredentials(Request $request)
    {
        $credentials = $this->getCredentialsTrait($request);

        $credentials['active_flag'] = 'Y';

        return $credentials;
    }
    ...

getCredentialsは、AuthenticateAndRegistsUsersトレイトの中で使用されているAuthenticatesUsersのトレイト。以下を参照してください。

ユーザー認証（３）ログイン・ログアウト

ここで同じ名前のメソッドを使用して、クレデンシャルにユーザーが有効、つまり　active_flag => ‘Y’という条件を追加したいです。しかし、ここではまず、すでに定義されているgetCredentialsの関数をコールしてからの追加としたい。問題は、

これでは、再帰となるし、

$credentials = $this->getCredentials($request);

スタテックのメソッドでも、継承したクラスのメソッドでもないのでこうともできない。

$credentials = parent::getCredentials($request);

それゆえに、

    use AuthenticatesAndRegistersUsers, ThrottlesLogins {
        getCredentials as getCredentialsTrait;
    }

として、オリジナルのメソッド名を改名して、

$credentials = $this->getCredentialsTrait($request);

となったわけです。

ユーザー認証（７）スロットルのユニットテスト

Sun, 20 Dec 2015 07:30:44 +0900

前回話したログインのスロットル機能。もちろん手動、つまりブラウザ、で確認はできます。しかし、手動ではいちいち面倒ですね。自動で動作を確認できたらもっと良いです。そこで登場するのがユニットテスト。難しくはないです。チェックしたいのは、

パスワードが正しいときのログインが成功するかのテスト
パスワードを間違えて、失敗回数がデフォルトの５回となったときに、スロットされるかのテスト
その後デフォルトの６０秒待って、パスワードが正しいときに成功するかのテスト

他にもいくつか考えられますが、最低限は以上としてテストを作成してみましょう。

注意：パスワードには理解しやすいように日本語としていますが、実際は英数字が一般的です。

class LoginTest extends TestCase
{
    public function testLoginSuccess()
    {
        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('保存')
            ->see('ホームページ');
    }

    public function testLoginThrottle()
    {
        for($i=1;$i <=5; $i++)
        {
            $this->visit('/auth/login')
                ->type('test@gmail.com', 'email')
                ->type('間違ったパスワード', 'password')
                ->press('ログイン')
                ->see('Eメールとパスワードにマッチするレコードがありません。');
        }

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('間違ったパスワード', 'password')
            ->press('ログイン')
            ->see('ログインの失敗回数が設定を超えました。次回のログインまで６０秒お待ちください。');

        sleep(10);

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('ログイン')
            ->see('ログインの失敗回数が設定を超えました。');

        sleep(50);

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('ログイン')
            ->see('ホームページ');
    }
}

最初のテスト、testLoginSuccessは、正しいパスワードを入力したときのテストで、その後「ホームページ」という文が入ったページへ行くとする仮定。

次のtestLoginThrottleは、スロットルされるまでの失敗回数の確認とスロットル解除の確認のテスト。まず間違ったパスワードを入れて５回失敗させます。画面には、「Eメールとパスワードにマッチするレコードがありません」のエラーメッセージが表示されます。その後、さらに失敗すると、今度はログインをスロットルしたメッセージが表示されます。ここから６０秒経過しないと次のログインができません。確認のために１０秒後に正しいパスワードでログインしてみましょう。そこでは、さらに「ログインの失敗回数が設定を超えました。」を含むエラーメッセージがでます。残りの秒数は誤差が出ると思うので、その部分の確認はしません。そして、５０秒後（つまり、スロットル開始から６０秒後）には、正しいパスワードでログインが成功となるはずです。

さて、ここで注意です。Laravelに含まれるphpunitのテストの設定ファイルは、以下の内容です。

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="bootstrap/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Application Test Suite">
            <directory>./tests/</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist>
            <directory suffix=".php">app/</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
    </php>
</phpunit>

前回話したように、ログイン失敗回数や現在スロットルされていることなどの情報は、デフォルトではファイルを使用して行っています。しかし、テストでは CACHE_DRIVERは配列設定となっています。私のテストでは、そのためか上のテストはスロットル期間終了後に成功とはなりませんでした。どうも残りの秒数のカウントが負となっていしまい、うまくいかない。

この設定をphpunit.xmlでarrayからfileあるいはdatabaseに変更とすると、うまく行きました。

ユーザー認証（６）ログインスロットル

Sun, 13 Dec 2015 03:58:30 +0900

スロットルと聞くと、どうしてもバイクのアクセルを想像してしまいます。どちらかというとスピードを出すために。スロットルは正確にはスピードを抑圧する意味で、「スロットル全開」というと、抑制なしで最高のスピードを出すということになります。

ここでのスロットルは、パスワードを意図的に変えて不正にログインしようという試み、たいていはプログラムによる機械的な攻撃、を抑える目的のセキュリティ対策です。具体的には、例えば過去５分間に５回ログインを失敗すると、次回のログインには１０分間待たなければならないという仕組みです。もちろんそれですべて防御できるとは言えないですが、少なくとも抑制にはなります。

嬉しいことにこれも、Laravelに機能があります。

スロットル機能はログインで行われるので、以前に説明したログインのプログラムを再度見てみましょう。

まず、AuthControler。

app/Http/Controllers/Auth/AuthController.php

namespace App\Http\Controllers\Auth;

use App\User;
use Validator;
use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ThrottlesLogins;
use Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers;

class AuthController extends Controller
{
    use AuthenticatesAndRegistersUsers, ThrottlesLogins;

    ...

ThrottlesLoginsのトレイトがありますね。そして、AuthenticatesAndRegistersUsersのトレイトの定義で使用されている、AuthenticatesUsersのトレイト、以前の紹介ではスロットルの部分を省略したので、今度はそこの部分を含めて見てみましょう。以下のコードのコメントを見てください。

vendors/framework/src/Illuminate/Foundation/Auth/AuthenticateUsers.php

namespace Illuminate\Foundation\Auth;
use Illuminate\Http\Request;ろぐ
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Lang;

trait AuthenticatesUsers
{
    use RedirectsUsers;

    ...

    public function postLogin(Request $request)
    {
        $this->validate($request, [
            $this->loginUsername() => 'required', 'password' => 'required',
        ]);

        // ThrottlesLoginsは、上のAuthControllerのトレイトして使われているから、$throttleには値を含みます。
        $throttles = $this->isUsingThrottlesLoginsTrait();

　　　　//ここで指定のログインの失敗回数を超えているなら、
       //画面にエラーメッセージを表示して次のログインを指定の時間待たせます。
        if ($throttles && $this->hasTooManyLoginAttempts($request)) {
            return $this->sendLockoutResponse($request);
        }

        //入力の値でログインを試みます。
        $credentials = $this->getCredentials($request);
        if (Auth::attempt($credentials, $request->has('remember'))) {
            return $this->handleUserWasAuthenticated($request, $throttles);
        }

　　　　//ログインが失敗なら、ログインの失敗回数を１増やします。
        if ($throttles) {
            $this->incrementLoginAttempts($request);
        }
        return redirect($this->loginPath())
            ->withInput($request->only($this->loginUsername(), 'remember'))
            ->withErrors([
                $this->loginUsername() => $this->getFailedLoginMessage(),
            ]);
    }
 
    ...
}

というようにログインの失敗回数を追跡しています。

さて、何回まで失敗とか失敗回数を超過したら何分ログインを許さないかはどこで指定されているのでしょう。今度はトレイトのThrottleLoginsを見てみましょう。

vendors/framework/src/Illuminate/Foundation/Auth/ThrottleLogins.php

namespace Illuminate\Foundation\Auth;
use Illuminate\Http\Request;
use Illuminate\Cache\RateLimiter;
use Illuminate\Support\Facades\Lang;

trait ThrottlesLogins
{
    //ここです、失敗回数をチェックしているのは。
    protected function hasTooManyLoginAttempts(Request $request)
    {
        return app(RateLimiter::class)->tooManyAttempts(
            $request->input($this->loginUsername()).$request->ip(),
            $this->maxLoginAttempts(), $this->lockoutTime() / 60
        );
    }

    ...

    protected function maxLoginAttempts()
    {
        return property_exists($this, 'maxLoginAttempts') ? $this->maxLoginAttempts : 5;
    }

    protected function lockoutTime()
    {
        return property_exists($this, 'lockoutTime') ? $this->lockoutTime : 60;
    }
}

最初のhasTooManyLoginAttemptsのメソッドでは、maxLoginAttemptsとlockoutTimeのメソッドがコールされていますね。

それぞれ、ここのクラスのインスタンスで、maxLoginAttemptsとlockoutTimeの変数が定義されているなら、その値を使いますが、定義なしでは、最高５回、ログインロックは６０秒という設定です。

また、失敗回数は、ログイン＋IPアドレスの値がキーとなっています。つまり、同じログインで同じIPからログインを試みて連続５回失敗したら、１分のログインロックとなるということです。

最後に、これらの失敗回数の追跡やロックアウトの保持のデータは、どこで管理しているのでしょう。

先のコードで以下の参照をみてください。

use Illuminate\Cache\RateLimiter;

Cacheとして管理しているようです。Laravelでは、Cacheはデフォルトでファイルで管理しています。しかし、ファイルではなくデータベースや高速なメムキャッシュでのデータの管理も可能です。

config/cache.phpにおいて設定するか、.envにおいて、

CACHE_DRIVER=database

と設定することも可能です。データベースと設定するなら、以下のようにmigrationを通して、

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

class CreateCacheTable extends Migration
{
    public function up()
    {
                Schema::create('cache', function($table) {
                        $table->string('key')->unique();
                        $table->text('value');
                        $table->integer('expiration');
                });
    }

    public function down()
    {
        //
    }
}

としてcacheテーブルを作成してください。ここで以下のようにデータベースの中身を見ながらテストをすると、実際どのようなレコードが作成されるかわかります。

例えば、ログインに失敗すると、以下のようなレコードが作成されます。

mysql> select * from cache\G;
*************************** 1. row ***************************
       key: laraveltest@gmail.com66.87.77.84
     value: eyJpdiI6IlJQN1Awck9BVzlTWXdnMk4wb0ZOMnc9PSIsInZhb...
expiration: 1449946110
*************************** 2. row ***************************
       key: laraveltest@gmail.com66.87.77.84:lockout
     value: eyJpdiI6Im5pMmg0dm1iREl0TFIwNkkzZTV1V2c9PSIsInZhb...
expiration: 1449946259
2 rows in set (0.00 sec)

最初のレコードは、失敗回数を数えているレコードです。キー(key)として、Eメールアドレス＋IPアドレスとなっています。キーの値（value）は暗号化されています。回数が設定を超えると、２番目のレコードが作成されます。キーの最後に:lockoutが追加されていることに注意してください。こちらのレコードの期限は、設定のブロック時間（デフォルトは６０秒）を経過した日時となっています。期限が過ぎてアクセスしたときに、これらのレコードは削除されて再度、失敗回数を追跡してきます。

ユーザー認証（５）パスワードリセット

Sun, 06 Dec 2015 07:47:28 +0900

ユーザーログインがあるなら、パスワードを忘れることがあるのは当然。忘れたらなら、通常はログイン（たいていはEメール）を入力して、パスワードのリセットのリンクを受け取り、リンク先の画面で新規のパスワードを設定します。新しいパスワードを作成して送信してくるサイトもあります。しかし、良く利用するサイトなら、やはり自分が覚えられるパスワードを設定したいです。

そう、この機能もLaravelで提供しています。

まずは、この機能に必要なものをリスト。

パスワードリセットリンクを送信してもらう画面
パスワードリセットリンクを含むメールのテンプレート
送信するパスワードリセットリンクの有効期限を設定し保持するDBテーブル
パスワードリセットリンク先の画面で、新規パスワードを設定する画面

以上です。

パスワードリセットリンクを送信してもらう画面

routes.phpの設定から見てみましょう。

Route::get('password/email','Auth\PasswordController@getEmail');
Route::post('password/email', 'Auth\PasswordController@postEmail');

PasswordController.phpは、AuthController.phpと同様にlaravelインストール時に app/Http/Controllers/Authに存在します。

中身は以下にあるように、これまたAuthController.phpと同様にトレイトで構成されているのでほぼ空状態。

namespace App\Http\Controllers\Auth;

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

class PasswordController extends Controller
{
    use ResetsPasswords;

    public function __construct()
    {
        $this->middleware('guest');
    }
}

ミドルウェアguestが使用されているので、すでにログインしているなら使用できません。

テンプレートは、reources/views/auth/password.blade.phpのファイルとします。

<form method="POST" action="{!! url() !!}/password/email">
    {!! csrf_field() !!}

    <div>
        Eメール
        <input type="email" name="email" value="{{ old('email') }}">
    </div>

    <div>
        <button type="submit">パスワードリセットリンクを送信</button>
    </div>
</form>

これで画面の表示までは完了。次は、送信ボタンを押したときの処理。以下の３つ作業が必要です。

入力バリデーション。Eメールのフォーマットのチェックだけでなく、ユーザーとしてそのEメールがDBに存在するかのチェック
ユニークなトークンを発行し、EメールとともにDBに保存
パスワードリセットの画面のURLとトークンを合わせてリンクとして、ユーザーのEメールに送信

この３つの作業が行われているか、PasswordControllerで使用されるトレイトのResetsPasswordsを見てみましょう。

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

namespace Illuminate\Foundation\Auth;
use Illuminate\Http\Request;
use Illuminate\Mail\Message;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Password;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

trait ResetsPasswords
{
    public function getEmail()
    {
        return view('auth.password');
    }

    public function postEmail(Request $request)
    {
        $this->validate($request, ['email' => 'required|email']);
        $response = Password::sendResetLink($request->only('email'), function (Message $message) {
            $message->subject($this->getEmailSubject());
        });
        switch ($response) {
            case Password::RESET_LINK_SENT:
                return redirect()->back()->with('status', trans($response));
            case Password::INVALID_USER:
                return redirect()->back()->withErrors(['email' => trans($response)]);
        }
    }
　　...

postEmailがあり画面の入力を受け取り処理しています。入力したEメールのバリデーションがあります。しかしここでは、その他の作業は皆、Password::sendRsetLinkに任せています。もうちょっと追及してみましょう。

Password::sendResetLinkは、PasswordのクラスはFacadeで、実際は以下のPasswordBrokerのクラスが使用されています。sendResetLinkの定義がありますね。

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

namespace Illuminate\Auth\Passwords;
use Closure;
use UnexpectedValueException;
use Illuminate\Contracts\Auth\UserProvider;
use Illuminate\Contracts\Mail\Mailer as MailerContract;
use Illuminate\Contracts\Auth\PasswordBroker as PasswordBrokerContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;

class PasswordBroker implements PasswordBrokerContract
{
    protected $tokens;
    protected $users;
    protected $mailer;
    protected $emailView;
    protected $passwordValidator;

    public function __construct(TokenRepositoryInterface $tokens,
                                UserProvider $users,
                                MailerContract $mailer,
                                $emailView)
    {
        $this->users = $users;
        $this->mailer = $mailer;
        $this->tokens = $tokens;
        $this->emailView = $emailView;
    }

    public function sendResetLink(array $credentials, Closure $callback = null)
    {
        $user = $this->getUser($credentials);
        if (is_null($user)) {
            return PasswordBrokerContract::INVALID_USER;
        }
        $token = $this->tokens->create($user);
        $this->emailResetLink($user, $token, $callback);
        return PasswordBrokerContract::RESET_LINK_SENT;
    }

    public function emailResetLink(CanResetPasswordContract $user, $token, Closure $callback = null)
    {
        $view = $this->emailView;
        return $this->mailer->send($view, compact('token', 'user'), function ($m) use ($user, $token, $callback) {
            $m->to($user->getEmailForPasswordReset());
            if (! is_null($callback)) {
                call_user_func($callback, $m, $user, $token);
            }
        });
    }
...

$this->getUserでDBテーブルusersに入力したEメールのレコードを取得して、$this->tokens->createでトークンを作成しDBに保存し、$this->emailResetLinkでパスワードリセットリンクを含むメールを送信します。マッチするDBレコードが存在しないならエラーコードを返して画面にエラーを表示となります。

ここにおいてメール送信に関していくつか。

まず、メール送信が行われるので、.envにおいてMAIL_DRIVERなどの設定が必要です。さらに、config/mail.phpにおいて、fromの設定が必要です。

...
   'from' => ['address' => null, 'name' => null],
...

上のnullには、例えば、‘support@gmail.com’、‘サポート’のような具体的な値に置き換える必要あります。

次に、送信メールのテンプレートをresources/views/emails/password.blade.phpとして作成する必要あります。

以下のリンクをクリックして、パスワードのリセットができます。

{{ url('password/reset/'.$token) }

パスワードリセットリンク先の画面で、新規パスワードを設定する画面

さて、次はこのリンク先のパスワードリセット画面です。

まずは、routes.phpの設定から、

Route::get('password/reset/{token}', 'Auth\PasswordController@getReset');
Route::post('password/reset', 'Auth\PasswordController@postReset');

こちらもまた、PasswordControllerですね。

テンプレートは、reources/views/auth/reset.blade.phpのファイルとします。hiddenのtokenを忘れなく。

<form method="POST" action="{!! url() !!}/password/reset">
    {!! csrf_field() !!}
　　　<input type="hidden" name="token" value="{{ $token }}">
    <div>
        Eメール
        <input type="email" name="email" value="{{ old('email') }}">
    </div>

    <div>
        パスワード
        <input type="password" name="password">
    </div>

    <div>
        パスワードの確認
        <input type="password" name="password_confirmation">
    </div>

    <div>
        <button type="submit">パスワードをリセット</button>
    </div>
</form>

さて、この画面でボタンをクリックしたときの処理は、

入力バリデーション。Eメールやパスワードの値チェック。EメールがDBに存在するかのチェック
DBのパスワードの値を暗号化して更新

でしょうか？見てみましょう。

まずは、先ほど出てきたトレイトのResetPasswords.php

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

...
    public function getReset($token = null)
    {
        if (is_null($token)) {
            throw new NotFoundHttpException;
        }
        return view('auth.reset')->with('token', $token);
    }
..
    public function postReset(Request $request)
    {
        $this->validate($request, [
            'token' => 'required',
            'email' => 'required|email',
            'password' => 'required|confirmed|min:6',
        ]);
        $credentials = $request->only(
            'email', 'password', 'password_confirmation', 'token'
        );
        $response = Password::reset($credentials, function ($user, $password) {
            $this->resetPassword($user, $password);
        });
        switch ($response) {
            case Password::PASSWORD_RESET:
                return redirect($this->redirectPath())->with('status', trans($response));
            default:
                return redirect()->back()
                            ->withInput($request->only('email'))
                            ->withErrors(['email' => trans($response)]);
        }
    }
...

入力バリデーションには、トークンが必須ですね。そして、Password::resetで処理を行い、その結果$responseが成功なら、指定のページにリダイレクト。エラーなら、同画面でエラー表示。

Password::resetの中身ですね、問題は。

こちらも、先のPasswordResetBroker.phpでコードされています。

vendor/laravel/framework/src/Illuminate/Auth/Passwors/PasswordResetBroker.php

...
    public function reset(array $credentials, Closure $callback)
    {
         $user = $this->validateReset($credentials);
        if (! $user instanceof CanResetPasswordContract) {
            return $user;
        }
        $pass = $credentials['password'];

        call_user_func($callback, $user, $pass);
        $this->tokens->delete($credentials['token']);
        return PasswordBrokerContract::PASSWORD_RESET;
    }

    protected function validateReset(array $credentials)
    {
        if (is_null($user = $this->getUser($credentials))) {
            return PasswordBrokerContract::INVALID_USER;
        }
        if (! $this->validateNewPassword($credentials)) {
            return PasswordBrokerContract::INVALID_PASSWORD;
        }
        if (! $this->tokens->exists($user, $credentials['token'])) {
            return PasswordBrokerContract::INVALID_TOKEN;
        }
        return $user;
    }

    public function validateNewPassword(array $credentials)
    {
        list($password, $confirm) = [
            $credentials['password'],
            $credentials['password_confirmation'],
        ];
        if (isset($this->passwordValidator)) {
            return call_user_func(
                $this->passwordValidator, $credentials) && $password === $confirm;
        }
        return $this->validatePasswordWithDefaults($credentials);
    }
...

resetでは、$this->validateResetで、ユーザーレコードの有無。新規パスワードのバリデーション、そしてトークンの存在と有効期限内かのチェックを行い、callbackでDBレコードのパスワードの更新を行います。そして最後に使用したトークンの削除となります。なるほど、削除しないと再度のリセットが可能になるので必要なわけですね。

ユーザー認証（４）認証でページを保護

Sun, 29 Nov 2015 07:46:38 +0900

ユーザー認証の目的は、ユーザー本人であることを確認し、ユーザーのプライベートの情報を他に見られることを防ぐことです。

Laravelでは、アプリにおけるすべてのルートを設定するroutes.phpのファイルにおいて、ミドルウェアを利用して保護するページを指定します。

app/Http/routes.php

Route::get('/home', ['middleware' => 'auth', function () {
    return view('auth.home');
}]);

上の例では、/homeを保護するために、ミドルウェアのauthを使用しています。authは、以下のKernel.phpで登録されているサービスです。

app/Http/Kernel.php

namespace App\Http;
use Illuminate\Foundation\Http\Kernel as HttpKernel;
class Kernel extends HttpKernel
{
    protected $middleware = [
 　 ...
    ];

    protected $routeMiddleware = [
        'auth' => \App\Http\Middleware\Authenticate::class,
        'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
        'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
    ];
}

そこでバインドされているクラスは、以下のAuthenticate.phpで定義されています。

app/Http/Middleware/Authenticate.php

namespace App\Http\Middleware;
use Closure;
use Illuminate\Contracts\Auth\Guard;
class Authenticate
{
    protected $auth;

    public function __construct(Guard $auth)
    {
        $this->auth = $auth;
    }

    public function handle($request, Closure $next)
    {
        if ($this->auth->guest()) {
            if ($request->ajax()) {
                return response('Unauthorized.', 401);
            } else {
                return redirect()->guest('auth/login');
            }
        }
        return $next($request);
    }
}

handle()内での、$this->auth->guest()は、ユーザーがゲスト、つまり認証されていないユーザーであるかどうかをチェックします。認証されていないなら、auth/loginにリダイレクトして、ログイン画面が表示されます。

routes.phpでのページ保護は、Route::groupで行うこともできます。例えば、以下のように複数のルートをまとめることができます。わかりやすいですね。

Route:: group(['prefix' => 'member', 'middleware' => 'auth'], function() {
    Route::get('index', 'MemberController@getIndex');
    Route::get('password', 'MemberController@getPassword');
    Route::post('password', MemberController@postPassword');
    Route::get('profile', 'MemberController@getProfile');
    Route::post('profile', 'MemberController@postProfile');
    Route::get('logout', 'MemberController@getLogout');
});

さらに、認証の保護しないページにおいて、すでに認証されているならスキップしてリダイレクトさせることも可能です。以下では、ログインや登録画面にアクセスしたときにすでにログインしているなら、/homeにリダイレクトされます。ミドルウェアにおいて、guestが使用されていることに注意してください。このミドルウェアも先のKernel.phpで登録されています。

Route::group(['middleware' => 'guest'], function() {
    Route::get('login', 'LoginController@getLogin');
    Route::post('login', 'LoginController@postLogin');
    Route::get('signup', 'SignupController@getSignup');
    Route::post('signup', 'SignupController@postSignup');
});

これらのミドルウェアは、routes.phpだけでなくコントローラの中でも実行できます。例えば、前回まで使用してきたAuthController.php。

namespace App\Http\Controllers\Auth;

use App\User;
use Validator;
use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ThrottlesLogins;
use Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers;

class AuthController extends Controller
{
    use AuthenticatesAndRegistersUsers, ThrottlesLogins;

    public function __construct()
    {
        $this->middleware('guest', ['except' => 'getLogout']);
    }

　　...
}

guestのミドルウェアをコンストラクタで使用することにより、ログアウト(getLogout)以外のメソッド、つまり会員登録（getRegisterとpostRegister）とログイン（getLoginとpostLogin)のメソッドにおいて、すでにログインしているなら/homeにリダイレクトします。

ユーザー認証（３）ログイン・ログアウト

Sun, 22 Nov 2015 06:58:31 +0900

前回のユーザー登録では、登録後は自動的に認証され、ユーザーはあたかもすでにログインしたような状態となります。

しかし、デフォルトの設定の２時間のアイドルを過ぎると、ログアウトされてしまいます。そうなると必要なのはユーザー認証のためのログイン画面です。

ログイン画面に必要なのは、

app/Http/Controllers/AuthController.php

のコントローラ。前回にはこのコントローラは、登録画面に使われましたが、コントローラ中の以下のトレイトの使用により、

use AuthenticatesAndRegistersUsers

さらに、

そのトレイトの定義で使われているトレイト、

use AuthenticatesUsers

により、ログインが機能します。その定義を見てみましょう。以下のコードは説明のために、ログインスロットルなどの部分を省いています。

namespace Illuminate\Foundation\Auth;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Lang;

trait AuthenticatesUsers
{
    use RedirectsUsers;

    // ログイン画面の表示
    public function getLogin()
    {
        // app/resources/views/auth/authenticate.blade.phpがあるならそれを使用
        if (view()->exists('auth.authenticate')) {
            return view('auth.authenticate');　
        }

        // authenticate.blade.phpがないなら、login.blade.phpを使用
        return view('auth.login');
    }

　　//　ログインボタンを押したら以下を実行
    public function postLogin(Request $request)
    {
        // 入力バリデーション
        $this->validate($request, [
            $this->loginUsername() => 'required', 'password' => 'required',
        ]);

        $credentials = $this->getCredentials($request);

        if (Auth::attempt($credentials, $request->has('remember'))) {
　　　　　　 //　認証成功後の処理：リダイレクトとか
            return $this->handleUserWasAuthenticated($request);
        }

　　　　//　認証失敗なら、ログイン画面にエラーを表示
        return redirect($this->loginPath())
            ->withInput($request->only($this->loginUsername(), 'remember'))
            ->withErrors([
                $this->loginUsername() => $this->getFailedLoginMessage(),
            ]);
    }

    // 認証成功後の処理。目的の画面にリダイレクト
    protected function handleUserWasAuthenticated(Request $request)
    {
        if (method_exists($this, 'authenticated')) {
            return $this->authenticated($request, Auth::user());
        }
        return redirect()->intended($this->redirectPath());
    }

　　// ユーザーのクレデンシャル、つまりemailとpasswordをゲット
    protected function getCredentials(Request $request)
    {
        return $request->only($this->loginUsername(), 'password');
    }
    
    //　ログアウト、つまりクッキーの削除。そしてリダイレクト。デフォルトはルートディレクトリへ
    public function getLogout()
    {
        Auth::logout();
        return redirect(property_exists($this, 'redirectAfterLogout') ? $this->redirectAfterLogout : '/');
    }
    
　　...

postLogin()では、入力バリデーションの後に、Auth::attemptが実行されます。そこでは、config/auth.phpで指定したドライバー（Eloquent)を使用して、DBにEメールと暗号化されたパスワードがマッチするかどうかチェックして結果を返します。マッチしたなら、そこでセッションを作成して認証された事実を残します。認証関連のイベントでフックされているコードもそこで実行されます。

その後に実行される、handleUserWasAuthenticated()では、redirect()->intended()により、アクセスを試みた初期のURLへリダイレクトします。

例えば、認証以前に、

http://localhost/demo-auth/public/password/edit

へアクセスを試みると、まず認証のためにログイン画面へリダイレクトされて、ログイン成功後には、上のURLへ自動的に移動します。デフォルトでは、$this->redirectPath()へ移行します。

ログアウトは、ログインのようにボタンとかは必要とせずに、現在ログインしているならログアウトのURLにアクセスするだけで、ログインのセッションを無効とします。get Login()のAuth::logout()がその処理を行います。

上記のコントローラで使用されるテンプレート、login.blade.phpには、以下のようなフォームが含まれます。

<form method="POST" action="/auth/login">
    {!! csrf_field() !!}

    <div>
        Eメール
        <input type="email" name="email" value="{{ old('email') }}">
    </div>

    <div>
        パスワード
        <input type="password" name="password" id="password">
    </div>

    <div>
        <input type="checkbox" name="remember"> 次回から入力を省略
    </div>

    <div>
        <button type="submit">ログイン</button>
    </div>
</form>

さて、これでログイン画面は動作しますが、このフォームで使用される「次回から入力を省略」のチェックボックスは何でしょう？

ここがオフでは、ログインのセッションは２時間で時間切れとなり、再度ログインが必要となります。ここをオンとしてログインが成功となると現在の設定では５年間は、ログインなしで認証が必要な画面へのアクセスが可能となります。Laravelではセキュリティを上げるために、ここがオンのときはトークンを作成してDBに保存し、クッキーの値とマッチするかのチェックを行っています。

さて、ユーザーの認証の部分ができたところで、次回は、どうやってLaravelがこの認証の情報をもとにプライベート画面を保護するかを見てみましょう。

ユーザー認証（２）ユーザーの登録

Sun, 15 Nov 2015 10:39:11 +0900

ユーザーの登録は、重複回避ーDB重複エラーで、一部分紹介しました。ここでは、一部と言わず全部をカバーしてみましょう。しかも、ララベル5.1がサンプルとして提供するプログラムをもとに。

ララベルが提供するユーザー認証のサンプルは、ララベルの作者、テイラーが作成したプログラムでありますが、すべてのパーツが揃っていて、親切な説明がなされているというものではありません。コントローラで使用するブレイドのファイルもないし、ブレイドのファイル名やパス名もドキュメントにはありません。また、プログラムでは、トレイトが多用されているために、まず参照されているファイルを見て、次の参照ファイルを見て、さらに次へ・・という、理解には探偵作業が必要です。ちょっと腰を据えて取り組んでみましょう。

まず、最前線のファイルのリストから、

app/Http/routes.php
app/Http/Controllers/Auth/AuthController.php

そう、これだけなのです。もちろんブレイドファイルも作成する必要ありますが、これだけでユーザーの登録とログイン画面ができてしまいます。それぞれ中身を見てみましょう。

まず、routes.php。これは、画面でアクセスするプログラムの回路図のようなもので、ここでURLとコントローラを結びつけます。

app/Http/routes.php

// 会員登録
Route::get('auth/register', 'Auth\AuthController@getRegister');
Route::post('auth/register', 'Auth\AuthController@postRegister');

// ログイン・ログアウト
Route::get('auth/login', 'Auth\AuthController@getLogin');
Route::post('auth/login', 'Auth\AuthController@postLogin');
Route::get('auth/logout', 'Auth\AuthController@getLogout');

//会員登録後、ログイン後に飛ばされるホーム画面
Route::get('/home', function () {
    return view('auth.home');
});

次に、AuthController.php。このひとつで会員登録とログインをやってしまいます。いったいどうやっているのか見てみましょう。（オリジナルの英語のコメントはスペースのために省いています）

app/Http/Controllers/Auth/AuthController.php

namespace App\Http\Controllers\Auth;

use App\User;
use Validator;
use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\ThrottlesLogins;
use Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers;

class AuthController extends Controller
{
    use AuthenticatesAndRegistersUsers, ThrottlesLogins;

    public function __construct()
    {
        // ログアウト以外は、guestのミドルウェアを通す。
　　　　// ここですでに認証されているかどうかを判断。
        $this->middleware('guest', ['except' => 'getLogout']);
    }

　　//　入力チェックのルーチン
    protected function validator(array $data)
    {
        return Validator::make($data, [
            'name' => 'required|max:255',
            'email' => 'required|email|max:255|unique:users',
            'password' => 'required|confirmed|min:6',
        ]);
    }

　　//　DBにレコードを作成。
    protected function create(array $data)
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
        ]);
    }
}

これを最初に見て思うのは、routes.phpで使用されているコントローラのメソッドはどこにある？？

getRegister postRegister getLogin postLogin getLogout

これらのメソッドのことです。もしかして、Controllerのクラスを継承しているので、Controller.phpで定義されている？しかし、そちらはもっと短い（以下）！

app/Http/Controller.php

namespace App\Http\Controllers;

use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Routing\Controller as BaseController;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Foundation\Auth\Access\AuthorizesRequests;

abstract class Controller extends BaseController
{
    use AuthorizesRequests, DispatchesJobs, ValidatesRequests;
}

それならいったいどこで？と探偵作業の始まりです。

となると、AuthController.phpの１３行目のトレイト？

use AuthenticatesAndRegistersUsers

見てみましょう。

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

namespace Illuminate\Foundation\Auth;
trait AuthenticatesAndRegistersUsers
{
    use AuthenticatesUsers, RegistersUsers {
        AuthenticatesUsers::redirectPath insteadof RegistersUsers;
    }
}

またしてもトレイト！

use AuthenticateUsers, RegisterUsers

RegisterUsers.phpを見てみましょう（ログイン関連は、AuthenticateUsers.phpですがそれは次回に）。

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

namespace Illuminate\Foundation\Auth;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
trait RegistersUsers
{
    use RedirectsUsers;

    public function getRegister()
    {
        return view('auth.register');
    }

    public function postRegister(Request $request)
    {
        $validator = $this->validator($request->all());
        if ($validator->fails()) {
            $this->throwValidationException(
                $request, $validator
            );
        }
        Auth::login($this->create($request->all()));
        return redirect($this->redirectPath());
    }
}

これですね、探していたのは！

getRegisterでは、auth.registerがブレードの場所ということわかります。つまり、

resources/views/auth/register.blade.php

を作成すれば、会員登録の画面ができあがりです。

postRegisterの関数では、先にAuthController.phpで定義した、validatorとcreateがここで参照されていますね。

Auth::login($this->create($request->all()));

ここでは、DBレコードを作成して返される、Userのインスタンスをもとに、ログインも行っていしまいます。つまり、登録したら自動ログインして、ホームにリダイレクトということです。

しかし、いったいどこへリダイレクト？

それも、もちろんRedirectUsersのトレイトなのです。

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

namespace Illuminate\Foundation\Auth;

trait RedirectsUsers
{
    public function redirectPath()
    {
        if (property_exists($this, 'redirectPath')) {
            return $this->redirectPath;
        }

        return property_exists($this, 'redirectTo') ? $this->redirectTo : '/home';
    }
}

デフォルトは、/homeですね。また、Authocontrollerにおいて、redirectToの上書きも可能ということです。

最後に、登録画面のブレードファイルには、以下のようなHTMLがあればOKです。

<form method="post" action="auth/register">
{!! csrf_field() !!}
  <div>
    ログイン:
    <input type="email" name="email" value="{{ old('email') }}" required autofocus>
  </div>
  <div>
     パスワード:
     <input type="password" name="password" required>
  </div>
  <div>
     パスワードの確認:
     <input type="password" name="password_confirmation" required>
  </div>
  <div>  
     名前:
     <input type="text" name="name" value="{{ old('name') }}" required>
  </div>
  <div>
     <button type="submit">保存</button>
  </div>
</form>

次回は、ログインの方を深く見てみましょう。

ユーザー認証（１）下準備

Mon, 09 Nov 2015 05:52:53 +0900

ララベルを使用したユーザー認証のプログラムを紹介していきます。

ユーザー認証と言っても、いろいろ考えることがたくさんあります。

認証の対象としては、フロントエンドとして会員認証のためのログインがあるし、フロントエンドがあればもちろんバックエンドがあり、そこでは会員と違う管理者を認証する必要もあります。また、最近ではFacebookやTwitterなどのソーシャルウェブサイトのログインを自分のウェブサイトの会員認証のために利用することも可能です。

また、ユーザー認証に関わる機能としては、

と、いろいろあります。どれもアプリの開発には必要な機能です。

嬉しいことに、ララベルでは、画面のテンプレートファイル（ブレード）以外は、これらの機能をカバーするプログラムがほとんど揃っています。今回からこれらの機能を見ていきましょう。

アプリの設定

まず、このためにララベルのプロジェクトを作成します。新プロジェクトの名前は、demo-auth。以下をコマンドラインで実行してください。

laravel new demo-auth

あるいは、

~/.composer/vendor/bin/laravel new demo-auth

次にデータベースを作成してください。mysql, sqlite、pgsqlなどお好きなものでDBを作成してください。

DB作成後は、設定ファイルの編集です。まず、サンプルの設定ファイルを改名して、この環境でのアプリの設定ファイルとします。

mv .env.example .env

.envのファイルで編集が必要なのは今のところ、以下のＤＢ設定の部分です。

DB_HOST=localhost
DB_DATABASE=データベースの名前
DB_USERNAME=データベースユーザーの名前
DB_PASSWORD=データベースのパスワード

その後、以下を実行してください。

php artisan key:generate

それにより、.envのファイルの

APP_KEY=SomeRandomString

の「SomeRandomString」に値が「s0IWRnfPlNAiPl7Bwl1MX8V7i14loYyK」のようなランダム値に変更されます。この値は、アプリのすべての暗号化に使用されるので、一度設定したら２度と変えないように。

これで環境の準備は完了です。

DBテーブルの作成

この作業には、すでにdemo-authディレクトリで作成された以下のファイルが重要となります。これらをまず見てみましょう。


app/User.php
config/auth.php

まず、２のconfig/auth.php

return [

　　// ドライバーにはエロクエントを使用します。オプションとしては、'database'も可能です。
    'driver' => 'eloquent',

　　// ドライバーでエロクエントを使用するなら、そのクラスをここで指定。ファイルは app/User.phpです。
　　// ::classは、namespaceとともにクラス名を返します。
    'model' => App\User::class,

　　// ドライバーがdatabaseならテーブル名を指定。
    'table' => 'users',

    // パスワードを忘れたときにリセットするための情報。
    // emailは、views/emails/password.blade.phpを送信するメールとテンプレート（作成必要あり）とします。
    // DBテーブルは、password_resetsを使います。
    // リセットのトークンは発行されてから６０分間で時間切れとなります。
    'password' => [
        'email'  => 'emails.password',
        'table'  => 'password_resets',
        'expire' => 60,
    ],
];

今回はドライバーにエロクエントを使用するので、モデルファイルのapp/User.phpを見てみましょう。

<?php

namespace App;

use Illuminate\Auth\Authenticatable;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Auth\Passwords\CanResetPassword;
use Illuminate\Foundation\Auth\Access\Authorizable;
use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract;
use Illuminate\Contracts\Auth\Access\Authorizable as AuthorizableContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;

class User extends Model implements AuthenticatableContract,
                                    AuthorizableContract,
                                    CanResetPasswordContract
{
    // このクラスの関数の定義は、以下のtraitを使用しています。
    use Authenticatable, Authorizable, CanResetPassword;

    // 「users」が使用するDBテーブルとなります。
    protected $table = 'users';

　　// これらが入力フィールドという仮定。
    protected $fillable = ['name', 'email', 'password'];

    // JSONで排除するフィールド名
    protected $hidden = ['password', 'remember_token'];
}

ということで、DBテーブルとして必要なのは、usersとpassword_resetsの２つとなります。実際のプロジェクトで、DBテーブル名や、テーブルのフィールド名に違いがあれば、これらが編集必要なファイルですね。

さて、それらのテーブルを定義しているのが、以下のファイル。


database/migrations/2014_10_12_000000_create_users_table.php
database/migrations/2014_10_12_100000_create_password_resets_table.php

それらは以下をコマンドラインで実行して作成します。

php artisan migrate

下準備は、以上で完了です。次は、会員登録画面、ログイン画面を作成します。

入力の空白文字のトリム（３）配列の入力値

Sun, 01 Nov 2015 06:38:36 +0900

今回は、「入力の空白文字のトリム」の最後です。

以下のようなフォームでは、入力の変数に配列を使用することできます。

<form>
...
<div>あなたの趣味を以下に記入してください：</div>
<ul>
  <li><input type="text" name="hobby[]" value=""></li>
  <li><input type="text" name="hobby[]" value=""></li>
...
</form>

これらがプログラムには、

hobby[0] = "映画鑑賞";
hobby[1] = "　読書";
hobby[2] = "テニス　";
..

という形で入ってきます。

しかし、前回のミドルウェアの定義では、このような配列には対応できませんので、以下のように書き直しました。

namespace App\Http\Middleware;

use Closure;

class TrimInput {

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $input = $request->all();

        $request->merge(self::trim($input));

        return $next($request);
    }

    public static function trim($value)
    {
        if (is_array($value))
        {
            $value = array_map(['self', 'trim'], $value);
        }
        elseif (is_string($value))
        {
            $value = preg_replace('/(^\s+)|(\s+$)/u', '', $value);
        }

        return $value;
    }
}

一見複雑そうに見えますが、それほどでもありません。まず、回帰を使用するためにトリムの関数を分けました。クラスメソッドとしています。他でも使用するなら自身のライブラリのメソッドとしてもよいです。そのトリムのメソッドでは、パラメが配列のときには回帰を使用して配列の個々の値をトリムします。

これに伴い、ユニットテストも書き換えました。

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class SignupTest extends TestCase
{
    use DatabaseTransactions;

    /**
     * @dataProvider providerTrimpInput
     */
    public function testTrimpInput2($data, $expected)
    {
        $input = [
            'email'                 => 'success@gmail.com',
            'password'              => 'testtest',
            'password_confirmation' => 'testtest',
            'last_name'             => $data['last_name'],
            'first_name'            => '太郎',
            'hobby'                 => $data['hobby']
        ];

        $this->visit('/signup')
            ->submitForm('保存', $input)
            ->see('会員登録完了');

        $member = \App\Member::where('email', 'success@gmail.com')->first();

        $this->assertEquals($expected['last_name'], $member->last_name);
        $this->assertEquals($expected['hobby'], unserialize($member->hobbies));
    }

    public function providerTrimpInput()
    {
        return [
            [ //半角スペース
                ['last_name' => ' 山田 ', 'hobby' => [' 映画鑑賞 ', ' 読書 ', '']],
                ['last_name' => '山田',   'hobby' => ['映画鑑賞', '読書', '']],
            ],
            [ //全角スペース
                ['last_name' => '　山田　', 'hobby' => ['　映画鑑賞　', '　読書　', '']],
                ['last_name' => '山田',     'hobby' => ['映画鑑賞', '読書', '']],
            ],

        ];
    }
}

前回のテストでは、

      $this->visit('/signup')
           ->type('success@gmail.com', 'email')
　　　...
　　　　　　->press('保存')
           ->see('会員登録完了')

のように、入力をシミュレートするのに、type()の関数を使用しましたが、今回のテストでは、配列の入力は残念ながらtype()では対応できません。そこで、type()とpress()をまとめた、submitForm()を使っています。

データプロバイダーの方も、last_nameとhobbyのおいてそれぞれ値を変えることができるように、インデックスをつけました。

さて、これで前回の全角スペースとともに配列値でのトリムも可能となりました。空白文字をトリムするミドルウェアの完成です。

実行できるコードはこのリンクから、コード。タグは、2015-10-19となっています。

git fetch && git checkout -b 2015-10-19

入力の空白文字をトリム（２）全角スペース

Sat, 24 Oct 2015 09:50:38 +0900

前回の「空白文字の入力をトリムする」の続きです。

まず、動作確認を簡単にするために、ユニットテストを作成しましょう。

入力画面のユニットテストをもとに、いろいろなデータをテストできるように、データプロバイダーを使用します。

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class SignupTest extends TestCase
{
    use DatabaseTransactions;

    /**
     * @dataProvider providerTrimpInput
     */
    public function testTrimpInput($last_name, $expected)
    {
        $this->visit('/signup')
            ->type('success@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type($last_name, 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->see('会員登録完了');

        $member = \App\Member::where('email', 'success@gmail.com')->first();

        $this->assertEquals($expected, $member->last_name);
    }

    public function providerTrimpInput()
    {
        return [
            [ '山田', '山田'],
            [ ' 山田 ', '山田'],   //半角スペース
            [ '　山田　', '山田'], //全角スペース
        ];
    }
}

ユニットテストのデータプロバイダーは、テストとデータを分けることにより、１つのテストでいろいろなデータのテストが可能となります。必要なのは、コメントのphpDocの@dataProviderでデータを供給する関数名を指定することと、そのデータ供給の関数を作成することです。この例では３つのデータを用意することにより、３回テストが実行されます。

テスト実行結果は、以下です。

PHPUnit 4.8.9 by Sebastian Bergmann and contributors.

..F

Time: 360 ms, Memory: 26.50Mb

There was 1 failure:

1) SignupTest::testTrimpInput with data set #2 ('　山田　', '山田')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'山田'
+'　山田　'

/vol1/usr/www/shop/webdocs/demo/tests/SignupTest.php:27

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

２番目の半角のスペースのデータはトリムされ成功となり、３番目の全角スペースが前後にあるデータでは失敗となります。

さて、全角スペースはどう対応しましょうか？

再度、trim関数の仕様を見てみましょう。

 string trim ( string $str [, string $character_mask = " \t\n\r\0\x0B" ] )

この関数は str の最初および最後から空白文字を取り除き、 取り除かれた文字列を返します。
2番目のパラメータを指定しない場合、 trim()は以下の文字を削除します。

    " " (ASCII 32 (0x20)), 通常の空白。
    "\t" (ASCII 9 (0x09)), タブ。
    "\n" (ASCII 10 (0x0A)), リターン。
    "\r" (ASCII 13 (0x0D)), 改行。
    "\0" (ASCII 0 (0x00)), NULバイト
    "\x0B" (ASCII 11 (0x0B)), 垂直タブ

そう、２番目のパラメータに全角スペースを入れてあげればよいですね。

trim($val, ' \t\n\r\0\x0B　');//全角スペースは最後の空白文字

しかし、これはテストしたところうまくいきませんでした。全角のスペースが入る値には対応するようですが、半角の文字列では文字列によっては空白文字でないものもトリムしてしまいます。trimの関数はユニコード対応でないようですね。それならば、mb_trimと思いますが、残念ながらこれが存在しません。

いろいろ調べたところ、preg_replaceが使えそうです。

パターンは、

’/(^\s+)|(\s+$)/u’

\sは空白文字のエスケープシーケンスであり、ドキュメントでは以下の記述があります。

エスケープシーケンス

空白文字とは HT (9)、LF (10)、FF (12)、CR (13)、スペース (32) のことです。しかし、ロケールを指定したマッチングを行った場合には、128から255までのコードポイントの文字 (たとえば NBSP (A0)) も空白文字とみなされる可能性があります。

ということで、trimで削除する空白文字とともにユニコードの全角スペースも削除してくれます。

ミドルウェアを書き直すと、

app/Http/Middleware/TrimInput.php

namespace App\Http\Middleware; 

use Closure; class TrimInput {

    /** 
     * Handle an incoming request. 
     * 
     * @param \Illuminate\Http\Request $request 
     * @param \Closure $next 
     * @return mixed 
     */ 
    public function handle($request, Closure $next) { 

        $input = $request->all();

        $trimmed = [];

        foreach($input as $key => $val)
        {
            $trimmed[$key] = preg_replace('/(^\s+)|(\s+$)/u', '', $value);
        }

        $request->merge($trimmed);

        return $next($request);
    }
}

先のユニットテストの結果は？

PHPUnit 4.8.9 by Sebastian Bergmann and contributors.

...

Time: 359 ms, Memory: 26.50Mb

OK (3 tests, 12 assertions)

成功です！

次回は、配列の入力値の個々の値の空白文字のトリムの対応です。

入力の空白文字をトリム（１）ミドルウェア

Mon, 19 Oct 2015 09:32:19 +0900

フォームから入力されてくる文字でやっかいなのは、文字列の前後にユーザーのタイプミスで入れられる空白文字。英語では半角のスペース、日本語では全角のスペース。

これらの空白文字を削除してくれる関数はすでにPHPにはあります。

http://php.net/manual/ja/function.trim.php

さて、この関数をララベルのどこで使用するのが適切でしょうか？

まず考えるのは、コントローラ。バリデーションの前に、以下のようにループで空白文字を削除。

public function postSignup(Request $request)
{
    ...

    $trimmed = [];

    foreach($request->all as $key => $val)
    {
        $trimmed[$key] = trim($val);
    }

    $request->merge($trimmed);

    $this->validate($request, $rules, $messages);

    ...

しかし、どこのコントローラでもこれを行うのは面倒です。フォームリクエストという手もありますね。しかし、これもコントローラ１つに対してフォームリクエスト１つを作成すれば、同じ手間。もっとグローバルで対応する手はない？

そこで登場するのは、HTTPミドルウェアです。HTTPミドルウェアは、フォームなどから入力されてくる値をフィルターするためのプログラムです。

フィルターは、

app/Http/Middleware

のディレクトリに存在します。すでに以下のファイルが用意されていて、それぞれのフィルターのカスタマイズを行うことができます。

Authenticate.php　ユーザーの認証のため EncryptCookies.php クッキーの暗号化のため RedirectIfAuthenticate.php すでに認証されているならリダイレクトするため VerifyCsrfToken.php　セッション乗っ取りを防ぐため

ここに新たなミドルウェアとして空白文字のトリムを入れましょう。

app/Http/Middleware/TrimInput.php

namespace App\Http\Middleware; 

use Closure; class TrimInput {
    /** 
     * Handle an incoming request. 
     * 
     * @param \Illuminate\Http\Request $request 
     * @param \Closure $next 
     * @return mixed 
     */ 
    public function handle($request, Closure $next) { 

        $input = $request->all();

        $trimmed = [];

        foreach($input as $key => $val)
        {
            $trimmed[$key] = trim($val);
        }

        $request->merge($trimmed);

        return $next($request);
    }
}

まず、簡単な対応として、入力されたそれぞれの値に対して半角の空白文字のトリムを実行します。クラス名はファイル名と同様にTrimInputと命名します。既存のクラスを継承する必要はなく、handle()の関数を定義するのみです。

入力の値は、$requestのパラメータからオブジェクトとして取得して、それをトリムした文字列で上書きします。そして、最後には次のフィルターの関数を上書きされたリクエストとともにコールします。

しかし、残念ながらこれだけでは実行されません。以下のファイルにおいて、登録する必要あります。

app/Http/Kernel.php

namespace App\Http; 

use Illuminate\Foundation\Http\Kernel as HttpKernel;

class Kernel extends HttpKernel
{ 
/**
 * The application's global HTTP middleware stack.
 *
 * @var array
 */ 
    protected $middleware = [
        \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
        \App\Http\Middleware\TrimInput::class,
    ]; 

/**
 * The application's route middleware.
 *
 * @var array
 */
    protected $routeMiddleware = [
        'auth' => \App\Http\Middleware\Authenticate::class,
        'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
        'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
    ];
}

TrimInputは21行目に登録されています。先にリストした他のミドルウェアも入っていますね。

さて、これだけは十分ではありません。いくつか、対応すべき問題があります。

まず、フォームでは日本語の入力を期待するのに、全角スペースの対応ができていません。

また、フォームなどから入力される値は、たいていが文字列ですがＰＨＰでは、配列の[]を使用することで以下のような同型の複数行フォームの入力も可能です。

<form>
...
<div>あなたの趣味を以下に記入してください：</div>
<ul>
  <li><input type="text" name="hobby[]" value=""></li>
  <li><input type="text" name="hobby[]" value=""></li>
...
</form>

この配列での入力値の対応も先のコードでは無理です。そして、動作確認はどうしましょう。空白文字ゆえに画面での確認は難しいです。フォームのユニットテストが必要ですね。これらを含めて次回に仕上げましょう。

フォームリクエスト：コントローラからバリデーションを分離

Wed, 30 Sep 2015 11:40:55 +0900

「重複回避-DB重複エラーを利用」で使用した以下のコントローラのメソッドをここでもう一度掲載します。

public function postSignup(Request $request)
{
    $rules = [
      'email'      => 'required|email|unique:member,email',
      'password'   => 'required|min:6|max:20|confirmed',
      'first_name' => 'required',
      'last_name'  => 'required'
    ];

    $messages = [
       'email.unique' => "Eメールアドレスはすでに使用されています"
    ];

    $this->validate($request, $rules, $messages);

    try 
    {
      $member = Member::create($request->all());
    }
    catch(IlluminateDatabaseQueryException $e)
    {
      $errorCode = $e->errorInfo[1];

      if($errorCode == 1062) //重複エラーをここでキャッチ
      {
        return back()->withInput()->withErrors(['email' => "Eメールアドレスはすでに使用されています"]);
      }
    }

　　return "登録完了";
}

フォームでの入力により送信された値は、このメソッドのパラメータ変数$requestに収められます。それらをバリデーションして、エラーがあれば表示、なければ新規の会員のDBレコードを作成。さらに、タイミングエラーにより逃れた重複エラーも発生するならキャッチ。まとまってとてもわかりやすいです。これはこれで十分と思います。

しかし、このコントローラのコードがより複雑になったときに、たとえば、新規会員、編集、パスワードの編集と会員関連のバリデーションを一箇所に集めて管理性を高めたいときはどうしましょう？

もちろん、１つのコントローラでpostSignup()のようにそれぞれのメソッドで対応するのも１つのやり方、しかし、会員のすべての処理を１つのコントローラで対応することはできません。例えば、ユーザーはエンドユーザーだけでなく管理者も会員処理が必要となります。その場合は少なくともユーザーと管理者に別々のコントローラを持つことになるでしょう。そうなら、モデルのMember.phpに入れるのも１つの手です。

ここでは、それらとまったく違う手法、フォームリクエストを紹介します。ララベル5.1以降が必要です。

フォームリクエストは、まずapp/Http/Requests/MemberRequest.phpのファイルを作成して、以下のように先のコントローラのバリデーション部分を移行します。

namespace AppHttpRequests;

use AppHttpRequestsRequest;

class MemberRequest extends Request {
    public function authorize()
    {
      return true;
    }

    public function rules()
    {
      return [
        'email'      => 'required|email|unique:member,email',
        'password'   => 'required|min:6|max:20|confirmed',
        'first_name' => 'required',
        'last_name'  => 'required'
      ];
    }
}

これにより先のコントローラは以下のようにシンプルになります。

public function postSignup(MemberRequest $request)
{
    try 
    {
      $member = Member::create($request->all());
    }
    catch(IlluminateDatabaseQueryException $e)
    {
      $errorCode = $e->errorInfo[1];

      if($errorCode == 1062) //重複エラーをここでキャッチ
      {
        return back()->withInput()->withErrors(['email' => "Eメールアドレスはすでに使用されています"]);
      }
    }

　　return "登録完了";
}

パラメータにおいて、$requestのタイプが、RequestからMemberRequestに変わったことに注意してください。

さて、validateの関数のコールはどこへ行ったのでしょうね？

validateの関数のコールは、MemberRequestのオブジェクトが生成されるとともに、その中で実行されます。そしてエラーがあれば画面にエラーを表示し、エラーがなければ、postSignup()の残りのコードを処理します。

今回はシンプルな例でしたが、将来はより複雑な例を紹介しましょう。

入力画面のユニットテスト

Mon, 21 Sep 2015 03:18:35 +0900

ユニットテスト（PHPの場合は、phpunit）を使い始めて、２，３年。その重要さは理解しているものの、つい最近まで、コードの大変さによりなかなか多用はしていませんでした。

データベース絡みや入力画面絡みのテスト、書くのはやっかいです。しかし、ウェブのアプリの開発には、データベースや入力画面があって当然。ここのテストを自動化をせずにいったいどこでする？とも思う。

しかし、どうしてやっかいなのでしょう、これら？

例えば、前回の会員登録の件では、テストとして考えられるのは、

まずは、エラーを出して確認するテストたち：

必須の項目に値がないときにエラーとなるか。
EメールにEメールでないものを入力したときにエラーとなるか。
すでに登録した会員のEメールを入れたときにエラーとなるか（重複チェック）。

そして、エラーがなく、会員登録成功したときの確認のテストも必要です。

前者のエラーを出して確認するテストは、コントローラーでなくモデルに入れてテストが可能かもしれません。ララベルのバリデーションはすでに一貫しているし、カスタマイズのバリデーションも同様にテスト可能です。

しかし、それらユニットテストは個々のバリデーションをテストするだけで、それら集合した入力画面に対してのファンクショナルテストやアクセプタンステストは難しいです。あたかもユーザーが入力するようなテストです。

さらに、後者のエラーが出ない成功の確認のテストは、実際にDBにレコードが作成されてしまいます。つまり１回成功テストすると、次回は重複でエラーとなり成功のテストができなくなります。もちろん、毎回レコードを削除するという手段もありますが（これはDBテストとして将来に紹介します）、違うDBを用意するとかお膳立てがかなり面倒です。

もちろん、ここで、ララベルがそのフレームワークを活かしたユニットテストの登場です（注意：ララベル5.1での前提です）。

まずは、Eメールアドレスの重複による失敗のテストです。

class SignupTest extends TestCase
{
    public function testSignupFail()
    {
        $this->visit('/signup')
            ->type('dup@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type('山田', 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->dontSee('会員登録完了');
    }
}

このテストは、ユーザーが以下のような画面を経験したと同じ状況をテストします。すでにDBにdup@gmail.comが存在していると仮定です。

16行目の “dontSee(‘会員登録完了’);” では、エラーになるために成功時の「会員登録完了」の文字が画面には見えないよ、つまりdon’t seeということです。

今度は、成功時のテストですが、

use IlluminateFoundationTestingWithoutMiddleware;
use IlluminateFoundationTestingDatabaseMigrations;
use IlluminateFoundationTestingDatabaseTransactions;

class SignupTest extends TestCase
{
    use DatabaseTransactions;

    public function testSignupSuccess()
    {
        $this->visit('/signup')
            ->type('success@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type('山田', 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->see('会員登録完了');
    }
}

先の失敗の例と違って、今度はdon’t seeでなくsee(‘会員登録完了’)となっています。

しかし会員登録完了なのにDBのレコードは作成されません。そう、７行目のuse DatabaseTransactionsの宣言により、レコードの作成を試みるもののDBのトランザクション機能を使用してわざと変更をロールバックさせています。これにより作成あるいは変更されたデータを手動で戻さずに、何回でもテストの実行が可能となるわけです。もちろん、トランザクション機能があるDB、mysqlならinnodbの使用でないとできないことです。

先の２つテストを合わせて、実行すると、「OK」という結果です。

$ phpunit tests/SignupTest
PHPUnit 4.8.2 by Sebastian Bergmann and contributors.

..

Time: 313 ms, Memory: 27.25Mb

OK (2 tests, 7 assertions)

重複回避 - DB重複エラーを利用

Mon, 14 Sep 2015 02:46:41 +0900

前回においては入力バリデーションでの重複回避を紹介しました。

小規模なサイトではこれだけで重複回避は十分かもしれません。しかし、以下の状況では、どうなるでしょう？

ユーザーAさんとBさんがいたとして、どちらも、ほとんど同時にtest@gmail.comのログインで登録を試みます。もちろんそんなことは滅多に起こらないのですが、たまたまBさんは間違って自分のEメールアドレスをAさんと同じものとタイプしたとします。それから、test@gmail.comでの会員はまだDBには存在しないという仮定です。

Aさんは、

10時20分00秒：入力完了して送信（登録ボタンを押す） 10時20分05秒：入力バリデーション無事通過！ 10時20分15秒：無事にDBに登録成功！

Bさんも、５秒遅れて、

10時20分05秒：入力完了して送信（登録ボタンを押す） 10時20分10秒：入力バリデーション無事通過！　

（もちろん実際はこんなに遅く物事は進行しませんが、経過を理解してもらうために）

あれあれ、まだAさんのレコードはDBにないから、入力バリデーション効きませんね。

このままだと重複のレコードになってしまいますね。どうしましょう？

通常、会員の登録のDBテーブルでは、同じID、ここではEメールの重複はないよ、ということで、プライマリーキーあるいはユニークキーというものを設定します。

例えば、以下はmysqlでのDB設定ですが、「Unique Key member_unique (`email)」がDBに重複のレコードが作成されるのを防ぎます。

CREATE TABLE `member` (
  `member_id` int(11) NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `email` varchar(100) NOT NULL DEFAULT '',
  `password` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`member_id`),
  UNIQUE KEY `member_unique` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

このDBの設定のおかげで、

10時20分15秒：DBの重複エラーとなり、Bさんのレコードは作成されず重複のレコードの作成は回避されます。

ここの部分、プログラムでは前回の入力バリデーションと合わせて以下のようになります。

public function postSignup(Request $request)
{
    $rules = [
      'email'      => 'required|email|unique:member,email',
      'password'   => 'required|min:6|max:20|confirmed',
      'first_name' => 'required',
      'last_name'  => 'required'
    ];

    $messages = [
      'email.unique' => "Eメールアドレスはすでに使用されています"
    ];

    $this->validate($request, $rules, $messages);

    try 
    {
      $member = Member::create($request->all());
    }
    catch(IlluminateDatabaseQueryException $e)
    {
      $errorCode = $e->errorInfo[1];

      if($errorCode == 1062) //重複エラーをここでキャッチ
      {
        return back()->withInput()->withErrors(['email' => "Eメールアドレスはすでに使用されています"]);
      }
    }

　　return "登録完了";
}

これで重複は完全に回避されます。

これなら、入力バリデーションの重複はチェックはもう要らないのでは？

それを削除をしてもOKと思います。しかし、ルールの記述としてプログラムに残るのは良いかもしれません。将来はDBレベルの重複エラーもフレームワークが面倒みてくれるかもしれません。

重複回避－入力バリデーションで回避

Tue, 08 Sep 2015 09:41:02 +0900

GmailのEメールアドレス、Facebookのログイン、銀行の口座番号、などなど・・世の中どこに行っても必要なIDの情報。この情報に重複があったら困りますね。

このIDとなる情報を登録するプロセス、まずは入力バリデーション、次にDBでレコード作成時の重複DBエラーを利用しての２ステップで重複を回避します。

今回は、入力バリデーションを使って：

public function postSignup(Request $request)
{
  $rules = [
    'email'      => 'required|email|unique:member,email',
    'password'   => 'required|min:6|max:20|confirmed',
    'first_name' => 'required',
    'last_name'  => 'required'
  ];

  $messages = [
    'email.unique' => &quot;Eメールアドレスはすでに使用されています&quot;
  ];

  $this->validate($request, $rules, $messages);

  $member = Member::create($request->all());
}

重複をチェックしてくれるのは、unique:member,emailのルールです。「DBテーブル member の email には同じ情報があってはいけません」というルールです。

すでにDBに存在するEメールを入力したなら、DBに値を保存せずに、入力画面へ戻りエラー「Eメールアドレスはすでに使用されています」を表示してくれます。

それを行ってくれるのが次の1行：

$this->validate($request, $rules, $messages);

しかし、シンプルすぎて逆にわかりにくいかもしれません。そう思うなら、ララベルバージョン４のように、以下とも書くことできます。

$validator = Validator::make($request->all(), $rules, $messages)

if ($validator->fails())
{
  return back()->withErrors($validator)->$withInput();
}

さて、重複回避は、このチェックだけで十分でしょうか？

次回は、DBレベルでの重複回避の紹介をします。

ああも言えたりこうも言えたり

Mon, 31 Aug 2015 07:55:40 +0900

Laravelでは、同じことを成し遂げるのにいくつか違う方法で行うことできます。これを便利かと思うかややこしいかと思うかは、人それぞれですが、

例えば、前回のマスアサインメントの紹介をしたときの以下のコード、

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = new Member;
    $member->fill($request->all())->save();
  }
}

これ以下のようにも書けるのですよ。

インスタンスを作成するクラス・メソッドで、コンパクトに。

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = Member::create($request->all());
  }
}

あるいは、パラメータでインスタンスを作成してまって、値を入れてセーブ。

class SignupController extends Controller
{
  public function postSignup(Request $request, Member $member)
  {
    $member->create($request->all());
  }
}

これら皆同じくDBにレコードを作成します。

マスアサインメントで一括取り込み

Wed, 19 Aug 2015 09:31:52 +0900

ララベルのマニュアルで紹介されている一般的なDBレコードの作成方法は、

class Member extends Model
{
  protected $table = 'member';
  protected $primary_key = 'member_id';
  protected $timestamps = true;
}

use App\Models\Member;

$member = new Member();
$member->name = '山田太郎';
$member->email = 'tyamada@gmail.com';
$member->password = 'password'; //　ここもちろん実際は暗号化して
$member->save();

Memberのインスタンスを作成し、ちまちまとそれぞれの項目を埋めて、最後にセーブ。

しかし、ウェブのアプリでは、コントローラーにおいて、ユーザーの入力がたくさんの項目でいっぺんに入ってくるので、

namespace App\Http\Controllers;

use App\Models\Member;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = new Member;
    $member->fill($request->all())->save();
  }
}

と、先のようにひとつひとつの項目に値を割り当てずに、一気に保存することできます。いわゆる、一括割り当てのマスアサインメント(Mass Assignment)です。

しかし、このコード、ちょっと問題があります。

上のコードでは、フォームからポストされる項目名がすべてが、クラスMemberのDBテーブルにあると仮定して、ララベルは一括割り当てを試みます。

たとえば、以下のようなフォームでは、

    <form method="post" action="signup">
        ログイン:
        <input type="email" name="email" value="{{ old('email') }}" required autofocus>

        パスワード:
        <input type="password" name="password" required>

        パスワードの確認:
        <input type="password" name="password_confirmation" required>
        
        名前:
        <input type="text" name="name" value="{{ old('name') }}" required>

        <button type="submit">保存</button>

    </form>

以下の項目が入力項目名ですが、

email password password_confirmation name

password_confirmationは、通常、パスワード確認のための入力項目でDBには存在しない項目です。その値をDBに入れようとするところでエラーとなります。

どうしましょう？

エロクエント（Eloquent）では、どの値をDBに入れてよいか、どれを入れていけないかのルールの設定が可能です。$fillableあるいは$guardedのどちらかの変数の定義がその目的で使用されます。前者は、ホワイトリスト（入力OKの項目のリスト）、後者はブラックリスト（入力禁止の項目のリスト）です。

class Product extends Model
{
  protected $table = 'member';
  protected $primary_key = 'member_id';
  protected $timestamps = true;

  protected $fillable = ['email', 'password', 'name'];
}

こうすれば、エラーがなくDBに値を無事に入れることができます。

$fillableの代わりに、以下でも良いですね。

protected $guarded = ['password_confirmation'];

アーティザンのティンカー

Wed, 12 Aug 2015 12:44:26 +0900

前回の投稿「ダーティーなレコード」で、DBレコードが更新されたかどうか、簡単に実験してチェックできるツールを紹介しましょう。

ララベルにはコマンドで実行できる強力なツール、その名もアーティザン(Artisan)があります。このアーティザン、Macを含めてUnix系の開発者には便利でこのうえないツール。しかも、複数のコマンドがあるわけでなく、１つのコマンドでオプションを変えるだけでいろいろなことができる優れもの。

$ php artisan list

とタイプすればたくさんのオプションのヘルプがでてきます。

さて、この中でとてもユニークなのが、今回紹介するTinker

$ php artisan tinker

Psy Shell v0.4.4 (PHP 5.5.25 - cli) by Justin Hileman
>>>

まず、Eloquentのモデルを利用してレコードを取ってきましょう.

>>> use App\Models\Product
=> false
>>> $product = Product::find(1)
=> <App\Models\Product #000000000db510bc000000004b81eec1> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-05 13:15:25",
       name: "test product",
       price: "1000"
   }
>>>

次に、価格（price）を更新してみます。

>>> $product->price = "2000"
=> "2000"
>>> $porduct->isDirty()
=> true
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>

isDirty()は変更されたのでもちろんtrue、また update_atも更新時の日時に更新されています。

今までのDBのクエリの履歴を見たいなら、

>>> DB::getQueryLog()
=> [
       [
           "query"    => "select * from `product` where `product`.`product_id` = ? limit 1",
           "bindings" => [
               3
           ],
           "time"     => 0.56
       ],
       [
           "query"    => "update `product` set `updated_at` = ?, `price` = ? where `product_id` = ?",
           "bindings" => [
               "2015-08-11 09:33:23",
               "2000",
               3
           ],
           "time"     => 3.13
       ]
   ]
>>>

さて、今度は同じ値を入れてみましょう。

>>> $product->price = "2000"
=> "2000"
>>> $product->isDirty()
=> false
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>

レコードではダーティーではなく(false)、またsave()しているにもかかわらず、update_atの値にも変化ありませんね。

ここで、DB::geQueryLog()を実行すれば、さきとまったく同じ履歴が出てきます。つまり、DBの処理は何もなかったを証明します。

ティンカー便利ですね。ブラウザを使わなくとも、ユニットテストを書かなくても、ここでテストができるのが便利です。

追記：

今回のティンカーは、バージョン5.1のララベルを使用しています。他のバージョンでは、コマンドのプロンプトのシンボルが違ったりや行末のセミコロンの必須となったります。ご注意を。

ダーティなレコード

Wed, 05 Aug 2015 12:13:26 +0900

フォームの画面でのユーザーのインプットをもとに既存のDBレコードを更新する際、もし何もデータ更新なしに「保存」ボタンを押されたらDBレコードを更新する？

更新あります！

もちろん、Javascriptで「保存」ボタンを無効にすることも可能。少なくともブラウザレベルでは。

しかしサーバーレベルではどう判断？

現在のデータとインプットデータを項目ごとに１つずつ比較？

そんな面倒なことを裏で自動的にEloquentは行ってくれます。

例えば、

class Product extends Model {
  protected $table = 'product';
  protected $primary_key = 'product_id';
  protected $timestamps = true;
}

use App\Product;

$product = Product::find(1); //product_id = 1　のレコードをゲット
$product->price = 2000;　// まったく以前と同じ値段に
$product->update();

update()をコールしているのだけれど、何もデータに変更ないので、ここ裏ではDBの更新はありません（updated_atのタイムスタンプをチェックしてみてください）。賢いですね！

しかし、ここに例えば、この更新をもとに他のDBのレコードを更新することがプログラムされていたら？

$product->update();
update_other_table();

必要もないのにそちらも更新されては困ります。

更新されたかどうかを判断するには、

if($product->isDirty())
{
  $product->update();
  update_other_table();
}

と簡単にチェックできます。ここisDirty()はDBにレコードが保存される前にチェックする必要あります。つまり、update()の前に。

さらに、１つの項目だけが変更されたかどうかをチェックするには、

if($product->isDirty('price'))
{
  update_other_table();
}

素晴らしいですね。

ちなみに、この「ダーティ」。ダーティハリー、ダーティダンシングのムービーの「ダーティ」と同じです。

http://dictionary.goo.ne.jp/leaf/jn2/132268/m0u/

汚いの意味。

でもここでの意味は、「データが更新された」の意味。

L5.1 on ララジャパン

バリデーション (8) 配列をバリデーションする

laravel 4 や 5.1 以前での配列バリデーション

メンテナンス画面の裏口

ユーザー認証（８）ユーザーの有効・無効を考慮

ユーザー認証（７）スロットルのユニットテスト

ユーザー認証（６）ログインスロットル

ユーザー認証（５）パスワードリセット

パスワードリセットリンクを送信してもらう画面

パスワードリセットリンク先の画面で、新規パスワードを設定する画面

ユーザー認証（４）認証でページを保護

ユーザー認証（３）ログイン・ログアウト

ユーザー認証（２）ユーザーの登録

ユーザー認証（１）下準備

アプリの設定

DBテーブルの作成

入力の空白文字のトリム（３）配列の入力値

入力の空白文字をトリム（２）全角スペース

入力の空白文字をトリム（１） ミドルウェア

フォームリクエスト：コントローラからバリデーションを分離

入力画面のユニットテスト

重複回避 - DB重複エラーを利用

重複回避－入力バリデーションで回避

ああも言えたりこうも言えたり

マスアサインメントで一括取り込み

アーティザンのティンカー

ダーティなレコード

入力の空白文字をトリム（１）ミドルウェア