L5.2 on ララジャパン

グローバル変数をダイナミックに管理

Sun, 04 Dec 2016 04:07:20 +0900

Laravelのバージョンが5になってから、グローバルスコープを持つ変数の設定は、.envとconfig/のディレクトリの設定ファイルで、実用的しかも綺麗にまとまりました。変数の使用も、config(‘app.url’)と、プログラムのでどこでも簡単に取得できます。

また、DBの設定などのデフォルト設定ファイル以外にも、独自の設定ファイルも作成できます。

例えば、

config/local.phpというファイルを作成して、

config/local.php

return [
        'convert' => '/usr/bin/convert', // 画像変換のプログラムのパス名
        'items_per_page' => 50,          // 1ページのアイテム数
        'max_upload_size' => 20,         // 最大アップロードの画像サイズ（ＭＢ）
        'company' => env('LOCAL_COMPANY', 'Lots of Bytes'), // 会社名
];

とすれば、config(’local.company’)と参照できます。

しかし、これらのグローバル変数設定の問題は、プログラムとして設定ファイルあるいは.envでハードコードしなければならないことです。

グローバル変数をDBに値を保存して、管理画面で以下のように値を編集できて、プログラムの各所で使用できるようにするには、どうしたらよいのでしょうか？

幸いにも、config()の関数は、取得だけでなく書き込みも可能なのです。

config(['global.admin_email' => 'abc@gmail.com']);

というように実行すれば、config(‘global.admin’)でabc@gmail.comを返すことができます。

global.とプリフィックスしたのは、単に他の変数と区別やグループ分けがしたいがためです。

ということは、ＤＢからデータを読んでプログラムの実行時の最初に、configして入れしまえば良いわけです。

このための適切な場所は、プログラムの初期に実行される、app/Providers/AppServiceProvider.phpの中です。

app/Providers/AppServiceProvider.php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use DB;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
	$setting = DB::table('setting')->pluck('value', 'key');

	config(['setting' => $setting]);        
    }
...
}

DBテーブルsettingの中身は、以下とすると、

+------------+---------------------+---------------------+------------------+-------------------+
| setting_id | created_at          | updated_at          | key              | value             |
+------------+---------------------+---------------------+------------------+-------------------+
|          1 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | email_admin      | admin@gmail.com   | 
|          2 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | email_from       | from@gmail.com    | 
|          3 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | site_name        | ララジャパン       | 
+------------+---------------------+---------------------+------------------+-------------------+

例えば、config(‘setting.site_name’)の実行では、ララジャパンの値が返ってきます。

バリデーション (9) 配列のDistinctと暗黙の拡張

Tue, 01 Nov 2016 21:51:12 +0900

配列のDistinctバリデーション

前回の例題とした商品オプションに、オプション名に同じ値が入ることを禁じるバリデーションを追加します。

これには、配列プレースホルダー .* ともに laravel 5.2 で追加された distinct バリデーションが利用できます。よく考えられていますね。

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

空の入力に対するdistinct？

ところで、ここまで「オプション名」は必須入力であることを前提としてきましたが、商品オプションが１つだけなら「オプション名」は空のまま「販売単価」と「在庫数」だけ入力できるようにしたい、という要望が現場から上がってくるかもしれません。

もう少し仕様追求すると、商品オプションが２つ以上であっても、先頭（とは限らないかもしれません）の１つは空でよいかもしれません。

このために空の入力が１個まで可というバリデーションルールを追加するとロジックが複雑化します。required_with を外したとき distinct が空文字列もあわせて重複チェックしてくれれば話が簡単ですね。こんなふうに・・・

３つの入力欄のうち２つを空にした場合のリクエストは次のようになります。

