だ。ログ。

開発とかスノボとかやきうとか。

この程度の雪で帰るの?

ファンタジー小説を読み終わり、頭の中がファンタジー(゚∀゚)
だからファンタジーな文章を書いてみる。

外は首都圏大混乱の大雪、2014年の時もそうだった。
朝はやいニュースから大雪に関する情報が流れ、帰宅時間に雪のピークを迎え帰宅困難や電車の大幅な遅れが見込まれる。
テレビ、ラジオ、インターネット、どの媒体を取っても「今日は雪が降りますが大丈夫」と言う言葉はない。

12時を過ぎるとオフィスの窓からも白い物が目視出来るようになる。
最初は「うわー降ってきちゃったー」とか「これ位ならねえ」等の談笑が続く。
お昼を過ぎピークを避けコンビニに向かう。さっきまでの降り方とは明らかに強さが変わっている。
気温も落ちてきたのか塊のようなアラレから、大きなボタ雪。よくみると植え込みや電車の線路と言った人の手が入らない部分はうっすらと白くなってきている。この時点で13時。

コンビニで買ってきたコーヒーを啜りながら午後の予定とメールチェックと開発の打ち合わせ。
さて買ってきたご飯をオフィスで食べるか。と外を見ると傘いっぱいに積もった雪の中をいそいそと歩く人の影。
オフィスの有る街は普段はビル群と青空の景色だが流石に銀世界が広がり始め、オフィス内でも「やばくね?」の声が挙がる。

14時45分、東京23区と東京多摩地区に大雪警報が発令。
この時点であきらかに降り方は強まり、ポータルサイトには電車遅延や運行本数の間引きの情報が羅列される。
15時を過ぎ休憩がてらラジオを聴いてみると楽しいおしゃべりの時間帯だが、やはりこの大雪の情報で○×線は雪の影響で~~~と延々とアナウンスしている。
パーソナリティからは「この雪の影響はお帰りの時間帯に影響が見込まれ~~~」と今後の影響に言及がはじまっていた。


さてさて、自分の周りを見るといわゆるモーレツさんが目を輝かす。
こんな天候がなんだ!貢献が一番!仕事が一番!

おっしゃる通り、自分のようなサラリーマンは会社に貢献してナンボ。それも目に見えて金の稼げないシステム屋と言う職業。
営業様のご意見に反論する事は難しい。

さて、この状況で会社に波風を立てられないと言う一般の方々が意見具申をするのは非常に難しい。
しかしこの状況で帰りを気にして電車が動かなくなるんじゃないかと言う焦燥感から仕事よりも大雪に関する情報収集を行い、仕事なんぞ手につかない。
とりあえず状況を観ながら定時まで…と言う恐る恐るの状況判断をしている。

となると自分のような不良社員が意見具申に出る。
まず遠距離通勤者で該当路線の間引き運転がはじまった。積雪は10cmを越え今も降り続いている。
このまま途中まで帰宅し、帰宅難民になった際には労災なり一晩過ごした分の経費は全てもっていただけるのか?

答えは半分はYes、半分はNoである。

結局、その経費が正当であったかどうかの加味を行った上で正当であれば出すよ。
体よくタクシーとかホテルとか贅沢言うな。ネカフェで寝ろ。位のニュアンスだろう。

だいたいここまでで16時。

定時が18時と仮定すれば残り2時間。
その2時間で生産効率が100%の人間なぞ、そうそう居ないであろう。
会社が全て保証してくれていれば良い。
駅に入場出来ない人達が溢れ、交通インフラは軒並み人人人でごった返し乗車すら出来ない。その間も雪は深々と積もる。
休憩室のテレビを観て、もう無理だと思い上司に頭を下げ会社を出る。
もう、その時には手遅れである。
手に持っているビニール傘のビニール部分はあっという間にたわみ傘の骨がきしむ。
行列を成す中で傘を振る事も出来ない。結局の所は傘を閉じ積もる雪を払う事も出来ずに駅への入場に40分掛かった。

と、妄想ファンタジーはここまで。

