Eccube

TLS1.2対応サーバー(PHPのバージョン次第!)

今日、xserverにインストールしていたECCUBE

 

で、
PHPのライブラリー「curl」のバージョンが、0.9.8bとなり、
決済モジュールがエラーとなる。
(通信が確率出来ない状態)

TLS1.2に対応しているからと、
お客さんにも大丈夫ですよ、といったのですが、ダメで、

GMOペイメントに連絡するも、やっぱりTLS1.2に対応しておらず、
今回は、テスト決済なので、本番環境はTLS1.0でも動くのだけど、
せっかくインストールするのだから、
ちゃんと対応した状態で渡したかった。

GMOペイメントが、TLS1.2が必須になるのは、2018年夏予定

 

で、xserverに電話してみた。

私: TLS1.2に対応していると書いてあるが、実際のところ、通信が出来ないと。
鯖: SSLを入れれば、1.2になります。
私: でも、それって、外部からアクセスする場合であって、現に、PHPからエラーになる
鯖: 同じ説明を繰り返し、メールをよこせと。
私: 単に、PHPのcurlのバージョンが古いから、バージョンアップできるのか?が、聞きたいだけだと。

鯖: OPENSSL1.0以上は、PHPのバージョンを、5.6以降にすれば対応します。

私: ありがとうございます。

ちょっと、言い合いみたいになっていたので、
即、電話を切りました・・・(汗

***

ということで、
コンパネから、5.1.2 > 5.6系へ。

xserver PHPバージョン変更

 

すんなり、決済完了!!

 

GMOペイメントの説明だと、TLS1.2としか言わず、
Curlのバージョンのことまでしか、言わず・・・

OpenSSL 1.0系には、PHP 5.6系だと使えますよ。

と、
一言、言ってくれれば、こんなにサーバー選びに難儀する必要もなく・・・

ということで、

他のサーバーはわかりませんが、
仕様表記にTLS1.2がある、ない、関係なく、PHPのバージョン次第
ということでしたので、

これからは、無駄な時間を使わずに、済みそうです!

PS.

別のサーバーで調べてみましたが、
別に、PHP5.6でなくても、5.3系でもOpenSSL 1.0系がインストールされていました。
サーバーによりけり、ということです。

OpenSSLのバージョンなんて、仕様に乗ってないしな~
お試しで、phpinfo()を吐き出してみるしかないようです。

 

-

顧客/商品(dtb_customer/dtb_products)情報を共有@ECCUBE

おそらく、3.0系なら、接頭語を使えそうなので、
気にしなくても良さそうですが、
※さくらサーバー : クイックインストールより

3.0系は、まださわりたくないので、
2.13系でやるなら、いろいろと、大変そう・・・

***

とりあえず、ソースを見た限り、接頭語的なものはないので、
顧客/商品情報を共有する場合に、

思いついた手法は、3つ。

  1. それぞれのECCUBEのテーブルに接頭語を入れ、(例 dtb1_customer)
    class_exの該当ソースを、全て、置き換える。
  2. それぞれECCUBEを、別のDBにして、
    dtb_customer / dtb_products だった場合、
    接続先DBを、切り替える。
  3. タイマーで、それぞれのデータをコピーするか、
    DBトリガーは使えないので、
    追加・変更された時は、別のデータベースへ、更新を伝える。

参考 >?http://xoops.ec-cube.net/


※以下は、作る前の模索・まとめです

1. 接頭語を入れる

classを直接書き換えるなら、
* dtb_ > dtb1_
* mtb_ > mtb1_
に、それぞれ置換だけで済み、
dtb_customer / dtb_products だけは、接頭語ナシで共有する

※ただ、アップデートがある度、書き換えないといけないので、
class_exで、該当ソースをそれぞれコピーして使うのが、吉かな?
でも、すこぶる面倒・・・
だけど、もうアップデートはなさそうだし。
あと、プラグインも変更が必要な可能性大!

***

2. 接続先を変える

get、 update 、insertを使う場合、内部的には、SQLを作って、
SC_Query.php > query に渡しているので、
SQL内に、dtb_customer / dtb_productsが入っている場合は、接続先を書き換え。

具体的には、SC_Queryを派生させたサブクラス を作成し、
(SC_Query_Exではなく)=これは、通常DBに接続するために、おいておく
__constructで、接続先をメインDBへに書き換えたものを作り、

query内に、分岐を作り、上記サブクラスで、別のデータベースからデータを取ってくる。

※inner join とかで、繋いでいる場合、別のデータベースの注文情報などを書き換えてしまう可能性大!

***

3. トリガー的に書き換える

2は、現実的じゃなく、1は、ソース管理が面倒なので、
どれか、更新されたら、トリガー的にデータをコピーするのが、良さそうです。

※ただし、商品情報は、画像データのコピーとかが必要なので、その書き換えも必要です!

※今回は、顧客情報だけの共有なので、商品情報までは、加味してません。

***

会員登録・変更時に使用されるコードは、

SC_Helper_Customer.php :?sfEditCustomerData

変更の時は、
LC_Page_Mypage_Change.php :?lfRegistCustomerDataを、経由し、
上記、SC_Helper_Customer.php :?sfEditCustomerDataで、処理。

ログインなどのセッション情報は、SC_Customer内の関数でupdateされている。

.

これらを踏まえ、書き換えるのは、

  • SC_Helper_Customer.php :?sfEditCustomerData
  • SC_Query : update

の2箇所。


接続先を変えるため、SC_Query :?__construct から、派生し、クラス作成。
重要: SC_Query_EX.phpではない!

define.phpあたりに、別のデータベースの接続情報を作成し、
それを、参照する形で、それぞれの接続を作り、

追加・更新されたデータを、書き換える。

 

なんか、コレを、書いている途中、
「3サイトじゃなくて、1サイトでいい」と言われ、ココで断念・・・

ご参考に。


 

* 排他処理 *

データ追加する場合、IDがバッティングしてしまう可能性があるので、排他処理が必要ですが、
ファイルの書き込みには、FTP情報が必要なので、
今回は、排他処理用のテーブルを作って、そこにデータがある場合は、
遅延(sleepループ)させます。
※商品情報の場合は、管理者が同時に書き換えることはないので、不要。

同様に、
同一ユーザーが、ユーザー情報を、
複数サイトから同時に、変更する可能性も低いので、
遅延処理は、insertの時だけで、良いはずです。

 

-