Array
(
    [option_name] => Array
        (
            [11] => 
            [12] => 
            [13] => オレンジ
        )

option_name のキー 11 と 12 は同じ値（空文字列）なのだから重複チェックにかかりそうなものです。

しかしこのバリデーションはそんな都合よく機能しません。

distinct バリデーションは、option_name 全体ではなく、配列の値それぞれに働きます。キー 11 の値は配列内で重複してるか？キー 12 の値は・・・と。

そして、バリデーションの原則は値が入力された項目にのみ働きます。このケースでは、そもそもキー 11 と 12 は調査されることなく、キー 13 の値が配列内で重複してるかだけが調べられ、重複なしと判定されるのです。

そう、リクエストが空でも働くのは、required 系バリデーションだけでした。

暗黙の拡張 implicitRules

ここまでくると次の展開が読めましたか？

この課題は解決には、distinct が required と同様に 空リクエストに対してもバリデーションが働く 必要があり、これを実現するのが 暗黙の拡張 ルールです。

この暗黙の拡張を「暗黙の必須」と読んでしまうと理解を間違えます。空リクエストに対するバリデーション、それ以上でも以下でもありません。

暗黙の拡張ルールを作るには、Validator::extendImplicit() メソッドを使います。通常の拡張ルールとして登録されると同時に、暗黙の拡張ルールの名前を収めた配列 $implicitRules にルール名が追加されます。

Validator::extendImplicit('foo', function($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

ということは、Validator を継承して作成した customValidaor クラスでは、直接 $implicitRules にルール名を追加することで暗黙の拡張を作ることができます。

以下は、空文字列を含んだ重複判定ができる distinct_with_blank バリデーションの作成例です。

class CustomValidator extends \Illuminate\Validation\Validator {

    public function __construct($translator, $data, $rules, $messages = [])
    {
        parent::__construct($translator, $data, $rules, $messages);

        // 暗黙の拡張に追加
        $this->implicitRules[] = 'DistinctWithBlank';
    }

    /**
     * 空文字列も含む重複判定 distinct_with_blank
     * @param  string $attribute
     * @param  string $value
     * @param  array  $parameters
     * @return true
     */
    public function validateDistinctWithBlank($attribute, $value, $parameters)
    {
        // 標準distinctを呼ぶだけ
        return parent::validateDistinct($attribute, $value, $parameters);
    }

これを用いて option_name.* から required_with を外すと、最初のルール定義は次のようになります。無事に、オプション名の空は１つだけ許可されるようになりました。

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

この他にも、DB上の重複をチェックする unique に対し、空入力でも機能する unique_with_blank も状況によっては（DB定義がNULL OKではないなど）ニーズがあるかもしれませんね。

バリデーション (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.*',

バリデーション (7) エラーメッセージのリプレーサー

Tue, 18 Oct 2016 20:11:25 +0900

等号を含む日付の最大最小

日付の最大最小 after, before の比較はなぜか等号を含みません。英単語の意味を厳格にプログラム仕様に落とし込んだようですが、実際の使い勝手としては等号を含んでほしかったところです。

これを等号を含むように拡張してしまうと、前回の min, max を拡張したのと違って意味が変わってしまいます。そこで、start, end を新たに作成して追加してみましょう。

'start_date' => 'date|start:today',      // 今日を含んでそれ以降
'end_date'   => 'date|start:start_date', // 開始日を含んでそれ以降

最低限の追加で済むように、内部で標準バリデーションの after, before を呼び出すようにします。標準が等号を含まないのですから、普通に考えると after に与えられた引数を -1（秒）し、before の引数を +1（秒）するのがわかりやすいでしょう。

しかし、これらの引数は日付そのものだけではなく、上に示したように比較対象の属性名が与えられることがありますから、加減算をするには属性名から参照先の日付を取得するコードを自分で書かなければなりません。

そこで発想を逆転して、検査する入力値の日付を +1（秒）して after に、-1（秒）して before に与えることにします。意味を考えると分かりづらいですが、相対的なものなので正負を逆転しただけです。

作成したバリデーションルールは次のとおりです。

public function validateStart($attribute, $value, $parameters)
{
    $value = date('Y-m-d H:i:s', strtotime($value.' +1 sec'));

    return parent::validateAfter($attribute, $value, $parameters);
}

public function validateEnd($attribute, $value, $parameters)
{
    $value = date('Y-m-d H:i:s', strtotime($value.' -1 sec'));
/*
    // 比較相手が 日付のみ場合は 23:59:59を補完する
    if ((($date = $this->getValue($parameters[0])) || ($date = $parameters[0]))
        && !preg_match('/:/', $date))
    {
        $parameters[0] = date('Y-m-d 23:59:59', strtotime($date));
    }
*/
    return parent::validateBefore($attribute, $value, $parameters);
}

validateEnd() のコメントされたコード部分は、Datetime と Date を比較したときに起きる問題の補正です。

例えば、DBレコードの販売期間が Datetime で、出荷期間が Date のときなど、異なる日付型の間で比較が必要な場合には有効にしてください。補正は end のみに必要で、start には必要ありません。

$tests = [
    ['2016-10-10', '2016-10-10 10:00:00'],
    ['2016-10-10 10:00:00', '2016-10-10'],
];
foreach($tests as $i => $date) {
    printf("%d => %d %d\n", 
    $i, ($date[0] >= $date[1]), ($date[0] <= $date[1]));
}

結果

0 => 0 1 // ('2016-10-10' >=' 2016-10-10 10:00:00') == FALSE は正しい！
1 => 1 0 // ('2016-10-10 10:00:00' <= '2016-10-10 23:59:59'に補正が必要

メッセージへの引数の展開

さて、前回、比較対象の属性名を引数に持てるように拡張した min, max において、エラーメッセージの引数部分が、バリデーション言語ファイルの定義通りの日本語に展開されませんでした。今回追加作成した start, end にいたっては、英文字の属性名にすら展開されません。この問題を解決しましょう。

今、バリデーション言語ファイルが次のように定義されているとします。

resources/lang/ja/validation.php

'after'  => ':attributeが:dateより前',
'before' => ':attributeが:dateより後',
'max' => [
  'numeric' => ':attributeが:maxよりも大きい',
],
'min' => [
  'numeric' => ':attributeが:minよりも小さい',
], 

// 追加

'start'  => ':attributeが:dateより前',
'end'    => ':attributeが:dateより後',

// 項目名

'attibutes' => [
  'end_date'   => '終了日',
  'start_date' => '開始日',
  'unit_cost'  => '仕入単価',
  'unit_price' => '販売単価',
],

このとき、それぞれのルールに対するエラーメッセージは次のように展開されます。

区分	ルール	エラーメッセージ	課題
標準	'unit_price' => 'min:0'	販売単価が0より小さい
拡張	'unit_cost' => 'max:unit_price'	仕入単価がunit_priceより大きい	日本語にはならない
標準	'end_date' => 'before:start_date'	終了日が開始日より後
追加	'end_date' => 'end:start_date'	終了日が:dateより後	属性名への展開すらない

属性名を引数に取れるように拡張した min, max で英文字の属性名が展開できるのは、数値が与えられたときの標準の展開がそのまま適用されているためです。

カスタムプレースホルダー

エラーメッセージの中の :attribute や :min, :date はプレースホルダーと呼ばれます。

カスタムのプレースホルダーを追加するには、サービルプロバイダーの boot メソッドの中で、Validator::replacer() メソッドを呼び出します。

Validator::replacer('foo', function($message, $attribute, $rule, $parameters) {
    return str_replace(...);
});

もしくは、Validator を継承した CustomVlidator クラスでは、addReplacer() メソッドか、複数のリプレーサーを配列にしてまとめて登録できる addReplacers() メソッドで登録できます。

$this->addReplacer('foo', function($message, $attribute, $rule, $parameters) {
    return str_replace(...);
});

リプレーサーの中身は簡単な文字列置換です。

与えられたエラーメッセージ（$message）に対して、プレースホルダー文字列（":min" や ":date" など）を引数の文字列（$parameters[0]）に置き換えるコードを記述します。

引数（$parameters[0]）は与えられた最小値の値や、比較相手の英文字の属性名です。これを日本語に展開するには、バリデーション言語ファイルの $attributes 配列から対応語を参照する getAttribute() メソッドを使います。

以下、CustomValidator クラスのコンストラクタで min, max, start, end にリプレーサーを登録するサンプルです。共通部分が多いのでクロージャを変数に代入し、setReplacers() でまとめて配列登録しました。

これで、エラーメッセージは期待通りすべて日本語に展開されるようになりました。

<?php

namespace App\Services;

class CustomValidator extends \Illuminate\Validation\Validator
{
    public function __construct($translator, $data, $rules, $messages = [])
    {
        parent::__construct($translator, $data, $rules, $messages);

        // 汎用（ルールと同名）
        $replacer = function($message, $attribute, $rule, $parameters) {
            return str_replace(':'.$rule, $this->getAttribute($parameters[0]), $message);
        };
        // 日付
        $date = function($message, $attribute, $rule, $parameters) {
            return str_replace(':date', $this->getAttribute($parameters[0]), $message);
        };

        $this->addReplacers([
            'min' => $replacer, 'max' => $replacer, 'start' => $date, 'end' => $date
        ]);
    }

バリデーション (6) 他の属性の値を参照

Sat, 15 Oct 2016 19:30:29 +0900

日付の最大最小 after, before では、引数に値（日付）を与えるだけでなく、比較対象の属性の名前を与えることができます。むしろ具体的な日付を引数にすることのほうがまれでしょう。

'date_start' => 'date|before:today',
'date_end'   => 'date|after:date_start',

このような使い方は、数値型の最大最小 min, max でも使用したいこともありますよね？

例えば、次のような関係です。

'unit_price' => 'required|integer|min:0',
'unit_cost'  => 'required|integer|min:0|max:unit_price',

標準バリデーションの min と max を拡張して、比較対象の属性名を引数に持てるようにしてみましょう。

getValue()

バリデーションクラスにルールを登録するときの雛形は次のようなものでした。一見すると引数には、ルールを定義した属性に関する情報しか与えられません。

/**
 * 追加バリデーション
 * @param  string  $attribute  検査する属性名
 * @param  string  $value      入力された値
 * @param  array   $parameters 引数の配列
 * @return boolean
 */
public function validateHoge($attribute, $value, $parameters)
{
  //
}

しかし、バリデーションクラスにはリクエストされたすべての属性に関する情報が与えれていて、他の属性に入力された値も getValue() で得ることができます。getValue() の引数は属性名です。

よって、次のバリデーションは必ず TRUE を返します。

public function validateHoge($attribute, $value, $parameters)
{
   return ($value == $this->getValue($attribute));
}

min と max の拡張

min, max の引数は、属性の型が何であろうと必ず数値を取ります。

そこで、引数が数値（is_numeric）でないときを限定し、引数を属性名とした値が存在するならそれを新たなしきい値としました。

/**
 * 最小値 min
 * @param string $attribute
 * @param string $value
 * @param array $parameters	0 => 比較する属性名
 * @return true
 */
protected function validateMin($attribute, $value, $parameters)
{
    if (!is_numeric($parameters[0]) && 
        !is_null($val = $this->getValue($parameters[0])))
    {
        $parameters[0] = $val;
    }
 
    return parent::validateMin($attribute, $value, $parameters);
}

/**
 * 最大値 max
 * @param string $attribute
 * @param string $value
 * @param array $parameters	0 => 比較する属性名
 * @return true
 */
protected function validateMax($attribute, $value, $parameters)
{
    if (!is_numeric($parameters[0]) &&
        !is_null($val = $this->getValue($parameters[0])))
    {
        $parameters[0] = $val;
    }
 
    return parent::validateMax($attribute, $value, $parameters);
}

＊　＊　＊　＊

さて、拡張した最大最小バリデーションですが、このままではエラーメッセージが与えられた引数の属性名のままとなり、言語ファイルによる置き換えが行われません。

本来の最大最小が与えられた引数そのものを、メッセージのプレースホルダー :max と置き換えることしか想定していないからです。この部分の解決については次回にまとめる予定です。

バリデーション (5) 最大値と最小値

Mon, 10 Oct 2016 19:42:42 +0900

バリデーション言語ファイルを編集するときにお気づきと思いますが、Laravel標準バリデーション Max と Min は（他に Size、Between も）調査対象の属性の型でその挙動を変えます。

'max' => [
    'numeric' => ':attributeの値が:maxを超えています',
    'file'    => ':attributeのサイズが:max kBを超えています',
    'string'  => ':attributeの文字数が:maxを超えています',
    'array'   => ':attributeの個数が:maxを超えています',
],
'min' => [
    'numeric' => ':attributeの値が:minに足りません',
    'file'    => ':attributeのサイズが:min kBに足りません',
    'string'  => ':attributeの文字数が:minに足りません',
    'array'   => ':attributeの個数が:minに足りません',
],

ここで問題となるのは、文字列型が入力した文字数カウントとの比較になることです。文字列比較の大小によるバリデーションは存在してません。

例えば日付型の属性に対する開始日のつもりで Min を指定しても、文字数判定となり、期待したバリデーションにはなりません。

'date_start' => 'date|min:'.date('Y-m-d'),    // 開始日判定にはならない

日付の最大値と最小値

日付型の属性の前後関係の判定には、専用の after と before が用意されています。しかも、引数の文字列は strtotime で処理されるので次のような指定が可能です。

'date_start' => 'date|after:today',    // 今日より大（明日以降）
'date_end'   => 'date|befor:+1 year',  // １年以内

または属性名を引数に持つことができるので、期間指定のバリデーションに使うことが出来ます。

'date_end'   => 'datetime|after:date_start',

ただし、after, befor の比較は等号を含みませんので注意が必要です。

数値型のカスタムバリデーション

例えば1以上の整数（自然数）を判定するカスタムバリデーション natural_number を作成した場合、それを min や max で大小判定したときは、正しく数値として判定されるでしょうか？

結論を言えば、カスタムバリデーション natural_number は（そのままでは）、入力された値が数値であっても、文字列として判断され、文字数でカウントされてしまいます。

'quantity' => 'requied|natural_number|max:10', // 10桁（ 10億）まで可

では、数値として認められるにはどのようにしたら良いのでしょうか。

vender の Validation.php でコードを追うと、getSize() メソッドにおいて次のように型判定されていることがわかります。

1	入力値が数値（`is_numeric`）でバリデーションに `numeric` か `integer` があれば、その値を返す
2	入力値が配列（`is_array`）なら配列の個数を返す
3	入力値が `File` インスタンスならファイルサイズを kB で返す
4	それ以外は文字数（`mb_strlen`）を返す

数値として判定されるには、入力された値が数値であるかどうかだけでなく、バリデーションに numeric か integer が含まれなければなりません。これでは他のどんなルールであっても数値と判定されることはないのです。

numericRules

この数値と判断されるためのバリデーションルールは、変数 $numericRules で定義されていました。

protected $numericRules = ['Numeric', 'Integer'];

カスタムバリデーションとして数値型のルールを自作した場合には、これにルール名を追加すればよいわけです。

変数 $numericRules を protected で再定義して上書きするか、コンストラクタで必要分だけ追加します。……再定義する場合は Numeric と Integer を忘れずに。

public function __construct($translator, $data, $rules, $messages = [])
{
    parent::__construct($translator, $data, $rules, $messages);

    $this->numericRules[] = 'NatrualNumber';
}

/**
 * 自然数 natural_number
 *
 * @param string $attribute		検査する属性名
 * @param string $value			検査する値
 * @return bool
 */ 
public function validateNaturalNumber($attribute, $value)
{
    if ($this->validateInteger($attribute, $value))
    {
        return ($value > 0);
    }

    return false;
}

バリデーション (4) DateとDatetime

Mon, 10 Oct 2016 13:59:04 +0900

Laravel 標準の Date バリデーションは、次のときに TRUE を返します。

OR		値がPHPの `DateTime` クラスのインスタンスである
AND	値が `strtotime` で理解できる文字列である
`date_parse` で年月日を返す
`checkdate` で年月日が妥当である

文字列の具体例でまとめると以下のようになります。

	文字列	バリデーション	MySQL保存
例01	now	FALSE
例02	+1 day	FALSE
例03	next Thursday	FALSE
例04	2016-09-30 + 1day	TRUE	×
例05	30 September 2016	TRUE	×
例06	2016-09-30	TRUE	◯
例07	20160930	TRUE	◯
例08	2016/09/30	TRUE	◯
例09	09/30/2016	TRUE	×
例10	09-30-2016	FALSE
例11	30/09/2016	FALSE
例12	2016-09-30 10:10:00	TRUE	◯

date_parse を通すため例01〜例03のような論理指定は弾かれますが、例04のような記述では前半部分が年月日の配列値を返すためバリデーションは通ります。また、アメリカ式の月日年（例09）が通って、ヨーロッパ式の日月年（例11）は弾かれます（これは環境のタイムゾーンに影響されるでしょう）。

いずれにせよ、バリデーションに通ってもそのままデータベースに保存できるとは限りません。データベース保存を前提にするなら、ISO-8601 の “YYYY-MM-DD” 書式に限定したほうが何かと都合が良いですね。

date_format による ISO-8601限定

入力され日付のフォーマットを限定するために date_format が用意されています。引数は date_parse_from_format を通して処理されます。 date と date_format は両方を同時に使用することはできません。

'date'     => 'date_format:Y-m-d',
'datetime' => 'date_format:Y-m-d H:i:s',

Date と Datetime の拡張

データベースの保存フィールドで Date と Datetime を区別し、入力フォームのインターフェースもこの２つしかないならば、date_format を使用せずに、date バリデーションを拡張してしまうこともできます。

書式を正規表現で限定してからオリジナルのバリデーションを通せばよいでしょう。

    /**
     * date (without datetime)
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    protected function validateDate($attribute, $value)
    {
        // YYYY-MM-DD に限定する
        if (!preg_match('/^[0-9]+-[0-9]+-[0-9]+$/', $value)) return false;

        return parent::validateDate($attribute, $value);
    }

    /**
     * datetime
     *
     * @param string $attribute
     * @param string $value
     * @return bool
     */
    public function validateDatetime($attribute, $value)
    {
        // YYYY-MM-DD hh:mm に限定する
        if (!preg_match('/^[0-9]+-[0-9]+-[0-9]+ ([0-9]+):([0-9]+)/', $value, $m)) return false;

        return parent::validateDate($attribute, $value);
    }

validateDete() は標準の置き換えなので protected 宣言ですが validateDatetime() は追加関数として public で宣言しています。

日付入力のフォームインターフェイス

入力バリデーションとして Date と Datetime を用意したならば、入力フォームもそれに対応しなければなりませんが、HTML5 の日付フォームはブラウザの対応に依存し、非対応な環境を無視したとしてもユーザーインターフェイスが人によって異なりサポートが難しいものです。

私たちのプロジェクトの管理画面では、Bootstrapベースの SmartAdmin を導入してインターフェイスの統一を図っています。

SmartAdmin の日付フォームは jQuery UI Datepicker と Bootstrap Timepicker の組み合わせを採用していますが、HTML5の datetime や datetime-local には対応してません。スクリプトを書くことで datetime 属性（厳密には datetime-local 属性）の入力フォームを実現する必要があります。

bladeソース（の概念）と対応するjQueryスクリプト

<div class="input-group-datetime">
  <input type="hidden" name="date_start" value="{{ old('date_start') }}">
  <input class="datepicker">
  <input class="timepicker">
</div>

$('.input-group-datetime').on('change', 'input:visible', function() {
  // 日付または時刻が変更された
  var $parent = $(this).parents('.input-group-datetime'),
    dt = $parent.find('.datepicker').val(),
    tm = $parent.find('.timepicker').val();
  if (dt && !tm) {
    // 時刻が空なら00:00で補完
    tm = '00:00';
    $parent.find('.timepicker').val(tm);
  }
  if (!dt) {
    // 日付が空なら時刻も削除
    $parent.find('.timepicker').val('');
  }
  // 日時を合成して値を格納
  $parent.find(':hidden').val((dt) ? dt + ' ' + tm + ':00' : '');
});

ちょっとしたパフォーマンスの改善

Tue, 13 Sep 2016 01:59:13 +0900

Laravelは非常にたくさんのファイルを起動時に読み込んでいるので、パフォーマンスの改善は以前から感心があります。最近、管理画面だけでrouteの数が300近いプログラムをインストールするにあたり、重たくなることを予想して、簡単にできる範囲でLaravelでのパフォーマンスの改善を調査してみました。

１．設定ファイルのキャッシュ作成

php artisan config:cache

この実行は、configのディレクトリにあるファイルすべてを合わせて１つのキャッシュファイルにします。これにより設定データのローディング時間を速めようということです。

ファイルは、

bootstrap/cache/config.php

として作成されます。

この使用において、注意は３点あります。

注意点１:プログラムにおいてenv()の関数を使用してはいけない

例えば、

.envのファイルにおいて、

APP_ENV=local

と設定していて、

$path = storage_path().'/'.env('APP_ENV').'/logs/test.log';

のように、現在の環境変数の値によりログファイルを置くディレクトリを変えるとすると、

$pathの値は、

/var/www/test/storage/local/logs/test.log

のようになります。

しかし、php artisan config:cacheを実行すると、env()の値は空となり、

/var/www/test/storage/logs/test.log

となってしまい、意図した場所とは違うことになってしまいます。

それゆえに、先のプログラムは以下と変更することが必要です。

$path = storage_path().'/'.config('app.env').'/logs/test.log';

もちろん、config/app.phpなどの設定ファイルの中でのenv()の使用は問題ないです。

注意点２:ダイナミックに値を設定しているconfigに気をつける

設定ファイルの値は、

config(['some_setting' => 'some_value']);

のようにダイナミックに値の設定が可能です。例えば、DBからの値をAppServiceProvider::boot()で読み込んでおいて、DBに再度アクセスすることなくプログラムのあちらこちらで使用しようというときなどに便利です。

ところが、php artisan config:cacheの実行時に、AppServiceProvider::boot()が実行されるので、それらの設定もキャッシュファイルに保存されてしまいます。これで、ダイナミックに変わる値が固定されては困ります。

しかし、ダイナミックに上書きされるので問題はなさそうです。しかし、プログラムの他の部分では問題があるかもしれません。使用には気をつけてください。

注意点３：.envやconfigのファイルを編集したら、必ずキャッシュを再作成

最後に忘れてはならないのは、.envやconfig/*.phpのファイルを編集したら、必ずphp artisan config:cacheの実行が必要なことです。それなくしては、せっかくの変更も反映されません。

２．routeのキャッシュ作成

php artisan route:cache

こちらは、config:cacheと違い、この実行で作成されるファイル、

bootstrap/cache/routes.php

には、routes.phpファイルを読み込んでLaravelがマップしたデータ構造をbase64_encodeして、serializeした形で収めます。それゆえに、この読み込みとマップの作業を一気に短縮します。とくに、routeの数が大きいプロジェクトではパフォーマンスの改善に期待できる仕組みです。

それからconfig:cacheと同様に、routes.phpファイルを編集したら、必ずphp artisan route:cacheの実行が必要です。

３．共有クラスファイルの最適化

これは、環境変数のAPP_ENVがproductionの値のときにだけに有効なものです。また、設定ファイルに依存するので、設定ファイルをキャッシュするなら、php artisan config:cacheを実行してから以下を実行してください。

php artisan optimize

この実行で、共有されるクラスファイルを１つのファイルにまとめ、読み込み時間を短縮するのが目的です。以下のファイルを作成します。

bootstrap/cache/compiled.php

このファイルには、デフォルトでは、Laravel関連のファイルが含まれますが、必要なら以下の設定ファイルに追加が可能です。

bootstrap/cache/compile.php

改善した？

さて、実際にこれらの最適化でパフォーマンスはどれくらい変わるのでしょうか？

私の厳密ではないテストでは、DB操作を伴わない計測では１０～３０％の違いがありました。configよりもrouteやoptimizeの方が実際のパフォーマンスにより影響ありました。多分、設定ファイルが小さく数少ないためがその違いと思います。しかし、現実では、DBクエリーやCSS、JS、画像などのダウンロードがはるかに時間がかかるので、まだ私のプロジェクトのスケールではちょっとした改善というところです。スケールがより大きくなるとかなりの差となるかもしれません。

入力のブラックリストとホワイトリスト

Sat, 03 Sep 2016 08:25:41 +0900

このブログを開始してから、もうすでに1年以上。RawのSQLを書いてコードに埋め込む日常から、Eloquentを使用したORMのコードへと日常へと移行しています。Eloquentに関しても、ブログを書き始めた頃からは理解が深まり、洗練されたLaravelのコードを書けるようになってきたこの頃です。

１年前に書いた「マスアサインメントで一括取り込み」のトピックで、EloquentのModelのクラスの属性fillableとguardedの話、1年の経験で学んだことを含めてここでもう一度説明します。

まず、話のお膳立てを。

DBテーブルmemberにおいて以下の項目があるとします。

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

MemberのModelは以下のような定義になります。

Member.php

...
class Member extends Model
{
    protected $table = 'member';
    protected $primaryKey = 'member_id';
    protected $fillable = ['name', 'email'];
    ...
}

$timestampsや$incrementingの定義は必要ないです。両方ともデフォルトでtrueなので。

入力フォームは、

で、email, password, nameの項目を入力できます。

以下のコントローラで、入力フォームから入ってきた値は以下のコードでDBに保存できます。

MemberController.php

...
class MemberController extends Controller
{
    ...
    public store(Request $request)
    {
        $member = new Member;
        $member->fill($request->all())->save();
        ...
    }
    ...
}

しかし、先ほどの$fillable定義により、DBに保存されるのは、emailとnameのみです。実行されるSQLは以下で、他の入力された値は無視されるので、passwordはDBはデフォルトの空のままです。つまり、$fillableは、DBに入力したい値をリストするホワイトリストです。ちなみに、created_at, updated_atの項目は、Eloquentにより自動的に保存時の日時を記録します。

逆に、DBに入れたくない項目をリストするなら、つまりブラックリストを定義したいなら、$fillableの代わりに、$guardedを使用します。

Member.php

...
class Member extends Model
{
    protected $table = 'member';
    protected $primaryKey = 'member_id';
    protected $guarded = ['member_id', 'active_flag', 'password'];
    ...
}

以上がマスアサイメントの使用の仕方で、意図的あるいは間違って入力フォームから、DBへ保存されるのを防いでくれます。

$fillableや$guardedの目的を理解したところで、２つ問題。

まず、

active_flagやpasswordなどマスアサインメントで相手にしない項目の値はどうやってDBに保存するのでしょう？

これは、通常のオブジェクトの値のアサインメントで行います。

...
    public store(Request $request)
    {
        $member = new Member;
        $member->active_flag = 'Y'; //デフォルト
        $member->password = bcrypt($request->password);　//ハッシュ値に変換
        $member->fill($request->all())->save();
        ...
    }
...

次に、 入力画面によりDBに入れたい項目が違う場合は、どう$fillableを設定？

例えば、管理画面で会員の情報を編集する画面。そこでは、会員が有効か無効のフラッグ(active_flag)、そして会員に関するノート(memo)も付加情報としてDBに保存したいです。もちろん、裏で使用するのは、同じMemberのクラスなので、同じ$fillableは使えないですね。

１つは、先の値のアサイメント使用する方法。

    $member->active_flag = $request->active_flag;
    $member->memo = $request->memo;
    $member->fill($request->all())->save();

しかし、これではもっと項目が増えたら面倒です。

$fillableを使用するのではなく、先のように$guardedをMemberで定義して、以下のようにコントローラにおいて、独自の$fillableを使用します。

...
    public store(Request $request)
    {
　　　　 $fillable = ['email', 'name'];
        $input = array_only($request->all(), $fillable);
        $member = new Member;
        $member->active_flag = 'Y';
        $member->password = Hash::make($request->password);
        $member->fill($input)->save();
        ...
    }

    public edit(Member $member, Request $request)
    {
        $fillable = ['email', 'name', 'active_flag', 'memo'];
        $input = array_only($request->all(), $fillable);
        $member->fill($input)->save();
        ...
    }
...

array_onlyの関数は、Laravelのヘルパー関数です。

routesを使いこなす（５）モデルとのバインディング

Fri, 26 Aug 2016 12:22:41 +0900

ユーザーがアクセスするURLを理解して、必要な関数にマップするのがroutes.phpの基本的な仕事です。

それらのURLには、以下のようにいろいろな形があります。

http://localhost/admin/login
http://localhost/admin/product/156
http://localhost/admin/product/156/edit

さて、上の例の156の数字は、DBテーブルのproductの主キーの値なのですが、Laravelはこの値をどのようにコントローラに取り込むのでしょう？

まず、前回のroutes.phpの設定を見てみましょう。

Route::resource('product', 'ProductController');

は、

php artisan route:list

の出力では以下のようなマップになります。

+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+
| Domain | Method    | URI                                | Name                   | Action                                                                | Middleware      |
+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+
|        | POST      | admin/product                      | admin.product.store    | App\Http\Controllers\Admin\ProductController@store                    | web             |
|        | GET|HEAD  | admin/product                      | admin.product.index    | App\Http\Controllers\Admin\ProductController@index                    | web             |
|        | GET|HEAD  | admin/product/create               | admin.product.create   | App\Http\Controllers\Admin\ProductController@create                   | web             |
|        | GET|HEAD  | admin/product/{product}            | admin.product.show     | App\Http\Controllers\Admin\ProductController@show                     | web             |
|        | DELETE    | admin/product/{product}            | admin.product.destroy  | App\Http\Controllers\Admin\ProductController@destroy                  | web             |
|        | PUT|PATCH | admin/product/{product}            | admin.product.update   | App\Http\Controllers\Admin\ProductController@update                   | web             |
|        | GET|HEAD  | admin/product/{product}/edit       | admin.product.edit     | App\Http\Controllers\Admin\ProductController@edit                     | web             |
+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+

URIの部分を見てください。

例えば、7行目の

admin/product/{product}

は、

ProductController@show

にマップされています。

そして156のIDは、この{product}の部分に対応します。

admin/product/{product}/edit

も同じことです。

対応するコントローラのメソッドを見ると、

ProductController.php

namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use App\Http\Requests;
use App\Models\Product;

class ProductController extends Controller
{
    /**
     * 表示画面
     *
     * @param  \App\Models\Product $product
     * @return \Illuminate\Http\Response
     */
    public function show(Product $product)
    {
        return $product->name; //画面に商品名を表示
    }
...

showのパラメータが、数字でなくモデルのProductのタイプになっていますね。これは、Laravelが自動的に、IDの数字をもとに、

$product = Product::find(156);

のようなモデルバインディング（紐づけ）操作を行って、Eloquentのオブジェクトを生成して、メソッドの中で使用できるようにしてくれているのです。便利ですね。

さて、product_id = 156に対応するDBレコードがない場合はどうなるのでしょう？

Sorry, the page you are looking for could not be found.
2/2 NotFoundHttpException in Handler.php line 102: No query results for model [App\Product]. 

1/2 ModelNotFoundException in Builder.php line 290: No query results for model [App\Product].

「検索結果が空」の404エラーとなります。

今度は、上のshowの関数のパラメータ名を以下のように変えたとしたら、どうなるのでしょう？

    public function show(Product $a_product)
    {
        return $a_product_name;//画面は空
    }

この場合、$a_project_nameにはDBレコードが入らず、単にProjectの新規オブジェクトとなり、画面には何も表示されません。

つまり、パラメータ名は、{product}とまったく同じ名前である必要があるということです。ミススペルに気をつけましょう。

さて、今度は、product_idではなく、例えば、skuという商品番号の項目の値でレコードを引っ張ってきたいときはどうするのでしょう？　

つまり、

http://localhost/admin/product/ABCDE

でアクセスしたい。そこでは、ABCDがskuの値とします。

その場合は、Productのモデルの定義で、

Product.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    protected $table = 'product';
    protected $primaryKey = 'product_id';

    public function getRouteKeyName()
    {
        return 'sku';
    }
　　...
}

のように、getRouteKeyNameの関数を作成して、skuをリターンすれば、product_idの代わりに以下のようにオブジェクトを作成してくれます。

$product = Product::where('sku', 'ABCD')->first();

もちろん、skuは、productのDBテーブルで、主キーと同様に１つのレコードを特定するためにユニークなキーを持つ必要あります。

最後に、

http://localhost/admin/product/156?print=Y

の場合、printの値はどう取ってくるのでしょう？

これはshowメソッドを以下のように変更して、

ProductController.php

...
    /**
     * 表示画面
     *
     * @param  \App\Models\Product $product
     * @param  \Illuminate\Http\Request
     * @return \Illuminate\Http\Response
     */
    public function show(Product $product, Request $request)
    {
        $print = $request->input('print');

        return $print;
    }
...

printの値の取得が可能です。ここ、関数のパラメータの順番はURLでの順番とは関係ありません。逆でも同じ結果となります。先に説明したように、{product}の名前と一致する変数名でLaravelは判断するからです。

バリデーション (3) 既存バリデーションの置き換え

Mon, 15 Aug 2016 10:27:51 +0900

Laravelには最初から利用可能なバリデーションルールが多数存在していますが、そのいくつかは実用にならなかったり、自分好みに挙動を変えたりしたいこともあります。

CustomValidator クラスは標準 Validator を継承していますので、これらを置き換えて上書きすることが可能です。

vendor/laravel/framework/src/Illuminate/Validation/Validator.php

ここから関数宣言をコピーして、前回作成した CustomValidator クラスのファイルに貼り付けて編集します。引数はそれぞれの関数によって異なりますし、宣言が public ではなく protected であることに注意してください。

email

標準の email バリデーションは実在してるメールアドレスがエラー判定になることがあります。これを解決するために正規表現による判定に置き換えてみたものです。

    /**
     * email
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    protected function validateEmail($attribute, $value)
    {
        return (preg_match("/^([*+!.&#$|\'\\%\/0-9a-z^_`{}=?~:-]+)@(([0-9a-z-]+\.)+[0-9a-z]{2,10})$/i", $value));
    }

管理画面では、メール送信者の指定などで名前付きメールアドレスの入力を容認する場面もあります。ついでに email_with_name を作成しておきましょう。

クラスメソッドとして関数を書いていますので、内部で他のバリデーションルールを呼び出して使用することができます。ここでは先に上書きした email を使用するので $this->validateEmail() で呼び出していますが、標準ルールを呼び出すなら parent::validateEmail() となります。

    /**
     * email_with_name
     *
     * @param string $attribute
     * @param string $value
     * @return true
     */
    public function validateEmailWithName($attribute, $value)
    {
        if (preg_match('/<(.*)>$/', $value, $m)
        {
            $value = $m[1];
        }

        return $this->validateEmail($attribute, $value);
    }

alpha, alpha_dash, alpha_num

これらアルファベット系の標準バリデーションは、全角英数字の文字コードを通します。

半角のasciiコードだけの入力許可に絞るため、これらも正規表現によるバリデーションルールに置き換えます。

/**
 * alpah
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlpha($attribute, $value)
{
    return (preg_match("/^[a-z]+$/i", $value));
}

/**
 * alpah_dash
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlphaDash($attribute, $value)
{
    return (preg_match("/^[a-z0-9_-]+$/i", $value));
}

/**
 * alpah_num
 *
 * @param string $attribute
 * @param string $value
 * @return true
 */
protected function validateAlphaNum($attribute, $value)
{
    return (preg_match("/^[a-z0-9]+$/i", $value));
}

ただし、ユーザが入力した全角英数に対してただエラーを返すようなユーザーインターフェースは褒められたものではありませんね。

入力を受け付けてからphpで半角に変換するという方法もありますが、私たちはjQueryスクリプトで入力前に変換する方法を選択しています。

jQueryスクリプトの例:

			var toHankaku = function (strVal){
				// 半角変換
				var halfVal = strVal.replace(/[！-～]/g, function(tmpStr) {
					// 文字コードをシフト
					return String.fromCharCode(tmpStr.charCodeAt(0) - 0xFEE0);
				});

				// 文字コードシフトで対応できない文字の変換
				halfVal = halfVal.replace(/”/g, "\"")
					.replace(/[ｰー―－‐]/, "-")
					.replace(/’/g, "'")
					.replace(/‘/g, "`")
					.replace(/￥/g, "\\")
					.replace(/　/g, " ")
					.replace(/?/g, "~");

				return halfVal;
			};

			$("input.en").change(function() {
				var $this = $(this);
				$this.val(toHankaku($this.val()));
			});

バリデーション (2) CustomValidatorを追加

Sun, 14 Aug 2016 11:35:17 +0900

カスタムバリデーションのクラスを追加するには、サービスプロバイダーで次のようにクラスを登録します。

追加するクラスの名前や位置はどのようなものでもかまいせん。ここでは、ディレクトリパス app/Services に CustomVaidator.phpを作成し、AppServiceProvider に登録することにします。

app/Providers/AppServiceProvider.php

<?php

namespace App\Providers;
 
use Validator;
use Illuminate\Support\ServiceProvider;
use App\Services\CustomValidator;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
         Validator::resolver(function($translator, $data, $rules, $messages)
        {
            return new CustomValidator($translator, $data, $rules, $messages);
        });
    }
 
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

次に、標準の Validator を継承する CustomValidator を作成します。前回 AppServiceProvier.php に直接登録したバリデーションルールを、こちらに移します。

app/Service/CustomValidator.php

<?php

namespace App\Services;

class CustomValidator extends \Illuminate\Validation\Validator 
{
    /**
     * kana
     *
     * @param string $attribute
     * @param string $value
     * @return bool
     */
     public function validateKana($attribute, $value)
     {
        // かな、半角空白、全角空白、全角記号を許可
        return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
     }
}

こうして専用のバリデーションクラスを作成すると、それぞれのバリデーションルールは通常のメソッドとして実行できるようになり、ユニットテストの作成も容易になります。

$bool = CustomValidator::validateKana('kana', $request->get('kana'));

前回との重複になりますが、エラーメッセージをバリデーション言語ファイルの「Validation Language Lines」グループに追加します。

'unique' => ':attribute に指定された値はすでに存在しています',
'url'    => ':attribute のフォーマットが正しくありません',
 
// カスタムバリデーション
 
'kana'   => ':attribute は全角のひらがなで入力してください',

これでふりがなバリデーションをどこでも利用できるようになりました。

'name_kana' => 'required|kana',

次回から、このクラスにいろいろなルールを登録していきましょう。

ところで、ふりがなに「カタカナ」を強要するサイト設計が多いことに苛立つのは私だけでしょうか？無駄にカタカナを入力するとIMEの辞書学習が汚れ、その後の漢字変換のリズムが崩れるのです。名簿などの入力作業をすると誰でも体験できるでしょう。
カタカナルールは昔ながらの紙文化の遺物なのでしょう。手書きならばそのほうが識別しやすいに違いないですが、電子データにその配慮は必要ありませんよね。

routesを使いこなす（４）routeを名付ける

Sat, 13 Aug 2016 08:28:31 +0900

Laravelでは、routeに名前を付けることができます。いったいそれがどうした？と思いますが、これができることで便利なことが増えます。

まず、routeの名前の付け方から、

Route::get('admin/ranking/download', 'RankingController@download');

とroutes.phpに指定して、

php artisan route:list

を実行すると、

+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
| Domain | Method    | URI                     | Name                   | Action                                                |
+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
|        | GET|HEAD  | admin/ranking/download  |                        | App\Http\Controllers\Admin\RankingController@download |

を出力します。3列名のNameの列に注目してください。

今は空ですね。

しかし、

Route::get('admin/ranking/download', 'RankingController@download')->name('admin.ranking.download');

とすると、

+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
| Domain | Method    | URI                     | Name                   | Action                                                |
+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
|        | GET|HEAD  | admin/ranking/download  | admin.ranking.download | App\Http\Controllers\Admin\RankingController@download |

admin.ranking.downloadと名前が付きます。

現在は、URIのスラッシュ(/)をピリオド(.)に置き換えたフォーマットですが、admin:ranking_downloadでも、admin::rankingdownloadでもOKです。

さて、routeにresourceを使用するときはどうなるのでしょう？

例えば、

Route::resource('product', 'ProductController');

は、

+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+
| Domain | Method    | URI                                | Name                   | Action                                                                | Middleware      |
+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+
|        | POST      | admin/product                      | admin.product.store    | App\Http\Controllers\Admin\ProductController@store                    | web             |
|        | GET|HEAD  | admin/product                      | admin.product.index    | App\Http\Controllers\Admin\ProductController@index                    | web             |
|        | GET|HEAD  | admin/product/create               | admin.product.create   | App\Http\Controllers\Admin\ProductController@create                   | web             |
|        | GET|HEAD  | admin/product/{product}            | admin.product.show     | App\Http\Controllers\Admin\ProductController@show                     | web             |
|        | DELETE    | admin/product/{product}            | admin.product.destroy  | App\Http\Controllers\Admin\ProductController@destroy                  | web             |
|        | PUT|PATCH | admin/product/{product}            | admin.product.update   | App\Http\Controllers\Admin\ProductController@update                   | web             |
|        | GET|HEAD  | admin/product/{product}/edit       | admin.product.edit     | App\Http\Controllers\Admin\ProductController@edit                     | web             |
+--------+-----------+------------------------------------+------------------------+-----------------------------------------------------------------------+-----------------+

と自動で名前を付けてくれます。

routeに名前が付いたところで、どう使用するか見てみましょう。

echo route('admin.ranking.download');

は、

http://localhost/admin/ranking/download

となります。もちろん、localhostはライブ環境では実際のドメイン名となります。

ということは、

echo url('admin/ranking/download');

と同じになります。

引数があるときは、

echo route('admin.product.edit', 12);
echo url('admin/product', [12, 'edit']);

の出力は、両方とも、

http://localhost/admin/product/12/edit

となりますが、名前付きの方がわかりやすいですね。

このroute()は、

return redirect()->route('admin.product.show', 12);

のようにリダイレクトや、

{!! Form::open(['route' => ['admin.product.store'], 'method' => 'post']) !!}

のようにテンプレートでも使用可能です。

もちろん、名前付きのrouteをプログラムで使用するなら、そのrouteのURIを変えても何もプログラムで変更は要らないことになります。便利ですね。

さらに、URIに比べて比較的扱いやすい文字列なので、名前付きのrouteに対してユーザーの権限をDBで定義すれば、例えば、ログインしたユーザーの役割により、特定のrouteを実行するかどうかの権限の判断にも使用可能です。将来、この連載で扱う予定のトピックです。

routesを使いこなす（３）prefixでgroupを分割

Wed, 03 Aug 2016 23:37:08 +0900

開発しているプログラムの機能が増えてくると、必然的に定義するrouteの数が増えてきます。特に、マルチ認証ともなると、関わるプレイヤーの分だけで倍増する可能性があります。

例えば、ECのプロジェクトで、会員と管理者がプレイヤーとすると、ログインだけでも2通りのURIが必要となり、routeの設定は以下のように４つ必要となります。

routes.php

Route::group(['middleware' => 'web'], function () {
	Route::get('user/login', 'User\Auth\AuthController@showLoginForm');
	Route::post('user/login', 'User\Auth\AuthController@login');
	Route::get('admin/login', 'Admin\Auth\AuthController@showLoginForm');
	Route::post('admin/login', 'Admin\Auth\AuthController@login');
});

実際作成されるrouteは、

php artisan route:list

の実行によると、

+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+
| Domain | Method   | URI         | Name | Action                                                       | Middleware      |
+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+
|        | POST     | admin/login |      | App\Http\Controllers\Admin\Auth\AuthController@login         | web,guest:admin |
|        | GET|HEAD | admin/login |      | App\Http\Controllers\Admin\Auth\AuthController@showLoginForm | web,guest:admin |
|        | POST     | user/login  |      | App\Http\Controllers\User\Auth\AuthController@login          | web,guest       |
|        | GET|HEAD | user/login  |      | App\Http\Controllers\User\Auth\AuthController@showLoginForm  | web,guest       |
+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+

これに他のいくつもの機能を加えていくと、管理が大変になってきます。現在私が管理しているプロジェクトでは、管理画面だけで300近いrouteが存在します。そうなると、タイプミスも増えるでしょうし、一目見て理解もしにくいです。

管理性を高める１つの方法は、prefixを使用してroutesのgroupを分割します。

先の例では、userとadminのprefixを用いて、それぞれのプレイヤーに１つのgroupを作成します。

Route::group(['prefix' => 'user', 'namespace' => 'User', 'middleware' => 'web'], function () {
	Route::get('login', 'Auth\AuthController@showLoginForm');
	Route::post('login', 'Auth\AuthController@login');
});

Route::group(['prefix' => 'admin', 'namespace' => 'Admin', 'middleware' => 'web'], function () {
	Route::get('login', 'Auth\AuthController@showLoginForm');
	Route::post('login', 'Auth\AuthController@login');
});

行数が少し増えたかもしれませんが、重複部分がなくなってすっきりしただけでなく、グループ分けで理解しやすいコードとなりましたね。さらに、namespaceを使用することで、コントローラのnamespaceも重複も省いています。

さて、実際生成されるrouteはどうなのでしょう？この変更で変わってしまっては問題です。

php artisan route:list

を実行すると、

+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+
| Domain | Method   | URI         | Name | Action                                                       | Middleware      |
+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+
|        | POST     | admin/login |      | App\Http\Controllers\Admin\Auth\AuthController@login         | web,guest:admin |
|        | GET|HEAD | admin/login |      | App\Http\Controllers\Admin\Auth\AuthController@showLoginForm | web,guest:admin |
|        | POST     | user/login  |      | App\Http\Controllers\User\Auth\AuthController@login          | web,guest       |
|        | GET|HEAD | user/login  |      | App\Http\Controllers\User\Auth\AuthController@showLoginForm  | web,guest       |
+--------+----------+-------------+------+--------------------------------------------------------------+-----------------+

まったく先と同じです。

routesを使いこなす（２）resourceを使いこなす

Thu, 28 Jul 2016 13:39:45 +0900

resourceを使い始めて、まず思うのは、いつもいつも index, store, create, edit, update, destroyの一式が必要というわけではないことです。

例えば、以下のようなレポートタイプのコントローラなら、

indexだけで十分なので、以下のようにonlyを使い他のrouteを無効にします。

Route::resource('ranking', 'RankingController.php', ['only' => ['index']]);

また、追加と編集だけで、削除が要らないコントローラなら、exceptを使い、index, store, create, edit, updateだけの使用を可能にします。

Route::resource('no_destroy', 'NoDestroyController.php', ['except' => ['destroy']]);

便利ですね。

さらに、 index, store, create, edit, update, destroyだけでないrouteが必要なときもあります。

例えば、先の「売上ランキング」のレポートに、結果をCSVでダウンロードしたいとします。

今のところ、indexしか使用していないので、storeでも使う？

しかし、名前がいまひとつ。理想は、ranking/downloadとしたいです。

このような場合は、

Route::get('admin/ranking/download', 'RankingController@download');
Route::resource('admin/ranking', 'RankingController', ['only' => ['index']]);

と、独自のrouteをRoute::resourceの前に追加します。

php artisan route:list

の出力は、

+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
| Domain | Method    | URI                     | Name                   | Action                                                |
+--------+-----------+-------------------------+------------------------+-------------------------------------------------------+
|        | GET|HEAD  | admin/ranking           | admin.ranking.index    | App\Http\Controllers\Admin\RankingController@index    |
|        | GET|HEAD  | admin/ranking/download  |                        | App\Http\Controllers\Admin\RankingController@download |

バリデーション（１）Validatorファサードのextend

Tue, 19 Jul 2016 10:28:50 +0900

はじめまして。ブログ主筆khino氏と同じプロジェクトで仕事をしてます。彼とは別テーマを平行して掲載しますので、これまで順番に読み進めていた方にはちょっと読みにくくなるかもしれませんが、ご容赦ください。

私の最初のテーマはカスタムバリデーションルールです。このシリーズでは、Validatorファサードの基本的な使い方から始めて、より複雑なルールの定義の仕方や、laravel 5.2で追加された配列定義のカスタムバリデーションまで紹介する予定です。

まずは、Validatorファサードのextendを利用する方法から。

コントローラやモデルに依存しない一般的なルールの追加は、サービスプロバイダーの中で定義するのが一般です。

app/Providers/AppServiceProvider.php

<?php

namespace App\Providers;

use Validator;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
         Validator::extend('kana', function($attribute, $value, $parameters, $validator) {
            // 半角空白、全角空白、全角記号、全角かなを許可
            return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
        });    
    }

    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

例は全角ひらがなだけを許可するバリデーションですが、見たとおり正規表現による判定を行っています。カスタムバリデーションを使いこなす前に、正規表現を使いこなさなければなりませんが、それはまた別に勉強してくださいね。

エラーメッセージはバリデーション言語ファイルに追加しておきましょう。追加するのは「Validation Language Lines」のグループの末尾です。

resouces/lang/ja/validation.php に追加

    'unique' => ':attribute に指定された値はすでに存在しています',
    'url'    => ':attribute のフォーマットが正しくありません',

    // カスタムバリデーション

    'kana'   => ':attribute は全角のひらがなで入力してください',

「Custom Validation Language Lines」のグループは、属性名とルールの組み合わせでメッセージを独自のものにすると言う意味での「カスタム」です。

    'custom' =>[
        'password'  => [
            'alpha_num' => 'パスワードは10文字以上40文字以下の英数字で入力してください',
            'between'   => 'パスワードは10文字以上40文字以下の英数字で入力してください',
        ],
    ],

また、言語ファイル末尾の「Custom Validation Attributes」に属性名の訳を追加しておきましょう。メッセージ内の「:attribute」の部分に用いられるようになります。

    'attributes' =>[
        'name'  => '名前',
        'email' => 'メールアドレス',
    ],

また、モデルやコントローラに依存して、そこでしか使用しないバリデーションなら、次のようにフォームリクエストで定義することも可能です。

しかし、この位置ではユニットテストが作りにくくなるので、次回で説明するようにカスタムバリデーションクラスを作成して、すべてのバリデーションを１つにまとめて管理するほうが良いように思います。

app/Http/Requests/MemberRequest.php

<?php

namespace App\Http\Requests;

use Validator;
use App\Http\Requests\Request;
use App\Member;

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

    public function rules()
    {
        Validator::extend('kana', function($attribute, $value, $parameters, $validator) {
            // 半角空白、全角空白、全角記号、全角かなを許可
            return preg_match("/^[ぁ-んー 　！-＠［-｀｛-～]+$/u", $value);
        });

        $member = Member::find($this->member_id);

        switch($this->method())
        {
        case 'POST':
            return [
                'email' => 'required|email|unique:member,email',
                'password'  => 'required|min:6|max:20|confirmed',
                'name' => 'required',
                'kana'  => 'required|kana'
            ];

        case 'PUT':
        case 'PATCH':
            return [
                'email' => 'required|email|unique:member,email,'.$member->member_id.',member_id',
                'name' => 'required',
                'kana'  => 'required|kana'
            ];
        }
    }

    public function attributes()
    {
        return [
            'email'	=> 'メールアドレス',
            'password' => 'パスワード',
            'name' => '名前',
            'kana' => 'ふりがな'
        ];
    }

    public function messages()
    {
        return [
            'kana'	=> ':attribute は全角ひらがなで入力してください',
        ];
    }
}

routesを使いこなす（１）resourceを使う

Mon, 18 Jul 2016 04:46:59 +0900

私が開発・管理しているプロジェクトのひとつは、もともとは過去に人気があったCodeIgniterで書かれたもの。過去２年の間に、それをLaravelのバージョン４で書き直し、さらに更新して現在はLaravelのバージョン5.2となっています。

それゆえに、最初のLaravelを使っての書き換えは、Laravelを勉強しながらの書き換えで、知らないことが多く、Route::controllerを多用していました。

コントローラは以下のように作成して、

ProductController.php

class ProductController extends Controller
{
...
	public function getAdd() {...}
	public function postAdd() {...}
	public function getEdit(Product $product) {..}
	public function postEdit(Product $product) {..}
...
}

メソッドには、getやpostのプリフィックスが必要です。次は、routeを設定します。

routes.php

...
	Route::controller('product', 'ProductController.php');
...

これを

php artisan route::list

で実行して見るとこんな感じに出力されます。

+--------+--------------------------------+------------------------------------------------------------+-----------------------+-----------------------------------------------------------------------+-----------------+
| Domain | Method                         | URI                                                        | Name                  | Action                                                                | Middleware      |
+--------+--------------------------------+------------------------------------------------------------+-----------------------+-----------------------------------------------------------------------+-----------------+
|        | GET|HEAD                       | admin/product/add/{one?}/{two?}/{three?}/{four?}/{five?}  |                       | App\Http\Controllers\Admin\ProductController@getAdd                  | web             |
|        | POST                           | admin/product/add/{one?}/{two?}/{three?}/{four?}/{five?}  |                       | App\Http\Controllers\Admin\ProductController@postAdd                 | web             |
|        | GET|HEAD                       | admin/product/edit/{one?}/{two?}/{three?}/{four?}/{five?} |                       | App\Http\Controllers\Admin\ProductController@getEdit                 | web             |
|        | POST                           | admin/product/edit/{one?}/{two?}/{three?}/{four?}/{five?} |                       | App\Http\Controllers\Admin\ProductController@postEdit                | web             |
|        | GET|HEAD|POST|PUT|PATCH|DELETE | admin/product/{_missing}                                  |                       | App\Http\Controllers\Admin\ProductController@missingMethod           | web             |

さて、ここでの問題は、デフォルトでは、URIが、

admin/product/edit/{one?}/{two?}/{three?}/{four?}/{five?}

となりgetEditの関数のパラメータがrouteに反映されないことです。

うえは、

admin/product/{product}/edit

とあるべきです。

これを正しくするには、

routes.php

...
Route::model('product', 'App\Models\Product');  
...
Route::get('product/add', 'ProductController@getAdd');
Route::post('product/add', 'ProductController@getAdd');
Route::get('product/{product}/edit', 'ProductController@getEdit');
Route::post('product/{product}/edit', 'ProductController@getEdit');
...

と、やたらroutes.phpにおいての記述が多くなってしまいます。ウェブのアプリのほとんどは、DBでのレコードの閲覧、作成、編集、削除などの定型です。簡単にならないものでしょうか？

そこで、Route::resourceの登場です。

ちなみに、Route::controllerは、バージョン5.1まではLaravelのマニュアルに説明がありましたが、現バージョン5.2ではなくなりました（コードではまた対応はしているようです）。

もうRoute::controllerはリタイヤが近づいているということで、Route::resourceに切り替えるちょうど良い機会です。

まず、以下のコマンドを実行してひな形を作成します。

php artisan make:controller ProductController –resource

作成されたファイルを編集して、

ProductController.php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

use App\Http\Requests;

use App\Models\Product;

class ProductController extends Controller
{
    /**
     * 検索表示
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        //
    }

    /**
     * 新規作成画面
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
        //
    }

    /**
     * DBレコード新規作成
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function store(Request $request)
    {
        //
    }

    /**
     * 表示画面
     *
     * @param  \App\Models\Product $product
     * @return \Illuminate\Http\Response
     */
    public function show(Product $product)
    {
        //
    }

    /**
     * 編集画面
     *
     * @param  \App\Models\Product $product
     * @return \Illuminate\Http\Response
     */
    public function edit(Product $product)
    {
        //
    }

    /**
     * DBレコード編集
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \App\Models\Product $product
     * @return \Illuminate\Http\Response
     */
    public function update(Request $request, Product $product)
    {
        //
    }

    /**
     * DBレコード削除
     *
     * @param  \App\Models\Product $product
     * @return \Illuminate\Http\Response
     */
    public function destroy(Product $product)
    {
        //
    }
}

Route::Controllerと比較すると、resourceのメソッドは、

getAdd   → create
postAdd  → store
getEdit  → edit
postEdit → update

となります。

routesを設定すると、

routes.php

...
	Route::resource('product', 'ProductController.php');
...

php artisan route:list

の出力は、

+--------+-----------+------------------------------------+-----------------------+-----------------------------------------------------------------------+-----------------+
| Domain | Method    | URI                                | Name                  | Action                                                                | Middleware      |
+--------+-----------+------------------------------------+-----------------------+-----------------------------------------------------------------------+-----------------+
|        | POST      | admin/product                      | admin.product.store   | App\Http\Controllers\Admin\ProductController@store                    | web             |
|        | GET|HEAD  | admin/product                      | admin.product.index   | App\Http\Controllers\Admin\ProductController@index                    | web             |
|        | GET|HEAD  | admin/product/create               | admin.product.create  | App\Http\Controllers\Admin\ProductController@create                   | web             |
|        | GET|HEAD  | admin/product/{product}            | admin.product.show    | App\Http\Controllers\Admin\ProductController@show                     | web             |
|        | PUT|PATCH | admin/product/{product}            | admin.product.update  | App\Http\Controllers\Admin\ProductController@update                   | web             |
|        | DELETE    | admin/product/{product}            | admin.product.destroy | App\Http\Controllers\Admin\ProductController@destroy                  | web             |
|        | GET|HEAD  | admin/product/{product}/edit       | admin.product.edit    | App\Http\Controllers\Admin\ProductController@edit                     | web             |
|

URIも自動で設定され、さらに名前付きのroute (named route)も設定されていますね。

さて、admin.product.updateのPUTやPATCHはどうbladeのフォームで対応するのでしょう？HTMLの

のactionにはGETとPOST以外見たことありませんね。

もちろん、簡単です。

<form method="POST" action="admin/product/{{$product->product_id}}">
     {!! method_field('put') !!}
     . . .
</form>

method_field()は、Laravelのヘルパー関数で、以下と同じです。

<input type="hidden" name="_method" value="PUT">

そして、以前紹介した、Laravel Collectiveのフォームを使用するなら、

{!! Form::open(['route' => ['admin.product.update', $product->product_id], 'method' => 'put']) !!}
..
{!! Form::close !!}

ファイルのアップロード（8）プライベートに画像を表示

Sun, 29 May 2016 07:38:21 +0900

前回は、画像をパブリックに表示する方法を説明しましたが、今回は画像をプライベートに表示する方法です。

いくつか方法があります。

まず、前回のようにアップロードをパブリックの場所に保存して、特定のユーザーだけに表示のためのURLを教える。

しかし、DBから自動発行されるproduct_image_idを画像ファイル名に使用するなら、URLを操作することで他のファイルも見れてしまいます。

そうなら、画像のURLをわかりにくいように変えて、他の画像のURLを予想しにくくすることも可能です。

例えば、235.jpgとは見せずに、1f3870be274f6c49b3e31a0c6728957f.jpgにするとか。

それは、md5()を利用することで簡単に可能です。

    public function filename()
    {
        $ext = 'jpg';
 
        switch($this->mime)
        {
            case 'image/jpeg':
            case 'image/jpg':
                $ext = "jpg";
                break;
 
            case 'image/png':
                $ext = "png";
                break;
 
            case 'image/gif':
                $ext = "gif";
                break;
        }
 
        return sprintf("%d.%s", md5($this->product_image_id), $ext);
    }

よりセキュアにするには、DBに保存するときに、uniqid()あるいは、openssl-random-pseudo-bytes()を使用してランダムな値を生成して、その値をファイル名として保存するとか。要するに、IDのように連続な番号とはならないので、容易にファイル名を予測できないようにすることです。

しかし、究極は、ファイルをパブリックから見れない場所に保存して、それを表示する方法です。

例えば、storage/images/product/1.jpgのように、パブリックから見れないstorageのディレクトリに画像をアップロードするようにして、見せるときには、ログインしたユーザーと関連ある画像だけを、そのユーザーに表示する。

この場合は、パブリックに保存されている画像と違い、固定のURLを通してウェブサーバーに画像の表示を任せることはできません。逆に、あたかもウェブサーバーが画像ファイルを読んでデータをストリームするという作業と同じことをプログラムで行います。header()を使用すれば、そう難しいことではありません。

ProductController.php

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

use Log;

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

class ProductController extends Controller
{
	public function getImage(Product $product)
	{
		return view('user/product_image', compact('product'));
	}

	public function downloadImage(ProductImage $product_image)
	{
		//@TODO ここで、認証したユーザーに画像を表示していいかどうかをチェック。
		//そうでないなら、空の画像を表示

		$filename = $product_image->filename();

		header("Content-type: $product_image->mime name=$filename");
		header("Content-Disposition: attachment; filename=$filename");
		header("Content-Length: ".@filesize($product_image->path));
		header("Expires: 0");
		@readfile($product_image->path);
		exit;
	}
}

上で使用されるテンプレートは、

user/product_image.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">アップロードしたファイルを表示</div>
                <div class="panel-body">
                    <div>
                        @foreach ($product->product_images as $image)
                            <img src="{{ url('/user/product_image', $image->product_image_id) }}">
                        @endforeach
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

のようになります。

routes.phpは、以下のように認証保護された中でコールされます。

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {

	Route::get('login', 'User\Auth\AuthController@showLoginForm');
	Route::post('login', 'User\Auth\AuthController@login');
	Route::get('logout', 'User\Auth\AuthController@logout');
..
	Route::group(['middleware' => 'auth:user' ], function () {
		Route::get('home', 'User\HomeController@index');
..
		Route::get('product/{product}/image', 'User\ProductController@getImage');
		Route::get('product_image/{product_image}', 'User\ProductController@downloadImage');
	});
});

ファイルのアップロード（７）パブリックに画像を表示

Sun, 22 May 2016 03:34:31 +0900

アップロードしてサーバーに保存した画像ファイルを表示するには、いくつか方法があります。

前回のように、誰もが見れるパブリックな場所（public/images/product）にファイルを保存したなら、

ProductImage.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class ProductImage extends Model
{
	protected $table = 'product_image';
	protected $primaryKey = 'product_image_id';
	public $incrementing = true;
	public $timestamps = true;

	protected $fillable = [
		'product_id', 'mime'
	];

	protected $baseUri = 'images/product';

	public function getUrlAttribute()
	{
		return url($this->baseUri, $this->filename());
	}

	public function storeImage($file)
	{
		$file->move(public_path($this->baseUri), $this->filename());
	}

	public function filename()
	{
		$ext = 'jpg';

		switch($this->mime)
		{
			case 'image/jpeg':
			case 'image/jpg':
				$ext = "jpg";
				break;

			case 'image/png':
				$ext = "png";
				break;

			case 'image/gif':
				$ext = "gif";
				break;
		}

		return sprintf("%d.%s", $this->product_image_id, $ext);
	}

と、getUrlAttribute()のアクセサーを作成して、

product_image.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">File Upload</div>
                <div class="panel-body">
                    <div class="form-group{{ $errors->has('file') ? ' has-error' : '' }}">
                        <div>
                            <form
                                method="POST"
                                action="/demo/public/admin/product/{{ $product->product_id }}/image"
                                class="dropzone"
                                id="imageUpload"
                                enctype="multipart/form-data">
                                {{ csrf_field() }}
                            </form>
	                    </div>
                    </div>

                    <div>
                        @foreach ($product->product_images as $image)　// １商品に対して複数の画像を表示
                            <img src="{!! $image->url !!}">
                        @endforeach
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

@section('script')

Dropzone.options.imageUpload = {
    dictDefaultMessage: 'アップロードするファイルをここへドロップしてください',
    maxFiles: 10,
    acceptedFiles: '.jpg,.jpeg,.gif,.png',
    maxFilesize: 5, // 5 MB
    init: function () {
        this.on('queuecomplete', function () {　//　アップロードがすべて完了したら、画面を更新してアップロードした画像を表示
            location.reload();　
        });
    }
}
@endsection

のように、$image->urlとしてテンプレートでコールして、/demo/public/images/product/4.pngのような値を生成し画像をブラウザに表示します。

また、以下のEloquentのRelationshipを使用して、１商品に対して複数アップロードした画像を表示させています。

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    protected $table = 'product';
    protected $primaryKey = 'product_id';
    public $incrementing = true;
    public $timestamps = true;

    protected $fillable = [
        'name'
    ];

    public function product_images()
    {
        return $this->hasMany('App\ProductImage');
    }

}

さて、以上は、管理者が管理画面からアップロードした画像を、同画面で表示する例ですが、ユーザー画面でも$image->urlを使用すれば、誰にでも同じ画像を見せることが可能です。

しかし、アップロードしたファイルを誰からも見えない場所に保存して、例えば、認証したユーザーしか見れないという制限が必要なら、どうしましょう？

ファイルのアップロード（６）異なる画像フォーマットの対応

Tue, 17 May 2016 00:02:38 +0900

画像のファイルのアップロードの基本を学んだところで、少し実践的なことを考えてみましょう。

例えば、ECサイトなら、販売する商品画像を管理画面でアップロードします。しかし、重複となるかもしれないので、アップロードした画像のファイル名で保存することはできません。

そこで、DBが自動発行する商品のIDあるいは商品番号を利用してファイル名を変えてサーバーに保存します。

例えば、Nikeの靴.jpgというファイル名のファイルをアップするなら、その商品のIDが234なら、234.jpgとしてサーバーに保存します。

もう１つ考慮必要なことは、アップする画像はいつも、JPEGの形式とは限らないことです。GIFかもしれませんし、PNGのフォーマットかもしれません。もちろん、手元でJPEGに変換してからアップもできますが、サーバーで違う画像フォーマットに対応できるならそれに越したことありません。

これらのフォーマットの違いの情報を対応するには、アップしたMIMEの情報あるいはファイルの拡張子をDBに保存する必要あります。

まず、DBの設計から始めましょう。ここで必要なのは以下の２つのテーブル、

product

+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| product_id | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| name       | varchar(255)     | NO   |     | NULL    |                |
| created_at | timestamp        | YES  |     | NULL    |                |
| updated_at | timestamp        | YES  |     | NULL    |                |
+------------+------------------+------+-----+---------+----------------+

product_image

+------------------+------------------+------+-----+---------+----------------+
| Field            | Type             | Null | Key | Default | Extra          |
+------------------+------------------+------+-----+---------+----------------+
| product_image_id | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| product_id       | int(11)          | NO   | MUL | NULL    |                |
| mime             | varchar(255)     | NO   |     | NULL    |                |
| created_at       | timestamp        | YES  |     | NULL    |                |
| updated_at       | timestamp        | YES  |     | NULL    |                |
+------------------+------------------+------+-----+---------+----------------+

一応、productとproduct_imageのテーブルの関係は、１対多の関係となります。つまり、商品１に対して複数の画像を持つことが可能。

migrationを作成して、以下のように作成してテーブルを作成します。

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

class CreateProductTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
		Schema::create('product', function (Blueprint $table) {
			$table->increments('product_id');
			$table->string('name');
			$table->timestamps();
		});
    }

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

class CreateProductImageTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
		Schema::create('product_image', function (Blueprint $table) {
			$table->increments('product_image_id');
			$table->integer('product_id');
			$table->string('mime');
			$table->timestamps();
			$table->index('product_id');
		});
    }

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

