SHIRANGANA

移転のお知らせ

当ブログは下記に移転します。

MUGIJIRU.JP

laravel 5.2 CSRF TOKENの仕組み

図にまとめたので上げておきます。
要点は

・laravelのセッションはネイティブPHPのセッションを使っていない。
・cookieに設定される値は暗号化される。
・cookieに保存されるセッションid(laravel_session)とトークン(XSRF-TOKEN)はcookie名が違う。
・tokenはセッション作成時に発行され、regenerateしない限り不動。
・tokenをリクエストする方法は3通り(ヘッダ2パターン、パラメータ1パターン)ある。

というところあたりだと思います。

意外な落とし穴では

・cookieの暗号化はenvのAPP_KEYがsaltに使われているので変更すると複合できなくなる
・URL毎にlaravel_sessionにあたるcookie名を分けている場合、XSRF-TOKENも揃えないと意味がない
　(x-csrf-token, _tokenだけで制御されているなら不要ですが)
・XSRF-TOKENのcookieの有効期限がなぜかソースに直書きになっているので
　期限を伸ばすならばオーバーライドが必要
https://teratail.com/questions/27003

という点が挙げられます。

Laravelでexpire_on_closeをtrueにしているのに放置しているとセッションが切れる

CSRF TOKENと関わりの深い話題だと思うので[こちら]もどうぞ。

「せや！セッション持続時間を永続化したろ！」

「expire_on_close = true！これで放置しても大丈夫やで！」

〜約2時間後〜

SE「消えたンゴ」

PG「ワイは消えてない・・・なぜなのか」

という状況の解決策をシェアしたいと思います。

解決策:

lifetimeを長めに取ってみて下さい。

gc(ガベージコレクション)がセッションデータを削除しているかもしれません。

expire_on_closeがtrueならlifetimeは無視されると思いきや・・・

実はガベージコレクションの判定では使用されています。

LaravelもネイティブPHPも、セッションデータを失う条件は

1.cookieが削除された

2.セッション自体の有効期限が切れた

3.gcが発動した

の3通りが主で、Laravelの場合1と2はexpire_on_closeで対応できますが

3はlifetime + lotteryの設定で動作するようになっています。

要するに、expire_on_closeがtrueでセッション自体の有効期限を永続化しても

ガベージコレクションが起こればデータが削除される場合があるということです。

例えば、lifetimeが120、lotteryが[2, 100]であるならば

そのサーバに誰かからアクセスされる度、

2/100(=2%)の確率で2時間以上更新されていないセッションデータを削除するという動きをします。

(消えたり消えなかったりのムラはこの確率判定が原因です)

極端な話、lifetime = 1 / lottery = [100, 100]にすると、
expire_on_close = trueでも

1分以内にアクセスしなければセッションが吹っ飛ぶ様を見ることができます。

放置されがちなアプリなら2時間は短いと思うので、例えば

「1週間触られていないセッションデータはさすがにゴミデータですよね」というポリシーなら

lifetimeは 60分 x 24時間 x 7日 = 10080

等と設定すれば良いと思います。

gcを緩めすぎてデータ量が肥大化しないよう、

アプリの用途と規模を考慮し、用法用量を考えて正しくご設定くださいませ。

Form submission canceled because the form is not connected

最近から、ChromeにおいてjQueryでformをsubmit処理をするとき

「Form submission canceled because the form is not connected」

というメッセージがコンソールに出るようになり、submitができなくなることがあります。

これはChromeのバージョン55系までは出ておらず、56系から出るようになりました。

(発生した私の環境では56.0.2924.87 64-bitでした)

このエラーは、ブラウザが描画しているdocumentに埋め込まれていないformを

submitしようとするときに発生します。

端的に言うと下記のような感じ

$('<form action="hoge"></form>').submit(); // これは上記のメッセージが出る。

暫定の対応としては、

form要素をdocumentに一度埋め込むことによって動作するようになります。

たとえば

var form = $('<form action="hoge"></form>');

