だ。ログ。

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

EC-CUBE3のログイン後のリダイレクト先を変える

どうもリダイレクト先を /src/Eccube/Controller/Mypage/ 内のコントローラで探してもリダイレクト先の記述がない。
じゃあどこでリダイレクトさせているのか。と悩んでいたがなんと
色々なりダイレクトページソースを観てみると

<input type="hidden" name="_target_path" value="{{ targetPath }}" />

こやつ!!!

ログインフォームのURLをhiddenの値でパラメータとして渡すと任意でPOST先を変更出来る。
ここだけhidden値でデータの受け渡しをしているとは。。灯台下暗し。

東京ドーム二連戦

f:id:rider_dice:20170919183345j:plain
ドーム

東京ドームの大きな問題

球場メシ問題

神宮は別格だが、横浜スタジアムもそんなにフードに関してはよろしくないが、そのハマスタをも凌駕する選択肢のなさ。それが東京ドーム。
水道橋の駅前は飲み屋ばかり、御茶ノ水の三浦のハンバーグは旨いが試合前にハンバーグガッツリは少し辛い。
と言う事でよくお世話になるのが、水道橋麺通団

https://tabelog.com/tokyo/A1310/A131003/13094345/

決して凝ったうどんではなく、入店してうどんの種類を選んでかしわ天や芋天を買う。お金を支払い讃岐うどんを胃にかっこむ。
食べ終わるまで入店から食べ終わるまで約20分、いりこだしのシッカリした味にコシの強いうどん、そして何よりも回転率が高く混雑し過ぎる事が無い。
東京ドームシティを本郷寄りに渡った近辺にあり、試合前に時間があると足を運ぶ。
ただ本場のうどんを食べている人からすると、物足りないと言う事である。関東の人間からするとこれでも凄いコシだし大ボリュームだと思う。

f:id:rider_dice:20170919183059j:plainf:id:rider_dice:20170919183339j:plainf:id:rider_dice:20170919183136j:plainf:id:rider_dice:20170919183105j:plain
うどんうどんうどん

東京ドームで禁止されているのは500ml以上のペットボトルは持ち込み禁止である。
大容量だからと言って大きめのペットボトルを買うと移し替えで大変な事になる。毎回ドームで親子がワタワタしている光景を見かける。

さて、ドームの球場メシはまずいのかと言う部分。
基本的にマズいと言う事はない、なぜならケンタッキーやピザーラと言った普段でも目にするファストフード、それに神宮でも見かける鐵一もある。
よく目にする「マズい」と言う事ではなく、そこで高いお金を払ってまで食べる価値があるか?と言う事が曲解されてマズい。と言う結論になっているように感じられる。
選手プロデュースは1000円を超えており、外野の場合は広げてゆっくり食べている時間がない。
席が中央寄りだといちいち席からゴミ捨てに行く為に周りの人に退いてもらわねばならない為、かなりうしろめたい。
複数人で行っていれば問題はそれでも軽減出来るがぼっち観戦の場合、なるべく角側を確保出来ないと試合開始から終了まで座りっぱなしも多い。
ドーム来たらやっぱアレ食べなきゃ!となるのが自分の場合は水道橋麺通団なのである。
ちょっと足を伸ばして神田でそばを食べる事も多い。

ビジター導線

確かマドロックがロッテに在籍していた年のロッテvs日ハムでレフトに座ったのが初めての東京ドーム。
こけら落とししたばかりのピカピカの東京ドーム、あの時代特有の少しクリーム色掛かった壁面は今も変わらず。
ベイスターズ戦のレフト開放は4ブロック(一番センター寄りのブロックは中立ブロックでジャイアンツファンも居る)
周りの7割は黒とオレンジ、3割は青と言う構図は変わらず。建築から約30年、壁面の汚れや床の塗装剥がれがかなり目立つ。
おうおうにしてどの球団もそうだが、ホーム側のチームファンの導線は上手く出来ているがビジターファンには冷たい。
レフトビジター応援席は11ゲートを利用するが、この11ゲートは雨風に濡れる。
他の出入り口は屋根に覆われているので、傘をささずに済むが11ゲートだけは入場前に傘が必須となる。
この辺はベイスターズファンがもっとドームに詰めかけ外野ブロックの開放されていけばまた違った事になるかもしれない。

また、11ゲートから内野コンコースには通じていない。11ゲートからではなく、外野立ち見の狭い通路をすり抜けすり抜けコンコースへとたどり着かねばならない。
外野立ち見は基本的にギッシリと人が詰めているので、試合中にすり抜けるのは結構大変。
ライト側がどうなっているのか分からないがレフトの立ち見がギッシリなので、そろそろもう1ブロックくらい開放して欲しいところ。