次は管理画面でのルートの作成。

...
Route::group(['prefix' => 'admin', 'middleware' => 'web'], function () {
    ...
    Route::get('product/{product}/image', 'Admin\ProductController@getImage');
    Route::post('product/{product}/image', 'Admin\ProductController@postImage');
    Route::resource('product', 'Admin\ProductController');
    ...
});
...

CRUD(Create, Read, Update, Delete)のオペレーションは、Route::resource(‘product’, ..に任せて、画像に関しては、product/{product}/imageのURIを使用して、それらのメソッドはすべてProductControllerに収めます。今回は、前回と違って管理画面での作業のことに注意してください。

それらの定義は、

ProductController.php

namespace App\Http\Controllers\Admin;

use Illuminate\Http\Request;

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

class ProductController extends Controller
{
	public function getImage(Product $product)
	{
		return view('admin/product_image', compact('product'));
	}

	public function postImage(Request $request, Product $product)
	{
		$file = $request->file('file');

		$image = new ProductImage;

		$image->product_id = $product->product_id;
		$image->mime = $file->getClientMimeType();

		$image->save();  // product_imageにレコードを作成

		$image->storeImage($file);　// アップロードしたファイルを移動
	}

}

となり前回とほぼ同じようなコードです。しかし、前回と違って、product_imageのテーブルに、アップロードしたファイルのMIME情報を入れてレコードを作成しています。

ProductImage.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class ProductImage extends Model
{
    protected $table = 'product_image';
    protected $primaryKey = 'product_image_id';
    public $incrementing = true;
    public $timestamps = true;

    protected $fillable = [
        'product_id', 'mime'
    ];

    public function storeImage($file)
    {
		$file->move(public_path('images/product'), $this->filename());
    }

    public function filename()
    {
    	$ext = 'jpg';

    	switch($this->mime)
    	{
    		case 'image/jpeg':
    		case 'image/jpg':
    			$ext = "jpg";
    			break;

  			case 'image/png':
  				$ext = "png";
  				break;

  			case 'image/gif':
  				$ext = "gif";
  				break;
    	}

    	return sprintf("%d.%s", $this->product_image_id, $ext);
    }
}

filenameでは、レコードで自動発行されたproduct_image_idとMIMEをもとにした拡張子を合わせて移動先のファイル名を作成します。

コントローラにより使用されるテンプレートも少し違います。

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">File Upload</div>
                <div class="panel-body">
                    <div class="form-group{{ $errors->has('file') ? ' has-error' : '' }}">
                        <div>
                            <form
                                method="POST"
                                action="/demo/public/admin/product/{{ $product->product_id }}/image"
                                class="dropzone"
                                id="imageUpload"
                                enctype="multipart/form-data">
                                {{ csrf_field() }}
                            </form>
	                    </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

@section('script')

Dropzone.options.imageUpload = {
    dictDefaultMessage: 'アップロードするファイルをここへドロップしてください',
    maxFiles: 10,
    acceptedFiles: '.jpg,.jpeg,.gif,.png',
    maxFilesize: 5, // 5 MB
}
@endsection

ファイルのアップロードの結果は以下のようにレコードの生成となります。

+------------------+------------+------------+---------------------+---------------------+
| product_image_id | product_id | mime       | created_at          | updated_at          |
+------------------+------------+------------+---------------------+---------------------+
|                1 |          1 | image/jpeg | 2016-05-15 19:46:24 | 2016-05-15 19:46:24 |
|                2 |          1 | image/gif  | 2016-05-15 19:46:24 | 2016-05-15 19:46:24 |
|                3 |          1 | image/png  | 2016-05-15 19:46:24 | 2016-05-15 19:46:24 |
+------------------+------------+------------+---------------------+---------------------+

ファイルのアップロード（５）複数の画像ファイルをアップロード

Mon, 09 May 2016 05:20:42 +0900

Dropzone.jsを使用する利点は、ファイルアップロードの途中経過を表示するようになりUIが良くなるだけでありません。１画面で複数の画像ファイルを一度にアップすることができます。

もちろん、以下のように複数のファイルのアップロードは、Dropzone.jsを使用しなくても可能です。

<form
    method="POST"
    action="/demo/public/user/upload"
    class="form-horizontal"
    role="form"
    enctype="multipart/form-data">
    {{ csrf_field() }}
...
    <input type="file" name="file1">
    <input type="file" name="file2">
...
</form>

しかし、以下のポストで説明したように、

ファイルのサイズの制限・制限なしでも制限ある

ウェブサーバーによる制限により、１フォームでアップロードできるファイルの数は、すべてのファイルを足したファイルのサイズになります。

例えば、

php.ini

post_max_size = 2M
upload_max_filesize = 1M

の設定なら、１フォームでは、最大１Mのファイルが２つまでしかアップロード可能でありません。

しかし、Dropzone.jsを使用すれば、ajaxを使用するので、それぞれのファイルアップロードは、１フォームで１つのファイルのアップロードとなり、この例では、1Mファイルをいくつでもアップロード可能となります。

そして、この複数のファイルのアップロードに対応するプログラムの変更といえば、

まず、フロントエンド、

Dropzone.jsでアップロード途中経過を表示

とまったく同じです。変更はありません。

アップロード時、複数のファイルを選択してドラッグするか、ファイルダイアログで複数のファイルを選択して実行すれば以下のようにアップされます。

バックエンドは、

UserController.php

namespace App\Http\Controllers\User;
 
use Illuminate\Http\Request;
 
use App\Http\Requests;
use App\Http\Controllers\Controller;
 
use Validator;
 
class UserController extends Controller
{
...
    public function getUpload()
    {
        return view('user/upload');
    }
 
    public function postUpload(Request $request)
    {
        $file = $request->file('file');
        $filename = $file->getClientOriginalName();
        $file->move(public_path('images'), $filename)
    }
}

と、アップしたファイル名で、/public/imagesのディレクトリに保存するように変更します。

同時にアップするファイル数を制限したいなら、

<script type="text/javascript">
       
Dropzone.options.imageUpload = {
    dictDefaultMessage: 'アップロードするファイルをここへドロップしてください',
    acceptedFiles: '.jpg, .jpeg',
    maxFilesize: 5 // 5MBまで
　　maxFiles: 2 // ファイルは２つまでアップロード可能
}
</script>

と、Dropzone.jsの設定で、maxFilesを指定します。

このように３番目のファイルは、アップロード不可となります。

ファイルのアップロード（４）バックエンド

Tue, 03 May 2016 13:50:00 +0900

前回のDropzone.jsを使用したファイルアップロードのフロントエンドに対して、サーバーサイドのバックエンドをLaravelでプログラムします。つまり、アップロードされたファイルを受け取るプログラムです。

まず、routes.phpにルートの追加となりますが、前回の設定を見てみますと、

Dropzoneを使用したファイルアップロード

<div class="form-group{{ $errors->has('file') ? ' has-error' : '' }}">
    <div>
　       <form
             method="POST"
             action="/demo/public/user/upload"
             class="dropzone"
             id="imageUpload"
             enctype="multipart/form-data">
             {{ csrf_field() }}
         </form>
    </div>
</div>

のパラメータのactionで指定している/demo/public/user/uploadがルートとなります。

となると、routes.phpでは、

...
Route::get('upload', 'User\UserController@getUpload');
Route::post('upload', 'User\UserController@postUpload');
...

のようになります。getの方は前回の画面を表示するとして、postは、サーバーでアップされるファイルの処理となります。

UserController.php

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

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

use Validator;

class UserController extends Controller
{
...
	public function getUpload()
	{
		return view('user/upload');
	}

	public function postUpload(Request $request)
	{
		...
		$request->file('file')->move(public_path('images'), 'test.jpg');
	}
}

ファイルをアップロードすると、phpは、/tmpのディレクトリに一時的なファイルを作成します。上の２９行目では、それをpublic/imagesのディレクトリにtest.jpgと命名してファイルを保存します。

最後に、上のpostUpload()の関数の最後において、通常あるredirect()文がないことに気づきましたか？この関数は、Dropzone.jsによりajaxでコールされるので、画面を更新するためのredirect()は要らないのです。

ファイルのアップロード（３）Dropzone.jsでアップロード途中経過を表示

Sun, 17 Apr 2016 08:01:28 +0900

今まで話したファイルアップロードは、基本でもっとも簡単にプログラムできるものです。

しかし、アップロードするファイルのサイズが大きく、アップロードに時間がかかるようになると、送信ボタンを押してからじ～っと何も起きない画面を見ているのは、退屈でもありちょっと心配ですね。これ、ちゃんと動いているのかなと。

要は、「アップロード中です」とか「８０％アップロード完了」したとか、しかもそれをビジュアルで伝えてくれれば最高です。それを行ってくれるのが今回紹介するツール、Dropzone.jsです。

「アップロードするファイルをここへドラッグしてください」にファイルをドラッグすると、

このように、アップロードの画像ファイルのサムナイルの中にアップロードの途中経過をバーで表示してくれます。

ファイル完了時は、

必要な設定は、

https://github.com/enyo/dropzone/archive/master.zip

よりダウンロードして解凍してから、assets/jsのディレクトリに入れて、画面のテンプレートを以下のように編集します。

Dropzoneを使用したファイルアップロード

<div class="form-group{{ $errors->has('file') ? ' has-error' : '' }}">
    <div>
　       <form
             method="POST"
             action="/demo/public/user/upload"
             class="dropzone"
             id="imageUpload"
             enctype="multipart/form-data">
             {{ csrf_field() }}
         </form>
    </div>
</div>

気づきましたか、やがないことに。

ちなみにデフォルトのファイル変数名はfileですが、設定変更できます。

そして、レイアウトのテンプレートを以下のように編集します。

...
<head>
...
<link href="{{ url('assets/css/dropzone/dropzone.min.css') }}" rel="stylesheet" type="text/css">
...
</head>
<body>
...
 
<script src="{{ url('assets/js/dropzone/dropzone.min.js') }}"></script>
 
<script type="text/javascript">
      
Dropzone.options.imageUpload = {
    dictDefaultMessage: 'アップロードするファイルをここへドロップしてください',
    acceptedFiles: '.jpg, .jpeg',
    maxFilesize: 5 // 5MBまで
}
</script>
...

上の設定では、ファイルをドロップする場所のメッセージ、アップロードを許すMIMEあるいは拡張子（jpegのみ）、最大のファイルのサイズ（5MBまで）としています。他にもいろいろな設定があります。以下を参照にしてください。

http://www.dropzonejs.com/#configuration

将来は、これらの設定を使用した複雑な例を紹介する予定です。

ファイルのアップロード（２）画像ファイルだけをアップ

Sat, 02 Apr 2016 09:05:53 +0900

ファイルのアップロードと言っても、なんのフォーマットのファイルでもアップをしてよいというわけではありません。たいていは画像ファイルのアップロードになりますが、それでもGIFはアップしてもらいたくない、JPEGだけが欲しいとか。

そのときは、バリデーションを使用してアップしたファイルのMIMEの情報をもとにプログラムで制限します。

まず、jpegだけのファイルをOKとしましょう。

UserController

...
class UserController extends Controller
{
 ...
    public function postUpload(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'file' => 'required|max:10240|mimes:jpeg'
        ]);

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

        return redirect('user/upload');
    }
}