var temp_wrapper = $('div#temp');

temp_wrapper.empty().append(form);

form.submit(); // 正常にsubmitされる。

みたいな感じ。

理由は、HTMLの仕様がそうであるからでした。

4.10.21.3 Form submission algorithm

上項の2番に書いてあるとおりで、documentに結合していない要素の処理は無視されます。
chromeはver56系からこれに従ったため、メッセージが出るようになったと思われます。

以前から、このテクニックは裏技っぽい使い方だな、と思っていましたが、

実際にブラウザハックだったということになりますね！

正式な仕様としてはNGということになります。

普段何気なく使っているHTMLですが、

不具合を出してお客さんに迷惑をかけたり、恥ずかしい思いをしないためにも

一度くらいは通しで規約を読んだほうが良さそうですね。

参考URL

Getting Error “Form submission canceled because the form is not connected”

LaravelCollective/Html Ver5.2

いつもお世話になっているHtml, Formの生成ヘルパーである LaravelCollective/Html
Laravelのコアから外れた今でも、その利便性が褪せることはありません。

しかしながら、その機能の中で、今までどうしても不満に思っていた点がありました。
それは、Form Model Bindingをする時に
日付がCarbonである場合、テキスト出力される際にフォーマットが指定できず、
テキスト欄に強制的にY-m-d H:i:sと出てきてしまっていた点です。

なぜここだけこんなにも融通が利かないんだろう。
という印象を受けた人は一人ではないのではないかと思います。

私も、dateと datetimeメソッドをフォーマット指定が可能なように
拡張したクラスを作成しようか何度も迷っていました。

最近もまた、そんなことを考えていたところ！

Ver5.2から新機能が追加されてた。
FormModelBinding専用のアクセサが実装できるようです。

このように書くことができるようになります。(公式より抜粋)
https://laravelcollective.com/docs/5.2/html#form-model-accessors

namespace App;

use Carbon\Carbon;
use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * Get the user's first name.
     *
     * @param  string  $value
     * @return string
     */
    public function getDateOfBirthAttribute($value)
    {
        return Carbon::parse($value)--->format('m/d/Y');
    }

    /**
     * Get the user's first name for forms.
     *
     * @param  string  $value
     * @return string
     */
    public function formDateOfBirthAttribute($value)
    {
        return Carbon::parse($value)->format('Y-m-d');
    }
}

formDateOfBirthAttribute が専用アクセサですね。
(getDateOfBirthAttributeはもともとあるEloquentのアクセサです)

まだ自由自在になりきったというところまではいかないものの、
普段使いで露骨に不足しない程度にはなってきたのではないかと思います。

ありがたいことです。

Laravel5.1 セッション flashの注意点

久しぶりのLaravel話です。

Laravelではエラーメッセージの表示などで馴染み深いflashセッションの機能がありますが
この機能は「次回のリクエストまでセッションを維持する」という言葉の通り動作します。

もし次回のリクエストでflashセッションを引き続き維持したい時は、
遷移やアクセスの可能性を十分に理解・整理したうえで、

Input::flash();

や

$request->session()->reflash();

をうまく使いましょう。

繰り返しますが、この言葉の通りなので使う時はちゃんとわかって使う事が大事だったりします。

はまりがちな罠 - 1

APIなどの非同期通信で消えてしまう。

はまりがちな罠 - 2

public以下に設置したcss, js, imgの404アクセス(laravelのハンドラで処理)で消えてしまう。

そんなことがあるのか的な罠(これが言いたかった)

barryvdh/laravel-debugbar を噛ませている場合、エラーハンドリング時は暗黙にreflashされるので
.envのdebug=falseで本番デプロイするまで上記の罠 - 2が表面化しない！！！

debug=trueの時に導入される便利ツールたちは便利ではありますが
こういう思いがけない事例もあるのだと感心しました。