今後も同様の自体が見込まれる。
同調圧力に似た、この程度で帰るの?に対して平然と帰れるか、一種忠誠心の尺度にも似ている。
その圧力に遠慮してしまう事が、組織としての限界なのだろう。とこの所思う。

EC-CUBE3の既存パーツ 購入の際の数量のサイズ調整

どうしても独自のデザインを当て込んだ際に、既存で提供されているパーツはそのまま残しておりデザインした物と大きさの統一感が揃わない。と言う事がある。
ただ、このパーツ自体はそのまま残してなんとか最小限の修正に抑えたい。と言う事も多々要望としてある。
javascriptの要素を強制的に変更する事も出来るが、提供パーツの修正は以下。

今回は商品詳細ページの数量部分を弄る。
/src/Eccube/Form/Type/AddCartType.php 83行目付近

        if ($Product->getStockFind()) {
            $builder
                ->add('quantity', 'integer', array(
                    'data' => 1,
                    'attr' => array(
                        'min' => 1,
                        'maxlength' => $this->config['int_len'],
                    ),
                    'constraints' => array(
                        new Assert\NotBlank(),
                        new Assert\GreaterThanOrEqual(array(
                            'value' => 1,
                        )),
                        new Assert\Regex(array('pattern' => '/^\d+$/')),
                    ),
                ))
            ;

元のソースをまずは貼ってみた。
addとして要素に情報を足している。今回の場合サイズを値で指定されたので以下ように変える

        if ($Product->getStockFind()) {
            $builder
                ->add('quantity', 'integer', array(
                    'data' => 1,
                    'attr' => array(
                        'min' => 1,
                        'maxlength' => $this->config['int_len'],
			'style' => "width:50px",
                    ),
                    'constraints' => array(
                        new Assert\NotBlank(),
                        new Assert\GreaterThanOrEqual(array(
                            'value' => 1,
                        )),
                        new Assert\Regex(array('pattern' => '/^\d+$/')),
                    ),
                ))
            ;

変更点はmaxlengthの下にstyleとしてサイズを明示した。サイズ自体はこれで変更出来る。

また余談だが、数量部分はmaxlengthが設定されているのにその値を越えてしまう。ここはmaxlengthに任せずにjsで制御するのも手かと思われる。

スクラッチのプラグインパッケージインストールの強みと弱み

特にEC-CUBE3ではそうだが、プラグインでの納品を視野に入れた開発を行う事も多い。
この場合、インストールしたモノが明示的に/app/Plugin/にインストールされるので、後々何をどうしたと言う事がわかりやすい。

ただ、これには大きな問題もある。
他で設定していたプラグインの周辺状況を確認していないと、そのプラグインを打ち消してしまう事がある。
これは発注時点でこちら側から命名規則なりを明示化させる事である程度は回避出来るとは思うが結局は外注して詳細に事を詰めずにやってしまうと

A:既存で動作していたプラグイン
B:今回納品したプラグイン

Bが干渉してしまいAのプラグインが正しく表示出来ない。と言うような問題が出て来る。
この辺の明確な指示もそうだが、結局は下準備が全てなんだなあ。としみじみと感じる。

そしてその修正が何故か元々作ったエンジニアの自分に来ている事で理不尽な気持ちに陥る月曜の午後。

DoctrineQueryBuilderのLimitを設定する

EC-CUBE3で利用されているDoctrine、QueryBuilderを使ったソースコードの簡素化ってのは慣れると便利だが
旧来のおっさんシステム屋からするとまだるっこしい。特にECサイト系の制作だと上限個数とかにこだわるクライアントさんが多い印象。

ってな訳で、QueryBuilderのオプションあんちょこ

$query = $this->createQueryBuilder('hogehoge')
# join系 (例はinner join)
->innerJoin('hoge.Hoge', 'hg')
# group by
->groupBy('fugafuga');
# order by
->orderBy("hogehoge",  "DESC")
# limit
->setMaxResults(10)

ざっくりとこの辺だけ分かれば後はなんとかなるかなと。
パラメータ系が揃っているが、自由度と言う意味でどうなのかと言う部分では使い倒していないのでなんとも言えない。

EC-CUBE3のパスワードリマインダの脆弱性のとりあえずの回避を行う

blog.tokumaru.org

徳丸浩先生が古い記事で上げていたパスワードリマインダがダメな理由。と言う記事を見てそう言えばEC-CUBEもリマインダ自体はメールアドレスを入力して、そのメールアドレスにリマインダメールを発射する仕組みになっている事に気付く。
総当り攻撃でメールアドレスを入力しまくってレスポンスの時間を推測すれば、ある場合と無い場合のレスポンス時間により、このメールアドレスはEC-CUBEのデータベース上に登録されている。と言う推測が出来てしまう。

1. 使わない

そのまんま。メールでのパスワードリマインダは使わない。
潔し。男気にあふれる選択。
ホントはこれに尽きる。パスワード忘れたらお問い合わせフォームからどうぞ。と。

2. 改修

んで本題。
徳丸先生の記事からすると、EC-CUBE3はセキュリティ的にいかんぞ。と。
本当だとパスワードの再設定は1回のみにしておくのが望ましい。またパスワードリマインダ使いました。と言う通知を何らかの方法で行う。と言う部分が必要になるかと思われる。

ただ、ここまでの要件を実装するとなると色々と改修が入る為、回避策と言う訳ではないが有効期間を持たせる形にしてみる。
/src/Eccube/Controller/ForgotController.php 90行目付近

            } else {
                log_warning('Un active customer try send reset password email: ', array('Enter email' => $form->get('login_email')->getData()));
            }
#ここにCookieで任意のデータを登録する
            setcookie("hogehoge", "fugafuga", PASSWORD_DEFAULT),time()+3600,"/forgot");
            return $app->redirect($app->url('forgot_complete'));