ここ、jpgでなくjpegであることに注意してください。ファイルの拡張子はたいてい、.jpgですが、ユーザーのマシンのOSが送信するMIMIEは、image/jpegです。

複数の画像フォーマットを許すなら、

UserController

...
class UserController extends Controller
{
 ...
    public function postUpload(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'file' => 'required|max:10240|mimes:jpeg,gif,png'
        ]);

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

        return redirect('user/upload');
    }
}

と指定します。

ファイルのアップロード（１）ファイルのサイズの制限：制限なしでも制限ある

Sat, 26 Mar 2016 05:29:40 +0900

入力フォーム画面でのファイルのアップロードは、他のテキストの入力と違っていろいろなことを考慮する必要があり、開発はそう簡単ではありません。PHPのマニュアルでも、説明のためだけに一章を費やしています。

もちろん、Laravelを使うことで開発はかなり簡単になるのだけれど、注意する点やアップしたファイルをどう使用するか．．．などたくさんのトピックあります。以下、いくつか興味あるトピックをリストしました。

ファイルのサイズの制限：制限なしでも制限ある
ファイルのMIMEタイプの制限：画像ファイルだけをアップ
ファイルのアップの進行状況表示：いつファイルのアップが終わるのかな
ファイルのウィルスの検出：そんなこと可能かな
アップしたファイルをメールで送信：届かないのはどうして
アップしたファイルをダウンロード：MIMEからファイルの拡張子を作成
アップしたファイルを配信：Amazonのウェブサービスを使用する

