さくらレンタルサーバの共用SSLをEC-CUBEで使うと。。

EC-CUBEとさくらレンタルサーバの相性の悪さは前回にも書いたのですが、もうひとつ問題があります。
それは共用SSLを使う場合です。

ECサイトでは、通常、会員登録画面やショッピングカート部分については、セキュリティの為、SSLを使った運用にする必要があります。
独自ドメインSSLはサーバ証明書取得など色々とコストがかかるため、共有SSLを使うことが多いと思います。

しかし、さくらレンタルサーバの共有SSLで運用するといくつか問題が出てきます。
それは、独自ドメインと共有SSL間で、クッキーの情報を引き継げないという問題です。

そのため、例えばショッピングカートの部分はクッキーを使って情報を引き継ぐ必要があるため、最初の商品リスト表示部分から共有SSLドメインで行う必要があります。

そんなわけで、ショッピングカートの部分はすべて共有SSLドメインで対応したのですが、色々テストをしているとなんだかおかしな挙動を発見してしまいました。

それは以下のような挙動です。
ショッピングカートの個数を変更するとSSLではない独自ドメインURLに移動してしまう。
ショッピングカートの情報を削除すると同じく独自ドメインURLに移動してしまう。

上記現象が原因で、クッキーの情報をうまく引き継げず、おかしな動作をしてしまうのです。

この解決方法を色々探っていたのですが、どうやらhtml側の修正ではなく、phpファイルを修正する必要があるこが分かってきました。
以下、私が解決した方法を記述します。
（ちなみにこれはEC-CUBE2.4.4の場合です。2.11系、2.12系はsfReloadメソッドがないようです）

SC_Utils.phpの384行目以降のsfReloadメソッドを修正することで対応しました。
ここで使用しているif文の条件をSC_Utils::sfIsHTTPS()へ変更します。

if ($_SERVER[“SERVER_PORT”] == “443” ){
$url = ereg_replace(URL_DIR . “$”, “”, SSL_URL);
} else {
$url = ereg_replace(URL_DIR . “$”, “”, SITE_URL);
}

　　　↓

if (SC_Utils::sfIsHTTPS() ){
$url = ereg_replace(URL_DIR . “$”, “”, SSL_URL);
} else {
$url = ereg_replace(URL_DIR . “$”, “”, SITE_URL);
}

これはカートの情報を変更するときに呼ばれるメソッドなのですが、どうやら、さくらインターネットのレンタルサーバの共有SSLでは、ポート番号が443ではなく、80で返ってきてしまうようで、うまく判定できないのが原因のようです。
そこで、別の方法でSSLを判定しているメソッドに置き換えることでうまく処理されるようになりました。

この辺の問題は2.12系でもまだ解決していないようです。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=12107&forum=2

また、時間が出来たら2.12系での解決策も探ってみようと思います。

ということでEC-CUBEではさくらレンタルサーバはあまりお勧めできないようですね。。

ちなみに私はよくカゴヤレンタルサーバをよく使います。
この辺の話はまた今度。

ではではまた〜。