上記の場合、利用後1時間はパスワードリマインダを使いました。という記録を残す。と言うロジック。
ただCookie部分は適当に作っているが、本当であれば推測され辛いデータに形成しておくべき。
またリスクとしてはCookie削除すれば結局使えてしまう。またクローラースパイダー等のツールを使ってcookieを持たないツールの場合は無力。
そう考えると本当は実行した回数をカウントして保持して異常値を叩き出したら再発行を一旦停止する。と言う事も必要かもしれない。
これはモヤモヤと考えているだけだが、forgotコントローラが動いた段階で指定した時間のしきい値以上のリマインダが叩かれたらエラーページや申し訳ありませんが現在混雑中です。みたいな表示で逃げる。ってのもありかな。と。

んで、話しを戻してCookieを使った場合。
今度はこのCookieの値が存在した場合はindexコントローラのrenderに値を持たせて

<p><button type="submit" class="btn btn-primary btn-block">次のページへ</button></p>

を制御する。見せないとかボタンが押せないとかその辺でいいと思う。

ajaxのレスポンスヘッダを確認する

セキュリティ診断等で、自分のプログラムの妥当性を見るためにヘッダを確認する事が多々ある。
どうだっけ?ってなるので書いとく。

    success: function(data, return, ajxhead){
        var res_data = ajxhead.getAllResponseHeaders();
    }

コンソールからres_dataをウォッチすると中身が確認出来る。

LaravelでDB設定を入れても反映されない対処

環境構築をしていて、LaravelをインストールしてからDB設定を記述して

$results = DB::select('select * from test_table');

と、接続テストをすると

PDOException
SQLSTATE[HY000] [1045] Access denied for user 'homestead'@'localhost' (using password: YES)

と表示されてしまいDBと疎通確認が取れない。
/config/database.phpには利用するDBの情報は入っているがユーザ名が homestead@localhost
となっている部分が問題。これはLaravel側が持っている.envファイルを優先して読みから出てしまっている。
サーバーから

$cd /Laravelがインストールされているディレクトリ/
$php artisan config:cache

キャッシュの再構築をしたら正しく接続出来た。
初期構築でコピペする。