ファイルのサイズの制限：制限なしでも制限ある

まず、ファイルアップロードのフォームをプログラムしましょう。

フォーム

<form
    method="POST"
    action="/demo/public/user/upload"
    class="form-horizontal"
    role="form"
    enctype="multipart/form-data">
    {{ csrf_field() }}

		<div class="form-group{{ $errors->has('file') ? ' has-error' : '' }}">
			<label class="col-md-4 control-label">File</label>

			<div class="col-md-6">
				<input type="file" name="file">
				@if ($errors->has('file'))
					<span class="help-block">
						<strong>{{ $errors->first('file') }}</strong>
					</span>
				@endif
			</div>
		</div>
		<div class="form-group">
			<div class="col-md-6 col-md-offset-4">
                    <input class="btn btn-primary" type="submit" value="Upload">
			</div>
		</div>
</form>

このフォームのコントローラで、アップするファイルの制限を課します。

UserController

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

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

use Auth;
use Validator;

class UserController extends Controller
{
 ...
 
    public function getUpload()
    {
        return view('user/upload');
    }

    public function postUpload(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'file' => 'required|max:10240'
        ]);

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

        return redirect('user/upload');

    }
}

‘file’ => ‘required|max:10240’ここ大事です。maxで指定する最大のファイルのサイズの単位は、バイトではなくキロバイト(KByte)です。つまり、10240は。10メガバイト(10M)となります。