flash自体は良い仕組みですので使いこなしていきたいところですが、
ちゃんとケースバイケースで用途を考えて実装する必要がありますね。
エラーハンドラ内で404であればreflashするとか、
APIのミドルウェアで特定の条件でのみreflashするとか、
安直に思いつく手はあれど、十分にケースを網羅した上で正解を決めていきたいところです。

この調査のためにまたソースをたくさん読んだので、良い勉強になりました。

Laravel5.1 collectionの注意点

Laravel小ネタ。

Laravelで用意されている便利な配列操作オブジェクト「collection」
これを使用している中で、人によってはハマりそうなケースを発見しました。

こんなことがあったのです

// EloquentのCollectionをゲット。
$persons = App\Person::all();

// あるカラムだけのCollectionにして、重複を排除してみよう。
$nicknames = $persons->pluck('nickname')->unique();

（゜Д゜）あれー

[Symfony\Component\Debug\Exception\FatalThrowableError]
Fatal error: Call to a member function getKey() on integer

普通に重複を排除した値を取ってくれるなら問題ないんですが
エラーで落ちてしまいました。

とりあえず結論から

Eloquentから得たCollectionは
「Illuminate\Database\Eloquent\Collection」
を使っている。

実はこれ、Illuminate\Support\Collection と似ているが、ちょっと違う。
このオブジェクトは所属アイテムがEloquentのModelオブジェクトである事を想定しているようだ！

よって、pluck()等でEloquentオブジェクト以外が所属している状態になった場合は
使うメソッドによっては、エラーになるぞ！

エラーの解決策

Modelのcollectionとして使用しないのなら、混同しないこと。
明示的にIlluminate\Support\Collection オブジェクトにして扱えばよろしい。

    $nicknames = collect($persons->pluck('nickname'))->unique();

ちなみに

エラーが発生した場所のコードはこちら。

/**
 * Return only unique items from the collection.
 *
 * @param  string|callable|null  $key
 * @return static
 */
public function unique($key = null)
{
    if (! is_null($key)) {
        return parent::unique($key);
    }

    return new static(array_values($this->getDictionary()));
}

からの、

/**
 * Get a dictionary keyed by primary keys.
 *
 * @param  \ArrayAccess|array  $items
 * @return array
 */
public function getDictionary($items = null)
{
    $items = is_null($items) ? $this->items : $items;

    $dictionary = [];

    foreach ($items as $value) {
        // ここ！！$itemにgetKey()が実装されている事が前提になっている。
        // getKeyは、Eloquent Modelのプライマリキーのカラム名を返すメソッド。
        $dictionary[$value->getKey()] = $value;
    }

    return $dictionary;
}

Laravelはソースがきれいなのですぐ分かります。
なるほどね、と思ったのでした。

Laravelの便利なValidationルール

LaraveのValidationは大変使いやすいです。
業務システムを作るとき、わりと使いやすいけど調べてもわかりにくいルールを備忘録として書いておきます。

unique
よくある重複チェック。DB内を検索してくれます。
すべての検索条件が=(イコール)でチェックできるならこんな書き方ができます。

<?php
// 必須ですよ|自分のid以外のcompany_idとshop_idが同じ商品の中でユニークじゃないとだめですよ
$rules = [
    'item_code' => 'required|unique:items,item_code,'.$my_id.',id,company_id,'.$my_company_id.',shop_id,',$my_shop_id;
];

実際は下記の構成になっています。
unique:{テーブル名},{対象カラム名},{除外条件の値},{←のカラム名(id等)},{where カラム1},{←の値},{and カラム2},{←の値}, ...

required_if
一緒に渡されたパラメータの値を見て、特定の条件だったら必須とする。

<?php
// 数字ですよ|typeがstudentの時だけ必須ですよ
$rules = [
    'age' => 'numeric|required_if:type,student';
];

before (after)
日付に適用できるフィルタ。以前、以後を表現できる。

<
?php
// 必須ですよ|日付ですよ|今日より前である必要がありますよ
$rules = [
    'birth_date' => 'required|date|before:'.date('Y-m-d');
];
// 一緒に渡されたto_dateより前である必要がありますよ
$rules = [
    'from_date' => 'date|before:to_date';
];