チケット

ぴあでの先行販売+セブンイレブンの発券をしている。
東京ドーム:G-po
神宮:スワクル
ゴヤ:ドラチケ
と無料会員になっているため、先行購入出来た。全て無料会員で一般発売よりも先にチケットの購入が出来るので、ビジター観戦をする場合は登録して損はない。
今回は座席していなかったが、土曜日はセンターから2ブロック目の3列目通路側、日曜日は応援団の横が席であった。
先行でチケットを申し込みさえすれば、抽選ではあるが外野チケットは比較的取れる部類だと思われる。

いつも思うこと

今回土曜日にこれは強く思うのだが、ドームの通路が狭い事もありビールの売り子さんが渋滞する。
大渋滞した時は5人が最前列で固まってしまっており、身動きが取れなくなっていた。
通路の造り上、非常に狭く警備員が注意するがフェンス手すりに物を置く人が居るので通れない事が多発する。
ごちゃごちゃして動かない、最終的に渋滞が起こる。そしてインプレー中であるにも関わらずプレーが見えない。

f:id:rider_dice:20170919183145j:plain
こういうところ

それと今回ホント酷いと思ったのがベイスターズ攻撃中に手を挙げてビールです、とアピールする→誰も手を上げない
この状況で移動すれば良いのだが、移動しない子が居る。
何度か手を挙げる→誰も反応無しを繰り返し、やっとの事で階段を上がっていく。
そして通路側の自分に当って謝罪なし。重いビールを背負ってドームの勾配を上がる事は非常に重労働なのは察するが当たったらすみません。の一言は欲しかった。

売上が良いなーと思う子は、前を横切る際に「すみませんとおりまーす」と声を出し会釈してから前を通過する。
ハマスタは勾配がキツく外野の入り口が最前列側にあるので気にならなかったがドームは傾斜が緩めで人が目の前に立つとプレーが見えない。
あくまでもいちオッサンの意見だが、あくまでも主役はグラウンドであることを忘れてほしくないと思う。
そして次回以降はフェンス前は避けようと思う。

試合は、井納の仁王立ちと濱口の爆発。
今年のドームは2勝1敗で終了、来年もまたドームにはお邪魔すると思う。
今以上に青いユニフォームが増える事を来季は期待したい。

f:id:rider_dice:20170919183119j:plainf:id:rider_dice:20170919183200j:plainf:id:rider_dice:20170919183210j:plainf:id:rider_dice:20170919183356j:plain

あと土曜日二次会の勇者の遺伝子を歌っている最中に3塁側内野に山口俊選手のタオル(ジャイアンツ)が居た。
来年こそはハマスタで彼を観ることはあるのだろうか。

EC-CUBE3の会員のパスワード文字数の上限と下限を変える

パスワードの文字数がデフォルトでは8文字~32文字と長め。
別に32文字のままにしておいても問題はないが短くしたいな。と思って調査。
まずはEC-CUBEの会員登録画面を覗いて【半角英数記号】でgrepしてみる。

/src/Eccube/Form/Type/RepeatedPasswordType.php

#64行目
            'first_options' => array(
                'attr' => array(
                    'placeholder' => '半角英数字記号'.$this->config['password_min_len'].'~'.$this->config['password_max_len'].'文字',
                ),
            ),

あったあった、$this->config['password_max_len']って言う変数に入ってると。
じゃあ、この変数はと探してみると

/src/Eccube/Form/Type/RepeatedPasswordType.php

#36行目
public function __construct($config = array('password_min_len' => 8, 'password_max_len' => '32'))

平文で持ってるのね。。。と言う事でこの文字列を変更してみる。
効かない。

どうやら、この変数ではなく他の変数に依存しているのかと調査。
password_min_lenをgrepすると

/src/Eccube/Resource/config/constant.yml.dist

#159行目
password_max_len: 32

この行を

#159行目
password_max_len: 16

に変更すると、placeholderに入っていた文字が 半角英数字記号8~16文字 に変更されている事を確認。

ただこれだけだとplaceholderの文字列だけが変わっていて入力制限は入っていない。と言う訳で入力制限のmaxlengthを追加する。

/src/Eccube/Form/Type/RepeatedPasswordType.php

#64行目
            'first_options' => array(
                'attr' => array(
                    'placeholder' => '半角英数字記号'.$this->config['password_min_len'].'~'.$this->config['password_max_len'].'文字',
                ),
            ),
            'second_options' => array(
                'attr' => array(
                    'placeholder' => 'form.member.repeated.confirm',
                ),
            ),

上記を