さて、これでファイルをアップロードしてみましょう。８MBのファイルをアップしてみます。しかし、送信ボタンを押した後、TokenMismatchExceptionのエラーとなってしまいます。

どうしてアップできないのでしょう？

制限しているのはプログラムだけではなく、サーバーのPHPの設定でも制限があるからなのです。Unix系のサーバーなら、/etc/php.iniにおいて以下の２か所を編集する必要あります。8Mを20Mとでも設定しましょう。

php.ini

...
post_max_size = 8M
upload_max_filesize = 8M
...

これで、ウェブサーバーを再スタートしてみてください。

１つ残る疑問は、どうしてエラーがPHPの制限のエラーでなくTokenMismatchExceptionのエラーなのでしょう。これは、制限を超えることにより、送信した入力の値が空となり、Laravelが期待するCSRF（クロスサイトリクエストフォージェリ）のトークンの値が入って来なかったからです。

会員編集フォーム - Laravel Collective

Sat, 12 Mar 2016 06:47:48 +0900

今回は、前回作成した会員編集フォームを、Laravel CollectiveのForm & HTMLを使用して書き換えてみます。

このForm & HTMLは、Laravelのバージョン4.2には含まれていました。その後、Lumenの登場によりLaravelから分けて、Laravel Collectiveからの配布となりました。Laravel Collectiveではその他にも、Annotation, Remote(SSH)など有用なパッケージが含まれています。

まず、Form & HTMLのインストールから。

composer.jsonを編集します。

composer.json

...
   "require": {
        "php": ">=5.5.9",
        "laravel/framework": "5.2.*",
        "barryvdh/laravel-debugbar": "^2.1",
        "laravelcollective/html": "5.2.*"
    },
...

その後以下をコマンドで実行。

$ composer update

次は、config/app.phpを編集します。

 'providers' => [
 ...
    Collective\Html\HtmlServiceProvider::class,
 ...
  ],
 
 'aliases' => [
...
      'Form' => Collective\Html\FormFacade::class,
      'Html' => Collective\Html\HtmlFacade::class,
...
  ],

これでインストール完了です。

前回のテンプレートは、以下のように変わります。ハイライトの部分が変更した部分です。