ちなみに、たいていValidationのルール定義はFormRequest内のrules()メソッドで返すのが定石ですが
特殊な入力フローを使っていて、Controller等でValidationを行いたい時もあると思います。
そんな時はこんな感じでもかけます。

<?php
// 手動でValidatorを作るよ
$validator = Validator::make($params,  [
    // rules...
]);
// Validateしてエラーがあったら
if ($validator->fails()) {
    // エラーメッセージと入力された値を持って入力画面に戻るよ
    return redirect()->route('edit_page_route_name')->withErrors($validator)->withInput();
}

Laravelのすごいところは、たいていの事を網羅してくれているところだと思います。
Laravelの実装機能の範囲内で対応できない要件は、完全に特殊な入力をする必要があるか
そもそもの考え方や設計がおかしいかのどちらかなので、
書いていく中で「行き詰まる事」が「状況整理のタイミング」として
考えず書き進めるような事を避ける癖が付いていくのが嬉しいですね。

array_get

phpにおいて所々で自作される「array_get」は大変便利な関数です。
Laravelのhelperにも入っています。

一般的な実装としては、「配列から与えられたキーの値を返す」というシンプルなもので、
たいていは3つの引数をとります。

第1引数 = 配列
第2引数 = キー
第3引数 = 値がなかった場合に返す値

Laravelはドット区切りの設定ファイルを取り扱うので、
'hoge.fuga' なんてキーを渡すと
$array['hoge']['fuga']
を探してくれるようなものを実装したりしていますね。

私も業務アプリを書くことが多かったので
多重の配列を取り扱うことが多く、階層を掘れるarray_getがほしい場面がたまにありました。
掘る階層の位置を動的に変える事に対応するため、引数に配列を許可し、
配列を許可した場合はその順番に階層を掘るという動きをさせるようにしました。自作したソースは下記です。

<?php
/**
 * array_get の再帰版
 *
 * 配列$arrayのキー$key(数値 or 文字 or 配列)の値を取得する。
 * 配列で指定した場合、要素の順番に配列を掘っていく。
 * 例外が発生した場合$defaultを返す。
 *
 * @param array $array   探す配列
 * @param mixed $key     探すキー。階層を掘る場合は配列で指定する
 * @param mixed $default 値がなかった場合に返すデフォルト値
 *
 * $array['key1']['key2']['key3'] の値が欲しければ
 *
 * $key = array('key1', 'key2', 'key3');
 * $value = aget($array, $key); と書ける。
 */
function aget($array, $key, $default = null) {
    if (!is_array($key)) {
        return is_array($array) && array_key_exists($key, $array) ? $array[$key] : $default;
    }

    if (!$key) return $default;

    foreach ($key as $k) {
        if (is_array($array) && array_key_exists($k, $array)) {
            $array = $array[$k];
        } else {
            return $default;
        }
    }

    return $array;
}

同時に、階層を調整して値を設定したい場面もありました。
setter版も作成しました。

<?php
/**
 * aget のsetter版
 *
 * 配列$arrayのキー$key(数値 or 文字 or 配列)に値$valueを代入する。
 * 配列で指定した場合、要素の順番に配列を掘っていく。
 * 値がnullであった場合、[] として扱う。
 *
 * $array['key1']['key2']['key3'] = $value は
 *
 * $pos = array('key1', 'key2', 'key3');
 * aset($array, $pos, $value); と書ける。
 *
 * 値の設定に成功した場合、trueを返す。
 */
function aset(&$array, $key, $value)
{
    if (!is_array($array)) {
        return false;
    }
    if (!is_array($key)) {
        if ($key === null) {
            $array[] = $value;
        } else {
            $array[$key] = $value;
        }
    } else {
        if (!$key) return false;
        $ref = &$array;
        foreach ($key as $k) {
            if ($k === null) {
                $ref = &$ref[];
            } else {
                $ref = &$ref[$k];
            }
        }
        $ref = $value;
        unset($ref, $array);
    }

    return true;
}

