ELB配下のサーバーを指定して確認する
テスト段階でしか使えないネタ。
いまや複数台構成が当たり前となって時代、ロードバランサーを最上位に置いて下位に複数台のWebサーバー
ELB配下にあるサーバーはELBさんが割り振ったご機嫌次第なんてこともあったり。
スティッキーセッションを使って各サーバーに一定時間割り振られると言う事もあるのだが
基本的にELBの死活監視はpingパスを使うと
ping パス HTTP または HTTPS リクエストの送信先。 HTTP または HTTPS GET リクエストが ping ポートと ping パス上のインスタンスに発行されます。ロードバランサーが応答タイムアウト時間内に "200 OK" 以外の応答を受信した場合、インスタンスは異常と見なされます。応答に本文が含まれている場合、アプリケーションは Content-Length ヘッダーを 0 以上の値に設定するか、値を "chunked" に設定した Transfer-Encoding を指定する必要があります。 デフォルト: /index.html
と書かれている。index.htmlにpingして応答があれば生きている。
応答がなければサーバーへの割り振りを止めて他のサーバーへ割り振りを行うと言う感じだ。
なので、エンジニア全員がA,B,Cのサーバーが有りBのサーバーにアクセスした状態でテストしたい場合、A,Cのサーバーのindex.htmlを抜いてしまえば死活監視からBに全てが割り振られる。
まあ当たり前な人には当たり前なのだろうが、自分みたくそこまでAWSのサービスに詳しく無い人間からすると、ルールを逆手に取った理にかなったやり方だなーと納得してしまった。
AWSのELBにSSLをインストールして、EC2にEC-CUBE3をインストールして運用するとSSLがおかしくなるはなし
図のようにシングルだろうが複数台構成だろうが構わないが、ELB上にSSL証明書をインストールするSSL Terminationと言う技法でELBまではSSL、そこから先は非SSLとして通信すると言うやり方が今のトレンドらしい。
この状況でEC-CUBE3をインストールすると問題が起こる。
インストールStep2のSSL強制が効かない
https://hogehoge.com/install.php/step2
このようなURLでSSLでアクセスする、しかし強制SSLのチェックが出来ない。ブラウザではhttpsで送信しているし鍵マークもついている。
でも、チェックが出来ない。仕方がないから後でconfig.ymlから強制すれば良いや。と放置してインストール自体は完了。
config.ymlからSSL設定をする
/app/config/eccube/config.yml
auth_magic: hogehogefugafuga password_hash_algos: sha256 shop_name: だ。のしょっぷ。 force_ssl: null admin_allow_host: { } cookie_lifetime: 0 cookie_name: eccube locale: ja timezone: Asia/Tokyo pageinrange: false trusted_proxies_connection_only: false trusted_proxies: { } eccube_install: 1
この
force_ssl: 1
null -> 1に変更して、ページを表示させる。
→SSLがリダイレクトしてしまい、ブラウザからページを表示する事が出来ない。
問題点
1. ELBまでは443のSSLプロトコルで来ているね。と言う事で証明書を確認する。
2. ELBはサーバーに通信をHTTPで行う。
ELB→EC2がHTTP通信になってしまう事が大きな問題。
var_dump($_SERVER); ##この辺を確認 ["HTTP_X_FORWARDED_PORT"]=> string(3) "443" ["HTTP_X_FORWARDED_PROTO"]=> string(5) "https" ["HTTP_CONNECTION"]=>
これで確認すると解るが、通常のサーバーに証明書が突っ込まれたサーバーだと、通信がHTTPSだから
$_SERVER['HTTPS'] = onと言う設定が入っているが、この項目が見つからない。
そりゃそうだ、HTTP通信だからSSLじゃねーよとEC2は判断する。
解決策
EC-CUBEのコントローラとなるindex.phpに以下を記述する
/html/index.php
if($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$_SERVER['HTTPS'] = 'on';
}
リダイレクトでも良いんだけど、カートの内容保持の問題もあるので問題としてはEC-CUBEのコントローラが$_SERVER['HTTPS']が存在するかを聞いて、SSL強制のチェックのフラグの可否をするので、HTTPSがありますよ。と言う事を$_SERVER変数に持たせる。
この設定を入れて管理画面にhttpsでアクセスすると、チェックボックスを選択する事ができてフロントページもSSLの無限リダイレクトを回避する事ができた。
EC-CUBEと言う特性上、ELBまでSSLだから入り口出口は必ずSSLで暗号化されてるし問題無い。と言う判断も出来る事は出来るが見た目上の信頼もある。
それと、出来るのであればHTTPSですと明示させる事も必要だと思う。
今後AWSを使ったECサイト構築、それも複数台構成を考える人が多くなると思う。
多分みんなこの部分で引っ掛かる。HTTP_X_FORWARDED_PROTOでググれば文献は一発で出て来るが、サーバー屋、Web屋どちら共に長けている人も少ない。
と言う事でメモっておく。
この辺、もう少しEC-CUBE使ってる技術者の人間がノウハウとして共有すれば幸せなんだろうが、メシの種なのだろう。
EC-CUBE3のデータコミットタイミング
ちゃんとコアプログラムを読んでいない自分が悪いが、EC-CUBE標準の使い方をした場合のデータベースのコミットはページが遷移した後になる。
何が言いたいかと言うと、コントローラ上で処理が完了してリダイレクトの前に一旦ブレイクポイントを置いてデータベースを確認してもまだコミットされていない。
例として以下の会員登録のコントローラで説明する
/src/Eccube/Controller/EntryController.php
case 'complete': log_info('会員登録開始'); $Customer ->setSalt( $app['eccube.repository.customer']->createSalt(5) ) ->setPassword( $app['eccube.repository.customer']->encryptPassword($app, $Customer) ) ->setSecretKey( $app['eccube.repository.customer']->getUniqueSecretKey($app) ); $CustomerAddress = new \Eccube\Entity\CustomerAddress(); $CustomerAddress ->setFromCustomer($Customer); $app['orm.em']->persist($Customer); $app['orm.em']->persist($CustomerAddress); $app['orm.em']->flush(); log_info('会員登録完了');
会員登録完了ページにてログとして会員登録開始と会員登録完了と言うログが書き込まれている。
ただ、このログでブレイクしてデータベースに会員情報は渡っていない。
log_info('本会員登録画面へリダイレクト');
return $app->redirect($activateUrl);
リダイレクトが終わった段階でデータが反映されるので、コミット自体はされておらず登録したデータからアレコレってのが出来ない。
基本的に現状あるEC-CUBEの骨子を変える事自体があまり良い事ではないからやりたくないが、やる場合は事後が基本となりそうなのでメモ。
EC-CUBE3のログイン後のリダイレクト先を変える
どうもリダイレクト先を /src/Eccube/Controller/Mypage/ 内のコントローラで探してもリダイレクト先の記述がない。
じゃあどこでリダイレクトさせているのか。と悩んでいたがなんと
色々なりダイレクトページソースを観てみると
<input type="hidden" name="_target_path" value="{{ targetPath }}" />
こやつ！！！
ログインフォームのURLをhiddenの値でパラメータとして渡すと任意でPOST先を変更出来る。
ここだけhidden値でデータの受け渡しをしているとは。。灯台下暗し。
東京ドーム二連戦
東京ドームの大きな問題
球場メシ問題
神宮は別格だが、横浜スタジアムもそんなにフードに関してはよろしくないが、そのハマスタをも凌駕する選択肢のなさ。それが東京ドーム。
水道橋の駅前は飲み屋ばかり、御茶ノ水の三浦のハンバーグは旨いが試合前にハンバーグガッツリは少し辛い。
と言う事でよくお世話になるのが、水道橋麺通団
https://tabelog.com/tokyo/A1310/A131003/13094345/
決して凝ったうどんではなく、入店してうどんの種類を選んでかしわ天や芋天を買う。お金を支払い讃岐うどんを胃にかっこむ。
食べ終わるまで入店から食べ終わるまで約20分、いりこだしのシッカリした味にコシの強いうどん、そして何よりも回転率が高く混雑し過ぎる事が無い。
東京ドームシティを本郷寄りに渡った近辺にあり、試合前に時間があると足を運ぶ。
ただ本場のうどんを食べている人からすると、物足りないと言う事である。関東の人間からするとこれでも凄いコシだし大ボリュームだと思う。
東京ドームで禁止されているのは500ml以上のペットボトルは持ち込み禁止である。
大容量だからと言って大きめのペットボトルを買うと移し替えで大変な事になる。毎回ドームで親子がワタワタしている光景を見かける。
さて、ドームの球場メシはまずいのかと言う部分。
基本的にマズいと言う事はない、なぜならケンタッキーやピザーラと言った普段でも目にするファストフード、それに神宮でも見かける鐵一もある。
よく目にする「マズい」と言う事ではなく、そこで高いお金を払ってまで食べる価値があるか？と言う事が曲解されてマズい。と言う結論になっているように感じられる。
選手プロデュースは1000円を超えており、外野の場合は広げてゆっくり食べている時間がない。
席が中央寄りだといちいち席からゴミ捨てに行く為に周りの人に退いてもらわねばならない為、かなりうしろめたい。
複数人で行っていれば問題はそれでも軽減出来るがぼっち観戦の場合、なるべく角側を確保出来ないと試合開始から終了まで座りっぱなしも多い。
ドーム来たらやっぱアレ食べなきゃ！となるのが自分の場合は水道橋麺通団なのである。
ちょっと足を伸ばして神田でそばを食べる事も多い。
ビジター導線
確かマドロックがロッテに在籍していた年のロッテvs日ハムでレフトに座ったのが初めての東京ドーム。
こけら落とししたばかりのピカピカの東京ドーム、あの時代特有の少しクリーム色掛かった壁面は今も変わらず。
ベイスターズ戦のレフト開放は4ブロック（一番センター寄りのブロックは中立ブロックでジャイアンツファンも居る）
周りの7割は黒とオレンジ、3割は青と言う構図は変わらず。建築から約30年、壁面の汚れや床の塗装剥がれがかなり目立つ。
おうおうにしてどの球団もそうだが、ホーム側のチームファンの導線は上手く出来ているがビジターファンには冷たい。
レフトビジター応援席は11ゲートを利用するが、この11ゲートは雨風に濡れる。
他の出入り口は屋根に覆われているので、傘をささずに済むが11ゲートだけは入場前に傘が必須となる。
この辺はベイスターズファンがもっとドームに詰めかけ外野ブロックの開放されていけばまた違った事になるかもしれない。
また、11ゲートから内野コンコースには通じていない。11ゲートからではなく、外野立ち見の狭い通路をすり抜けすり抜けコンコースへとたどり着かねばならない。
外野立ち見は基本的にギッシリと人が詰めているので、試合中にすり抜けるのは結構大変。
ライト側がどうなっているのか分からないがレフトの立ち見がギッシリなので、そろそろもう1ブロックくらい開放して欲しいところ。
チケット
ぴあでの先行販売＋セブンイレブンの発券をしている。
東京ドーム：G-po
神宮：スワクル
ナゴヤ：ドラチケ
と無料会員になっているため、先行購入出来た。全て無料会員で一般発売よりも先にチケットの購入が出来るので、ビジター観戦をする場合は登録して損はない。
今回は座席していなかったが、土曜日はセンターから2ブロック目の3列目通路側、日曜日は応援団の横が席であった。
先行でチケットを申し込みさえすれば、抽選ではあるが外野チケットは比較的取れる部類だと思われる。
いつも思うこと
今回土曜日にこれは強く思うのだが、ドームの通路が狭い事もありビールの売り子さんが渋滞する。
大渋滞した時は5人が最前列で固まってしまっており、身動きが取れなくなっていた。
通路の造り上、非常に狭く警備員が注意するがフェンス手すりに物を置く人が居るので通れない事が多発する。
ごちゃごちゃして動かない、最終的に渋滞が起こる。そしてインプレー中であるにも関わらずプレーが見えない。
それと今回ホント酷いと思ったのがベイスターズ攻撃中に手を挙げてビールです、とアピールする→誰も手を上げない
この状況で移動すれば良いのだが、移動しない子が居る。
何度か手を挙げる→誰も反応無しを繰り返し、やっとの事で階段を上がっていく。
そして通路側の自分に当って謝罪なし。重いビールを背負ってドームの勾配を上がる事は非常に重労働なのは察するが当たったらすみません。の一言は欲しかった。
売上が良いなーと思う子は、前を横切る際に「すみませんとおりまーす」と声を出し会釈してから前を通過する。
ハマスタは勾配がキツく外野の入り口が最前列側にあるので気にならなかったがドームは傾斜が緩めで人が目の前に立つとプレーが見えない。
あくまでもいちオッサンの意見だが、あくまでも主役はグラウンドであることを忘れてほしくないと思う。
そして次回以降はフェンス前は避けようと思う。
試合は、井納の仁王立ちと濱口の爆発。
今年のドームは2勝1敗で終了、来年もまたドームにはお邪魔すると思う。
今以上に青いユニフォームが増える事を来季は期待したい。
あと土曜日二次会の勇者の遺伝子を歌っている最中に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
これを追加して、適当にユーザーを追加しデータベースのパスワードを確認すると平文で登録されている事が確認出来る。
しつこいようだがセキュリティ上あまりよろしくない。
ただ、他のシステムとの連携でパスワード平文じゃないとダメって事もあるので忘備録。