profile.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Profile</div>
                <div class="panel-body">
                {!! Form::open(['url' => url('/user/profile'), 'class' => 'form-horizontal', 'role' => 'form']) !!}

                        <div class="form-group{{ $errors->has('name') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">名前</label>

                            <div class="col-md-6">
                            {!! Form::text('name', $user->name, ['class' => 'form-control']) !!}
                                @if ($errors->has('name'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('name') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group{{ $errors->has('email') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">Eメール</label>

                            <div class="col-md-6">
                                {!! Form::email('email', $user->email, ['class' => 'form-control']) !!}

                                @if ($errors->has('email'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('email') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                {!! Form::submit('保存', ['class' => 'btn btn-primary']) !!}
                            </div>
                        </div>
                {!! Form::close() !!}
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

デザイナーが編集できるテンプレートというより、どちらかというと開発者向け？と思われるかもしれません。しかし、例えば、前回で追加したクロスサイトリクエストフォージェリ対策の{!! csrf_field() !!}は自動的に生成されるし、タイプする量は減りますね。

また、以下のようにドロップダウンのデフォルト選択ではとても便利です。

前回のフォームでは、以下のように選択値のそれぞれでチェックする必要ありますが、

            <select name="category">
                <option value="">選択してください</option>
                <option value="1" {{ (old("category") == '1') ? "selected":"" }}>犬</option>
                <option value="2" {{ (old("category") == '2') ? "selected":"" }}>猫</option>
                <option value="3" {{ (old("category") == '3') ? "selected":"" }}>猿</option>
            </select>

これをFormで書き換えると、一行で終わってしまいます。

{!! Form::select('category', ['1' => '犬', '2' => '猫', '3' => '猿'], old('category'), ['placeholder' => '選択してください']) !!}

会員編集フォーム

Sat, 05 Mar 2016 07:36:54 +0900

ウェブのプログラミングでなんといっても難しいのはフォーム画面のプログラムです。テキスト入力、ドロップダウン、ファイルのアップロード機能、さらにjqueryやangularなどのフロントエンドのjavascriptも入れば、無限の可能性があります。

以前紹介したLaravelの付録の会員認証サンプルの会員登録画面は、php artisan make:authコマンドで自動作成されますが、ログイン後に会員がEメールアドレスや名前を編集する画面は作成されません。

今回はこの編集画面を作成してみます。

まず、新規のコントローラ作成します。

php artisan make:controller User/UserController

を実行して、それを以下のように編集し、

UserController.php

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

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

use Auth;
use Validator;

class UserController extends Controller
{
    protected $user;

    public function __construct()
    {
        $this->middleware('auth:user'); // 認証

        $this->user = Auth::guard('user')->user();
    }

    public function getProfile()
    {
        return view('user/profile')->with(['user' => $this->user]);
    }

    public function postProfile(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'name'  => 'required|max:255',
            'email' => 'required|email|max:255|unique:users,email,'.$this->user->id
        ]);

　　　　//　エラーチェック
        if ($validator->fails())
        {
            return back()->withInput()->withErrors($validator);
        }

　　　　// データを更新
        $this->user->update([
            'name'  => $request->input('name'),
            'email' => $request->input('email')
        ]);

        return redirect('user/home');
    }
}

Validationでは、emailのチェックは、$this->user->idを除くusersのレコードを対象に他に同じEメールが使われていないかチェックします。

次に、以下のようなテンプレートを作成します。

profile.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Profile</div>
                <div class="panel-body">
                    <form class="form-horizontal" role="form" method="POST" action="{{ url('/user/profile') }}">
                        {!! csrf_field() !!}

                        <div class="form-group{{ $errors->has('name') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">名前</label>

                            <div class="col-md-6">
                                <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

                                @if ($errors->has('name'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('name') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group{{ $errors->has('email') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">Eメール</label>

                            <div class="col-md-6">
                                <input type="email" class="form-control" name="email" value="{{ old('email', $user->email) }}">

                                @if ($errors->has('email'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('email') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    保存
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

ここ、old()のLaravelの関数が使用されていますが、すでに存在する値を編集するので、デフォルトとしてDBからの値が入っていることに注意してください。

 <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

コントローラでは、validationエラーが発生して、現在の画面に戻る必要があります。そのときは、withInput()がセッションに入力の値を保存して、back()で現在の画面にリダイレクトします。リダイレクト後には、old()は、デフォルトでなくセッションに保存された入力された値を表示します。

最後に、routes.phpを以下のように編集します。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
    Route::get('profile', 'User\UserController@getProfile');
    Route::post('profile', 'User\UserController@postProfile');
});

以下のように、認証のミドルウェアをコントローラから移してもOKです。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
   Route::group(['middleware' => 'auth:user' ], function () {
        Route::get('home', 'User\HomeController@index');
        Route::get('profile', 'User\UserController@getProfile');
        Route::post('profile', 'User\UserController@postProfile');
    });
});

publicのディレクトリを移動する

Sat, 27 Feb 2016 07:53:43 +0900

新規のLaravelのプロジェクトは、以下の実行で作成できます。

$ laravel new blog

/blogのディレクトリが作成され、そこには以下のようなディレクトリやファイルが作成されます。

app/
bootstrap/
config/
database/
public/
resources/
storage/
tests/
vendor/
artisan
composer.json
composer.lock
gulpfile.js
package.json
phpunit.xml
readme.md
server.php

/publicのディレクトリがウェブサイトのルートとなる仮定で、その他のディレクトリはユーザーからはアクセスできないという仮定なのですが、

しかし、現実は使用するサーバーの都合により、このpublicのディレクトリを違う場所に移動する必要があります。

例えば、

public

を

/usr/www/demo/webdocs

に、

その他のディレクトリやファイルは、ウェブがアクセスできない以下に

/usr/www/demo/blog

この変更に必要な設定は、Laravelではとても簡単です。

public/index.php、移動後では、/usr/www/demo/webdocs/index.phpを編集するだけです。

index.php

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

を

index.php

...
require '/usr/www/demo/blog/bootstrap/autoload.php';
...
$app = '/usr/www/demo/blog/bootstrap/app.php';
..

と書き換えるだけです。

しかし、ここで１つ問題は、Laravel定義のpublic_path関数が返す値が、

/usr/www/demo/blog/public

となります。

これを修正するには、

index.php

...
require '/usr/www/demo/blog/bootstrap/autoload.php';
...
$app = '/usr/www/demo/blog/bootstrap/app.php';

$app->bind('path.public', function() {
    return __DIR__;
});
..

と、path.publicを設定する必要あります。それにより、public_path関数が返す値は、

/usr/www/demo/blog/webdocs

となります。

Eloquentのアクセッサーの説明例

Sat, 20 Feb 2016 08:22:11 +0900

Laravelのマニュアルは、ほどよい説明で気に入っています。長い説明でポイントがつかめなく困ることはそうありません。理解には何回か読むことも必要ですが。

しかし、ときには掲載されるサンプルコードがよく使用されるような例ではなく、逆に混乱してしまうことあります。

例えば、Eloquent Mutatorsの以下のサンプルコード。

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }
}

getFirstNameAttributeを上のように定義すると、

$user = App\User::find(1);

$firstName = $user->first_name;

のように使えると。

ucfirstの関数は、文字列の最初の文字を大文字にする関数なので、もとのDBテーブルuserのfirst_nameの項目の値、つまり$user->first_nameが変換されるのだな、とは推測できます。

しかし、元の項目名もfirst_nameであるし、変換した値にアクセスするのもfirst_nameで、同じ変数名でややこしく思いませんか？

テンプレートで使用するなら、こちらの方が混乱せずに管理性が高いです。 {{ ucfirst($user->first_name) }}

アクセッサーの便利さの説明には、違うサンプルコードを使用した方が良いと思います。

例えば、

    public function getNameAttribute()
    {
        return $this->first_name.' '.$this->last_name;
    }

この例では、nameという項目はDBテーブルに存在しないという仮定です。

$user = App\User::find(1);

echo $user->name;

$user->first_nameが「Kenji」で、$user->last_nameが「Hino」なら、「Kenji Hino」が表示されます。つまり、モデルに新規の属性を作成するのは簡単ということが、このサンプルからわかります。

注意してもらいたいのは、関数名にパラメータがないことです。最初の例では、$valueがありました。そのパラメータは、関数名で指定される（この場合、FisrtName => first_name）変数の値をとってくるという意味ですね。

さて、この新規の属性name、他のDBから入ってくる属性と違って生成するオブジェクトに自動的にふくまれるというわけではありません。

$ php artisan tinker
Psy Shell v0.6.1 (PHP 5.6.13 — cli) by Justin Hileman
>>> use App\User;
=> false
>>> $user = User::find(1);
=> App\User {#847
     id: 1,
     created_at: "2015-04-21 11:56:46",
     updated_at: "2016-01-29 14:17:54",
     first_name: "Kenji",
     last_name: "Hino",
   }
>>> $user->name;
=> "Kenji Hino"
>>> $user->toArray()
=> [
     "id" => 1,
     "created_at" => "2015-04-21 11:56:46",
     "updated_at" => "2016-01-29 14:17:54",
     "first_name" => "Kenji",
     "last_name" => "Hino",
   ]
>>>

最初のオブジェクトの属性としては、nameは入ってきませんね。しかし、$user->nameでは値が返ってきます。しかし、toArrayやtoJsonでは入ってきません。

これは、パフォーマンスのためにLaravelの意図的な仕様です。毎回毎回必要なものでもありませんね。

しかし、必要なときにはどうしたらよいのでしょう？

class User extends Model
{
    protected $appends = ['name'];
...

と$appendsに新規属性を指定すると、

>>> $user->toArray()
=> [
     "id" => 1,
     "created_at" => "2015-04-21 11:56:46",
     "updated_at" => "2016-01-29 14:17:54",
     "first_name" => "Kenji",
     "last_name" => "Hino",
     "name" => "Kenji Hino",
   ]
>>>

name入ってきますね。

ユーザー認証（１４）Debugbar

Fri, 12 Feb 2016 08:26:57 +0900

マルチ認証のトピックが続いていますが、同じブラウザを使用して「会員」と「管理者」の両方にログインしたらどうなるのでしょう？

ログインはブラウザのクッキーを使用して、サーバーのセッションと繋がっています。Laravelはそれぞれに違うセッション、違うクッキーを使用するのでしょうか？それとも同じセッションで違う情報を保持するのでしょうか？興味ありませんか？

ということで、便利なツールの紹介とともに、認証のセッションがどうなっているかチェックしてみましょう。

ここで紹介するツールはDebugarというLaravelのためのツールです。

これをインストールすると、画面下にDebugarの情報パネルが表示され、実行したLaravelの様々な情報を見ることができます。

例えば、以下は会員のログイン成功直後の画面ですが、実行したDBのクエリーを見ることができます。DBテーブルusersに対するクエリーがあります。

このツールのインストールはとても簡単です（GitHubにリポあります）。

まず、以下を実行します。

composer require barryvdh/laravel-debugbar

composer.jsonが更新されライブラリがダウンロードされインストールされます。

次に、config/app.phpに以下を追加します。

...
   'providers' => [
...
       Barryvdh\Debugbar\ServiceProvider::class,
   ],

   'aliases' => [
...
      'Debugbar' => Barryvdh\Debugbar\Facade::class,
   ],
];

これで完了です。

先の会員ログインを実行では、DBのクエリーの情報を見ることができましたが、セッションはどうなのでしょう？

赤丸の部分がセッションの情報を見るボタンです。そして赤の四角の部分が、会員が認証されていることを示す情報です。login-user..の部分です。

さて、同じブラウザでもう１つタブを作成して今度は、管理画面にログインしてみましょう。以下が、ログイン成功後のセッション値です。

値が増えていますね。しかし、今度は、login-admin..と違う名前となっていますね。

つまり、セッションの中でguardの値をセッションの変数名として使い分けているわけです。

ユーザー認証（１３）Laravel 5.2 Hashを複数使用する

Sat, 06 Feb 2016 11:46:16 +0900

ユーザー認証（１０）Laravel 5.2 マルチ認証では、会員と管理者に対して異なるＤＢテーブルをもとに認証を設定しました。

また、

前回では、違うHasherの使用を試みました。

今回は、マルチ認証のときに異なるHasherを用いるケースについて考えてみましょう。そうたくさん起こるケースでないかもしれませんが、私のクライアントのシステムでは実際に起こるケースです。１つのシステムにおいて、「会員」と「管理者」と「店舗管理者」が存在し、それぞれの認証は異なるHasherを使用しています。特に「管理者」は複数のシステムで共有するもので、その認証のためのサーバーが違うマシンに存在します。

まず直面する問題は、Laravelの5.2のマルチ認証では、このような状況にはシンプルに対応できないことです。

config/auth.phpのprovidersでは、それぞれのproviderにおいてhasherの設定がないのです。

config/auth.php

..
   'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\User::class,
        ],

        'admin_users' => [
            'driver' => 'eloquent',
            'model' => App\AdminUser::class,
        ],
    ],
..

また、前回のように、グローバルでHasherを変えることもできません。

「会員」の認証のときには、デフォルトのHasherを使用し、「管理者」の認証のときには、違うHasherを使用できるのが理想です。

まず、Authのサービスがどう初期化されているか追跡してみましょう。

AuthServiceProviderで、ユーザー認証のサービスauthが登録されます。そこでは、AuthManagerのクラスが使用されます。

AuthServiceProvider.php

  protected function registerAuthenticator()
    {
        $this->app->singleton('auth', function ($app) {
            $app['auth.loaded'] = true;
            return new AuthManager($app);
        });
        $this->app->singleton('auth.driver', function ($app) {
            return $app['auth']->guard();
        });
    }

AuthManagerでは、config/auth.phpの設定を読み込み、providerを作成します。その作成は、CreatesUserProvidersで行われます。

AuthManger.php

..
    public function createSessionDriver($name, $config)
    {
        $provider = $this->createUserProvider($config['provider']);
..

providerのdriverは、先のconfig/auth.phpではeloquentと設定されているので、以下のメソッドでオブジェクトが作成されます。

CreatesUserProviders.php

..
   protected function createEloquentProvider($config)
    {
        return new EloquentUserProvider($this->app['hash'], $config['model']);
    }
..

やっとたどり着きましたね。そうproviderの作成時に、グローバルのHasher app[‘hash’]がパラメとして渡されているのです。

ここを変えることができれば、認証のHasherを変えることできるのです。変更するには、新規の認証のためのdriverを使用することも可能です。しかし、以下のEloquentUserProviderを見ると、オブジェクトが作成された後でもHasherを変えることが可能のようです。

EloquesntUserProvider.php

...
    /**
     * Sets the hasher implementation.
     *
     * @param  \Illuminate\Contracts\Hashing\Hasher  $hasher
     * @return $this
     */
    public function setHasher(HasherContract $hasher)
    {
        $this->hasher = $hasher;
        return $this;
    }
...

ここまで理解すると、あとはそう難しくはありません。

まずは、config/auth.phpにおいて、どのHasherのサービスを使用するか指定しましょう。

...
   'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\User::class,
　　　　　　 'hasher' => Illuminate\Hashing\BcryptHasher::class
        ],

        'admin_users' => [
            'driver' => 'eloquent',
            'model' => App\AdminUser::class,
            'hasher' => App\Services\MD5Hasher::class
        ],
    ],
...

上のhasherはまったくLaravelのコードでは使用されませんが、今回の目的でHasherを指定するにはベストの場所と思いませんか！

次に、管理者のAuthControllerにおいて、

AuthController.php

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

    protected $redirectTo = '/admin/home';

    protected $guard = 'admin';
    protected $redirectAfterLogout = 'admin/login';　//ログイン後のリダイレクト先
    protected $username = 'email'; //　DBテーブルのログインに使用される項目

    protected $registerView = 'admin.auth.register';　// 登録に使用されるテンプレート
    protected $loginView = 'admin.auth.login';　//　ログインに使用されるテンプレート

    protected $hasher;

    public function __construct()
    {
        $hasher_class = config('auth.providers.admin_users.hasher');

        $this->hasher = new $hasher_class;

        \Auth::guard($this->guard)->getProvider()->setHasher($this->hasher);

        $this->middleware('guest:admin', ['except' => 'logout']);
    }
...

会員と違うテンプレートを用意するために、テンプレートの場所を指定していることにも注意してください。すべて変数の指定で可能です。

PasswordControllerにおいても同様な設定をします。

PasswordsController

class PasswordController extends Controller
{
    use ResetsPasswords;

    protected $redirectTo = '/admin/home';　// ログイン後のリダイレクト先
    protected $guard = 'admin';

    protected $linkRequestView = 'admin.auth.passwords.email';　// パスワードのリセットリンクを送信してもらう画面のテンプレート
    protected $resetView = 'admin.auth.passwords.reset';　// パスワードリセット画面のテンプレート
    protected $subject = '管理者のパスワードリセット'; //　送信メールの件名

    public function __construct()
    {
        $hasher_class = config('auth.providers.admin_users.hasher');

        \Auth::guard($this->guard)->getProvider()->setHasher(new $hasher_class);

        $this->middleware('guest:admin');
    }
}

最後に、管理者へのパスワードリセットのメールのテンプレートは、以下のように、config/auth.phpで可能です。

config/auth.php

...
  'passwords' => [
        'users' => [
            'provider' => 'users',
            'email' => 'user.auth.emails.password',
            'table' => 'password_resets',
            'expire' => 60,
        ],

        'admin_users' => [
            'provider' => 'admin_users',
            'email' => 'admin.auth.emails.password',
            'table' => 'admin_password_resets',
            'expire' => 60,
        ],
    ],
];

ユーザー認証（１２）Laravel 5.2 Hasherを変える

Sun, 31 Jan 2016 06:26:48 +0900

Hasherとは、パスワードからHashの作成に使用される関数です。さて、Hashとはなんぞや？

例えば、パスワードをtesttestとします。これをHasherに与えると、 $2y$10$CE4R5SS6f5g4Rd0fgYRbneoeCOYbE0S2xfaYNC7i41CLysQ8TRUPO のような文字列を生成します。これがHashです。

Hashは暗号化と異なり、非暗号化はできる機能はありません。つまり、 $2y$10$CE4R5SS6f5g4Rd0fgYRbneoeCOYbE0S2xfaYNC7i41CLysQ8TRUPO から、もとのパスワードtesttestを解読できる機能はありません。

この特性を活かしてユーザー認証の機能のセキュリティを高めます。

まず会員登録時に入力したパスワードをHashした値をDBに保存します。そのままのテキストでは保存しません。そして、ログイン時に入力されたパスワードをHashして、DBに保存されたHashされたパスワードとマッチするかチェックします。マッチするなら認証OKです。

このHashする関数(Hasher)にはいろいろな種類があります。PHPでは、一昔前までは、

md5

を使用していました。md5は、必ず同じ値を返すので、Hashされたパスワードのマッチは、お互いの文字列を比較するだけです。

しかし、php5.5からは、よりセキュアな以下の関数の使用が薦められています。

password_hash

この関数が返すHashの値は、与えられる値が同じでも返す値が変わります。それゆえに、Hashされたパスワードのマッチにはもう１つの関数、

password_verify

を使用します。以下のように。

$password = 'testtest';

$hashed = password_hash($password, PASSWORD_DEFAULT);

$result = password_verify($password, $hashed);

echo $result ? '認証成功' : '認証失敗';

Laravelも基本的に同様な関数を使用しています。

BcryptHasher

さて、新規にLaravelを使用してプログラムを書くならまったくこれで問題ありません。しかし、既存のプログラムをLaravelに書き換えるとき、例えば、既存のプログラムがパスワードのHashにmd5を使用しているなら、DBに保存されているパスワードでは、LaravelのHasherでは誰もログインが不可能となってしまいます。

これに対応するには、LaravelのHasherを取り換える必要があります。HasherはLaravelではプログラムを通して１種類しか使用できない仕組みなので、HasherのProviderを作成して取り換えることになります。

まず、新規のHasherを作成します。

app/Services/MD5Hahser.php

namespace App\Services;

class MD5Hasher implements \Illuminate\Contracts\Hashing\Hasher {

    public function make($value, array $options = [])
    {
        return md5($value);
    }

    public function check($value, $hashedValue, array $options = [])
    {
        return (md5($value) == $hashedValue);
    }

    public function needsRehash($hashedValue, array $options = [])
    {
        return false;
    }
}

\Illuminate\Contracts\Hashing\Hasherで定められている型をもとに、必要な関数を定義します。

次にこのHasherを登録するサービスプロバイダーを作成します。

app/Providers/MD5HasherServiceProvider.php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

use App\Services\MD5Hasher;

class MD5HasherServiceProvider extends ServiceProvider {

    protected $defer = true;

    public function register()
    {
        $this->app->singleton('hash', function() {
            return new MD5Hasher;
        });
    }

    public function provides()
    {
        return ['hash'];
    }
}

そして、config/app.phpを編集して、Hasherをサービスプロバイダーを入れ替えます。

config/app.php

...
   'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        ...
        // Illuminate\Hashing\HashServiceProvider::class, //コメントして
        App\Providers\MD5HasherServiceProvider::class,　　　//登録する