#64行目
            'first_options' => array(
                'attr' => array(
                    'placeholder' => '半角英数字記号'.$this->config['password_min_len'].'~'.$this->config['password_max_len'].'文字',
                    'maxlength' => 16,
                ),
            ),
            'second_options' => array(
                'attr' => array(
                    'placeholder' => 'form.member.repeated.confirm',
                    'maxlength' => 16,
                ),
            ),

maxlengthの要素を足して、キャッシュを消して入力すると16文字以上はタイプ出来ない事を確認。
これで入力制限自体は問題ないかな。と。

EC-CUBE3のパスワードの平文化

【注意】セキュリティ上非常によろしくないので非推奨

EC-CUBE3のパスワードを平文化させておきたい。と言う要望を結構もらう。
あまりと言うか本当にマズい。それも現在まで稼働しているシステムの場合、データがハッシュ化されていてそのパスワードが全て使えなくなる。

全てのパスが過去になる

と言うところ。やるのは自己責任。
管理画面ログインも全て平文になってしまう。

/app/config/eccube/config.yml

#最下部に追加
auth_type: PLAIN

これを追加して、適当にユーザーを追加しデータベースのパスワードを確認すると平文で登録されている事が確認出来る。

しつこいようだがセキュリティ上あまりよろしくない。
ただ、他のシステムとの連携でパスワード平文じゃないとダメって事もあるので忘備録。

preg_splitのセパレート分割

データベース上の1つのカラムに複数のデータを格納する場合、開発のお作法とかもあるがセパレートを入れて分割させる事がある。
代表的な所で言うと縦棒(|)なんかが代表的。
この縦棒、preg_splitで分割する際に無意識に

	$arr_split = preg_split("/|/",$hogehoge);

と書いてしまうと、文字列全てを分割してしまい正しく配列に入らない。

	$arr_split = preg_split("/\|/",$hogehoge);

セパレート文字列にエスケープを入れること。毎回失念して色んなサイトを回って「ああそうだった」ってなるのでメモ。

jQueryで入力のみ不可にしたい。

jQuery-uiのカレンダーを使うと、その場ではああ。そうそう。と毎回思うけど忘れるのでメモ。

テキストボックスをクリックする→カレンダーが表示される→日付を選択する→選択された日付がテキストボックスに表示される。

と言う基本的な流れはjQuery-ui使えば簡単に出来るけど、文字列をそのまま入力されてしまい定型文で送られてこないと入力チェックを作るのが面倒。
だから入力出来ないようにしたい。

誤)

$(function(){
	$("#hogehoge").attr("enabled",false);
});

これだとクリックすら検知しなくなる。

正)

$(function(){
	$("#hogehoge").attr("readonly",false);
});

これだとクリック検知は問題なし。キー入力のみ不可と出来る。

EC-CUBEで人に依存した文字列の文字化けを解消する

テストをしていて、ある人から文字化けしてしまい文字列が数値文字参照になってしまっている。と言う指摘が有るので調査。
スマホやPCではなく人に依存した文字化けで、同一の環境を容易しても数値文字参照になってしまっている人とそうでない人が発生している。

文字コードやシステム側に悪そうな所は見つからない。
強いて言えば、エラーが出てしまっている部分がjsのプルダウンをクリックした際のダイアログで気付いたとの事。
ソースを見ると全部の2バイト文字が数値参照になってしまっているのが引っ掛かる。

結果として、参照しているセッションのファイルが壊れていること。
ちゃんとした調査はしていないものの、サーバーの負荷を測る為に自分がABコマンドを使いサーバーに過度な負荷を掛けている裏で
テストをしてもらっていた人がEC-CUBEにアクセスした際にエラーとしてログに書き込まれた

/app/log/front_site_yyyy-mm-dd.log

[ShoppingController:index:xxx] - カートが存在しません   [GET, /shopping, 1.2.3.4, https://hogehoge.com/cart, Mozilla/5.0 (Linux; Android 7.1.2; Nexus 5X Build/N2G48C)

上記の「カートが存在しません」
と言う部分に注視、カーネル部分まで確認しているワケではないのであくまでも自分の予測だが
1. EC-CUBEにアクセスする
2. カートセッションをサーバーに作成する
3. 作成したセッションをアクセスしたブラウザに保存する
4. ページが表示される

と言う流れでカートが作成されるが、この2が出来上がる前にカートに商品を入れてしまい、結果としてカートだけではなく全てのセッションとキャッシュが中途半端に出来上がった状態のままでアクセスした人にキャッシュが紐付いてしまい、結果エラーが起きたのではないかと推測。
/app/cache/ 内のファイルを全削除し、もう一度テストしてもらうと数値文字参照は回避され、2バイト文字が正しく表示されている事を確認。

多分安いレンタルサーバー等のレスポンスの遅いサーバーを使っているとこの問題は顕著に出てくる気がする。