昔のソースを引っ張り出してきたので、出来は不明ですが・・・
複雑な配列構造の操作において、可読性にかなり貢献してくれた関数たちです。

DIって何だろう？

<?php
/*
 
DIってなんだろう？

「依存性の注入」だそうで。
ソースコードの保全性向上とか、メンテナンスやらテストが綺麗にできるようになる
という事は聞いている。

単純な計算プログラムでも作って実感してみよう！

まずは、レガシーな書き方をしてみる。

Calcっていうクラスがあって、その中に各計算用のメソッドを用意して、
制御側でメソッドを呼び分けるという愚直なスタイル。

 */

// 計算するクラスだよ
class Calc
{
	// 足し算するとき呼んでね
	public function execAdd($left, $right)
	{
		return $left + $right;
	}
	// 引き算するとき呼んでね
	public function execDiv($left, $right)
	{
		return $left / $right;
	}
}

// では早速使ってみよう。「Add」か「Div」という文字を渡すと計算してくれるなかなかのやつ


$method = 'Add'; // 足し算をしよう
$left   = 10;    // 左辺は10
$right  = 5;     // 右辺は5としよう

// 計算機のお出ましだ
$calc = new Calc;

// 場合によって呼ぶメソッドを変えよう
if ($method === 'Add') {
	$answer = $calc->execAdd($left, $right);
} elseif ($method == 'Div') {
	$answer = $calc->execDiv($left, $right);
}


// とりあえず、$answerは15だった！




/*
 
まあ、こういう書き方は昔からありがちである。

なるほど、当然これだと処理が「Calcクラスの実装ありき」になってるので
Calcクラスのメソッド名とかが変更になれば、元の処理の流れも修正をしなきゃいけない。
計算ロジックを修正するときも、足し算割り算どちらにも関わらずこのクラスの書き換えが必要。

何をするにもCalc課長の重い腰を上げて頂く必要があるのだ。

＝依存性が強いとはこういうことか！

じゃあ、DIっぽくしてみよう。
「依存性の注入」的なものである。

そもそも、Calcクラスの役割は「計算する」という概念なわけで、
「何々の計算をする」という具体的な所まで包括するといろいろ詰め込みすぎてしまう。
いろんな用途で編集されうるクラスになってしまうということだ。

なので、シンプルに分けていくことにする。
Calc課長しかいろいろできないのは困るので、
「計算する！」というGoサイン出しまでを受け持ってもらい、
「何々の計算をする！」という細かい話は、部下の「モジュール」に分けてそれぞれに依存していこう。

 */

// 「何々の計算をする」にあたる、計算モジュールの実装フォーマット(interface)だよ。
// これを土台に、足し算や引き算を作って、CalcDIに「注入」するよ。
interface CalcModule
{
	// 計算モジュールには、とにかく「計算結果をくれ」というメソッドだけは必ず実装してね。
	// CalcDI課長が必ず呼ぶよ。
	public function getResult($left, $right);
}

// 計算モジュール「足し算」だよ
class CalcAdd implements CalcModule
{
	public function getResult($left, $right)
	{
		return $left + $right;
	}
}

// 計算モジュール「割り算」だよ
class CalcDiv implements CalcModule
{
	public function getResult($left, $right)
	{
		return $left / $right;
	}
}


// 計算をするクラスがDIっぽくなったよ。
// CalcさんからCalcDIさんに進化した！(実際はスーパー社員からハンコ押し係に格下げ)
// 計算部分は「モジュール」として別のクラスに分けていくよ。
class CalcDI
{
	// とにかく、「計算する！」はこれだけだ！
	// 計算を実行するときは常にこれを呼ぶだけでいいよ。
	// その代わり、$moduleに「何々の計算をする」にあたるモジュールをセットしてね。
        // あとCalcModuleの枠に従ってない部下は受け付けないからね！
	public function exec(CalcModule $module, $left, $right)
	{
		// 計算結果を返すね
		return $module->getResult($left, $right);
	}
}