...

最後に、以下をコマンドラインで実行します。

composer dump-autoload

ユーザー認証（１１）Laravel 5.2 ログインの記録

Sun, 24 Jan 2016 03:17:25 +0900

「ユーザー認証」のポストは、もうすでに１１回目になりました。Taylorくんのプログラムは、宝石がいっぱい詰まっているから、ソースコードを見ているといろいろ発見あります。

例えば、私はユーザー認証成功後にログインの記録が欲しいです。つまり、ユーザーがどのIPからどのブラウザあるいはどのOSでアクセスしたかをDBに記録したいのです。ソースコードを見ているとそのことをあたかも考慮しているメカニズムが存在することに気づきます。今回はそれをどう利用するかを紹介します。

まず、ユーザー認証（９）Laravel 5.2 コンポーネント自動作成で紹介したコマンドで作成されるファイルの１つ、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;

    protected $redirectTo = '/';

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

    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',
        ]);
    }

    protected function create(array $data)
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
        ]);
    }
}

さて、どうすればよいでしょう？

上の１１行目のトレイトのファイルを遡って辿ります。

AuthenticatesAndRegistersUsers ↓ AuthenticatesUsers

このファイルで、postLoginは、ログイン情報を送信したときに呼ばれる関数、その定義の中では、loginをコールしています。

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

...
    public function postLogin(Request $request)
    {
        return $this->login($request);
    }
...
    public function login(Request $request)
    {
        $this->validate($request, [
            $this->loginUsername() => 'required', 'password' => 'required',
        ]);
 
        $throttles = $this->isUsingThrottlesLoginsTrait();

        if ($throttles && $this->hasTooManyLoginAttempts($request)) {
            return $this->sendLockoutResponse($request);
        }

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

        if (Auth::guard($this->getGuard())->attempt($credentials, $request->has('remember'))) {
            return $this->handleUserWasAuthenticated($request, $throttles);
        }

       if ($throttles) {
            $this->incrementLoginAttempts($request);
        }
        return $this->sendFailedLoginResponse($request);
    }
...
    protected function handleUserWasAuthenticated(Request $request, $throttles)
    {
        if ($throttles) {
            $this->clearLoginAttempts($request);
        }
        if (method_exists($this, 'authenticated')) {
            return $this->authenticated($request, Auth::guard($this->getGuard())->user());
        }
        return redirect()->intended($this->redirectPath());
    }
...

loginの定義ではattempt()（２１行目）で認証を実行しています。そしてそれが成功なら、handleUserWasAuthenticatedをコールします。

今度は、36行目見てください。ここのifは、このクラスにauthenticatedというメソッドが定義されているなら、それを実行しますよ！という意味です。

先の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;

use App\UserLog;
use Illuminate\Http\Request;

class AuthController extends Controller
{
    use AuthenticatesAndRegistersUsers, ThrottlesLogins;

    protected $redirectTo = '/';

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

    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',
        ]);
    }

    protected function create(array $data)
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
        ]);
    }

    public function authenticated(Request $request, User $user)
    {
        UserLog::add($request, $user);//ここでログを作成

        return redirect()->intended($this->redirectPath());
    }
}

これで、ログインが成功するたびに、このauthenticatedがコールされログインの履歴をDBに作成します。

以下はそこで使用されるモデルUserLogです。ホスト名を得るために、ミューテーターを使用します。

app/UserLog.php

namespace App;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Http\Request;

class UserLog extends Model {

    protected $table = 'user_log';
    protected $primaryKey = null;
    public $incrementing = false;
    public $timestamps = true;

    public function setHostnameAttribute($ip)
    {
        $this->attributes['hostname'] = gethostbyaddr($ip);
    }

    public static function add(Request $request, User $user)
    {
        $userLog = new static;

        $userLog->user_id = $user->id;
        $userLog->ip = $request->getClientIp();
        $userLog->hostname = $userLog->ip; // ミューテーターを使用

        $userLog->save();
    }
}

user_logのDBテーブルを作成することをお忘れずに。

authenticatedには、ログインの履歴を作成するだけでなく、会員の１周年記念のためのお祝いのメッセージや、それにまつわる特典の提供とか、いろいろなコードを含むことが考えられます。

ユーザー認証（１０）Laravel 5.2 マルチ認証

Mon, 18 Jan 2016 04:00:49 +0900

マルチ認証と言っても、複数のステップでユーザーを認証するわけでもなく、ちょっとピンと来ないですね。

例えばECシステムにおいて、ユーザー画面での会員ログインと、管理画面での管理者のログインがそれぞれ別に必要とします。どちらもログインはEメールとは限らないし、片方でログインしたらもう片方でも認証となるとも限りません。つまり、ログインするユーザーの種類や場所が複数必要となる状況が多々あります。それに対応する機能が、マルチ認証です。

Laravelの5.1までは、マルチ認証は対応していなく、以下のようなパッケージをインストールして使用していました。

Laravel4.2対応のLaravel Multi Auth

Laravel5.1対応のMultiAuth for Laravel 5.1

しかし、5.2からはLaravelの基本仕様となっています。さすが、Taylorくん！

今回はこの機能を見てみましょう。

まず、デフォルトでインストールされるconfig/auth.phpの中身の解析。

Laravel 5.1では、

return [

    /* デフォルトの認証ドライバー */

    'driver' => 'eloquent',

    /* 認証に使用されるモデル */

    'model' => App\User::class,

    /* 認証に使用されるDBテーブル。ここでは、dirverがdatabaseでないので関係ない */

    'table' => 'users',

    /* パスワードリセットの設定 */
    'password' => [
        'email'  => 'emails.password',　// resources/views/emails/passwordをリンク送信メールのテンプレートとする
        'table'  => 'password_resets',  // パスワードリセットのトークンの情報を保存するDBテーブル
        'expire' => 60,                 // トークンは60分で期限切れ
    ],
];

これがLaravel5.2では、

return [
    /* 認証のデフォルト設定 */

    'defaults' => [
        'guard' => 'web',
        'passwords' => 'users',
    ],                         

    /* 認証のガードを定義 */                                                   

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'token',
            'provider' => 'users',
        ],
    ],

    /* 認証のプロバイダー */

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\User::class,
        ],

        // 'users' => [
        //     'driver' => 'database',
        //     'table' => 'users',
        // ],
    ],

   /* パスワードリセットの設定 */

    'passwords' => [
        'users' => [
            'provider' => 'users',
            'email' => 'auth.emails.password',
            'table' => 'password_resets',
            'expire' => 60,
        ],
    ],

];

となりました。違いは、guardsとprovidersの導入です。

ちょっとこれではわかりにくいので、先の例を使って、ECサイトを想像してもらって、ショッピングをするユーザ画面と、サイトを管理する管理者画面があり、どちらもログインで認証が必要と仮定しましょう。ユーザー画面では買い物かごをチェックアウトするには、会員のログインが必要とします。

となると必要な設定は以下にようになります。

return [
    /* 認証のデフォルト設定 */

    'defaults' => [
        'guard' => 'users',
        'passwords' => 'users',
    ],                         

    /* 認証のガードを定義 */                                                   

    'guards' => [
        'users' => [
            'driver' => 'session',
            'provider' => 'users_provider',
        ],

        'admin_users' => [
            'driver' => 'session',
            'provider' => 'admin_users_provider',
        ],
    ],

    /* 認証のプロバイダー */

    'providers' => [
        'users_provider' => [
            'driver' => 'eloquent',
            'model' => App\User::class,
        ],

        'admin_users_provider' => [
            'driver' => 'eloquent',
            'model' => App\AdminUser::class,
        ],
    ],

   /* パスワードリセットの設定 */

    'passwords' => [
        'users' => [
            'provider' => 'users_provider',
            'email' => 'auth.emails.password',
            'table' => 'password_resets',
            'expire' => 60,
        ],
    ],

];

ガードには、会員ログインのためのusersと、管理者ログインのためのadmin_usersの２つを定義します。どちらもセッションを使って、ログイン後の画面をプロテクトします。また、それらのプロバイダーで定義されているように、会員のUsersと管理者のAdminUsersのエロクエントモデルが認証のための情報提供元となります。

guardsとprovidersの概念を導入することにより、今までの１つだけの認証のメカニズムを複数としたわけです。

さて、次はこの設定の使用です。このファイル以外で使用するのは、ガード名だけですから簡単です。

ガードを指定する場所はプログラムの中でいくつかありますが、以下のようにapp/Http/routes.phpで使用されるのが一番明確と思います。

例えば、ユーザー画面では、

    Route::group(['middleware' => 'guest:users'], function() {
        Route::get('login', 'user\AuthController@getLogin');
        Route::post('login', 'user\AuthController@postLogin');
        Route::get('signup', 'user\SignupController@getSignup');
        Route::post('signup', 'user\SignupController@postSignup');
        Route::get('password/email', 'user\PasswordController@getEmail');
        Route::post('password/email', 'user\PasswordController@postEmail');
        Route::get('password/reset/{token}', 'user\PasswordController@getReset');
        Route::post('password/reset', 'user\PasswordController@postReset');
    });

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

以前、ユーザー認証（４）認証でページを保護で説明したように、

ミドルウェアとして、guestとauthが使われます。しかし、前回と違って、guest:usersのようにガード名を指定することが必要です。指定がないなら、auth.phpのデフォルトのセクションで指定したガードが自動的に使われます。

ちなみに、管理者側では、

Route::group(['prefix' => 'admin', 'middleware' => 'guest:admin_users'], function()
{
    Route::get('login', 'admin\AuthController@getLogin');
    Route::post('login', 'admin\AuthController@postLogin');
});

Route:: group(['prefix' => 'admin', 'middleware' => 'auth:admin_users'], function() {

    Route::get('logout', 'admin\AuthController@getLogout');
    Route::get('index', 'admin\HomeController@getIndex')->name('admin.home');
..

こんな感じです。

AuthControllerは、ユーザ画面と管理画面では、前回紹介した自動作成使われるもののコピーを編集する必用あります。

ユーザ画面では、

...

class AuthController extends BaseController
{
    protected $guard = 'users';

    protected $redirectTo = 'user/member/index'; 　　// ログイン後のリダイレクト先
    protected $redirectAfterLogout = 'user/login';   // ログアウト後のリダイレクト先

    protected $username = 'email';               // ログインとなるDBの項目名

    protected $maxLoginAttempts = 5;             // ログインスロットルとなるまで最高のログイン失敗回数
    protected $lockoutTime = 60;                 // ログインスロットルとなってからの待ち秒数

    use AuthenticatesAndRegistersUsers, ThrottlesLogins;

    public function showLoginForm()
    {
        return view('user.login');　　//テンプレートの場所を変える
    }
..

管理画面では、

...

class AuthController extends BaseController
{
    protected $guard = 'admin_users';

    protected $redirectTo = 'admin/index'; 　　// ログイン後のリダイレクト先
    protected $redirectAfterLogout = 'admin/login';   // ログアウト後のリダイレクト先

    protected $username = 'login';               // ログインとなるDBの項目名

    protected $maxLoginAttempts = 5;             // ログインスロットルとなるまで最高のログイン失敗回数
    protected $lockoutTime = 60;                 // ログインスロットルとなってからの待ち秒数

    use AuthenticatesUsers, ThrottlesLogins;

    public function showLoginForm()
    {
        $form = new \stdClass();

        $form->login = Form::text('login', '',
            ['size' => 20, 'maxlength' => 20, 'class' => 'en', 'autofocus' => 'autofocus']);

        $form->password = Form::password('password',
            ['size' => 40, 'maxlength' => 20, 'class' => 'en']);

        return view('admin.login')->with(compact('form')); //テンプレートの場所を変える
    }
..

となります。認証が２つとなると、テンプレートなどいろいろな指定が必要となることに注意してください。上の例では、会員のログインは、emailですが、管理者のログインは、emailでなくてもよい文字列という仮定です。

最後に、ログイン後にログインしたユーザーの情報がほしいときは、今まで、

Auth::user()

でしたが、マルチ認証となると、

Auth::guard(‘users’)->user() Auth::guard(‘admin_users’)->user()

と明確にガード名を指定する必用があります。

ユーザー認証（９）Laravel 5.2 コンポーネント自動作成

Mon, 28 Dec 2015 07:09:22 +0900

Laravelの5.2が登場してきました。いくつか興味ある変更がありますが、ユーザ認証に関してはスタート地点が身近になりました。

以下のコマンドを実行するだけで、

php artisan make:auth

以下を自動的に作成してくれます。

　画面とEメールのテンプレート
- ログイン画面
- ユーザー登録画面
- パスワードリセット情報送信画面
- パスワードリセットのEメール
- パスワードリセット画面
- ホーム画面（ログイン後）
　ホームコントローラ（HomeController.php)
　ルータの設定の変更 (routes.php)

データベースを用意して、.envの設定ファイルを編集すれば、以下のように。

画面は、Bootstrapを使用していて、ちょっと編集すればすぐに実践で使えそうです。

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

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()の残りのコードを処理します。

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

重複回避 - 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.2 on ララジャパン

グローバル変数をダイナミックに管理

バリデーション (9) 配列のDistinctと暗黙の拡張

配列のDistinctバリデーション

空の入力に対するdistinct？

暗黙の拡張 implicitRules

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

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

バリデーション (7) エラーメッセージのリプレーサー

等号を含む日付の最大最小

メッセージへの引数の展開

カスタムプレースホルダー

バリデーション (6) 他の属性の値を参照

getValue()

min と max の拡張

バリデーション (5) 最大値と最小値

日付の最大値と最小値

数値型のカスタムバリデーション

numericRules

バリデーション (4) DateとDatetime

date_format による ISO-8601限定

Date と Datetime の拡張

日付入力のフォームインターフェイス

ちょっとしたパフォーマンスの改善

１．設定ファイルのキャッシュ作成

２．routeのキャッシュ作成

３．共有クラスファイルの最適化

改善した？

入力のブラックリストとホワイトリスト

routesを使いこなす（５）モデルとのバインディング

バリデーション (3) 既存バリデーションの置き換え

email

alpha, alpha_dash, alpha_num

バリデーション (2) CustomValidatorを追加

routesを使いこなす（４）routeを名付ける

routesを使いこなす（３）prefixでgroupを分割

routesを使いこなす（２）resourceを使いこなす

バリデーション（１）Validatorファサードのextend

routesを使いこなす（１）resourceを使う

ファイルのアップロード（8）プライベートに画像を表示

ファイルのアップロード（７）パブリックに画像を表示

ファイルのアップロード（６）異なる画像フォーマットの対応

ファイルのアップロード（５）複数の画像ファイルをアップロード

ファイルのアップロード（４）バックエンド

ファイルのアップロード（３）Dropzone.jsでアップロード途中経過を表示

ファイルのアップロード（２）画像ファイルだけをアップ

ファイルのアップロード（１）ファイルのサイズの制限：制限なしでも制限ある

会員編集フォーム - Laravel Collective

会員編集フォーム

publicのディレクトリを移動する

Eloquentのアクセッサーの説明例

ユーザー認証（１４）Debugbar

ユーザー認証（１３）Laravel 5.2 Hashを複数使用する

ユーザー認証（１２）Laravel 5.2 Hasherを変える

ユーザー認証（１１）Laravel 5.2 ログインの記録

ユーザー認証（１０）Laravel 5.2 マルチ認証

ユーザー認証（９）Laravel 5.2 コンポーネント自動作成

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

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

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

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

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

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

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

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

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

ダーティなレコード

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