// では、CalcDI版で足し算をしよう。
$method = 'Add'; // 足し算をしよう
$left   = 10;    // 左辺は10
$right  = 5;     // 右辺は5としよう

// 場合によって「何々の計算をする」部分だけを取り分けよう。
if ($method === 'Add') {
	$module = new CalcAdd;
} elseif ($method == 'Div') {
	$module = new CalcDiv;
}

// さあ計算だ
$calc   = new CalcDI;

// 「計算する！」をひたすら叫ぶだけのCalcDIさん
$answer = $calc->exec($module, $left, $right); 

// $answerは15だった！


/*
 
これでもうCalcDI課長は全体の処理で口火を切る「計算をする！」を叫ぶだけの係になり、
ごちゃごちゃ触れられる機会が激減した事が分かった。

計算の種類を増やしたり、計算の内容を変更するときは
それぞれのモジュールを調達したり編集するだけでよくなった。

ただ、まだモジュールの生成に分岐が入っていて実装側はだるいままである。
依頼者は、課長に仕事を依頼する前に望む処理ができる社員を自分で引っ張ってこなければならないのである。

ではここで、やりたいことを伝えれば勝手にモジュールを取ってきてくれる
Factory主任にお出ましいただこう

Factory主任「望みを言え！！さすれば適切な社員をアサインしてやる！」

 */



// ----------------------


// Factory主任だよ。計算モジュールをよしなに取ってくるすごいやつだよ
class CalcModuleFactory
{
	// 計算したい種類を教えてくれ！
	public function make($method)
	{
		// その種類なら、計算モジュールの名前はこれのはずだ！
		$moduleName = $this->getModuleName($method);

		// 一応計算モジュールがあるかどうか事前に調べておこう！
		$this->_checkModule($moduleName);

		// 計算モジュールが居たぞ受け取れ！！
		return new $moduleName;
	}

	public function getModuleName($method)
	{
		return 'Calc'.$method;
	}

	protected function _checkModule($moduleName)
	{
		if (!class_exists($moduleName)) {
			throw new Exception('計算の種類:'.$moduleName.'は未実装のようだ！');
		}
	}
}

// ではFactory主任に助けてもらって足し算を。
$method = 'Add';
$left   = 10; // 左辺
$right  = 5;  // 右辺


// 分岐もモジュール探しも全部Factory主任にお任せだ
$factory = new CalcModuleFactory;
$module  = $factory->make($method);

// ささっと計算！
$calc    = new CalcDI;
$answer  = $calc->exec($module, $left, $right);

// $answerは15だった！


/*

すばらしい。
これでもう、計算の種類を追加するときはモジュールを作るだけで良くなった。
他に触るべき処理もなくなってしまった。

CalcDI課長はモジュールと左辺と右辺をもらって「計算する！」を叫ぶだけであり、
渡すモジュールはFactory主任が勝手に連れてきてくれるし、
具体的な計算処理であるモジュールたちはinterfaceの秩序のもと足並みを揃えてお行儀良くしながら、
自分の処理に集中しているからである。

結局メインの処理は「目的(やりたい事)」と「材料(左辺と右辺)」を用意するだけで、
もう何も弄らなくて良くなってしまった。

やりたい事が増えても、モジュールを追加(スペシャリスト社員を雇用)するだけでいいのである。

以上で、DIの良さを実感し、なんとなくわかったつもりになれた。

なお、LaravelはDIの概念を掲げてソースを構築しているので、とても勉強になる。
自分も綺麗な実装ができるように日々精進する次第である。


以上でDIってなんだろう？は終了です。





p.s.
これだけ整頓されているとワンライナー化してドヤ顔することもできるぞ！
(ワンライナーは独りよがりにならない範囲で計画的に！)
*/

$answer = (new CalcDI)->exec((new CalcModuleFactory)->make($method), $left, $right);