EC-CUBE クロネコwebコレクトAPI方式での通知エラーを解消する
EC-CUBEにクレジットカード決済を導入する方法の一つとして、クロネコwebコレクトがあります。今回API方式で導入し、クロネコテスト環境でテストしてみたところ、通知エラーが発生しました。（EC-CUBE → クロネコテスト環境への通知はOK（〇） クロネコテスト環境 → EC-CUBEへの通知がNG（×））
試行錯誤の上解決いたしましたので忘備録として残します。
前提事項
設置環境は以下の通りです。
- EC-CUBE (2.13.5)
- SSL：グローバルサイン（企業認証型）
- サーバー：さくらサーバー
- クロネコｗｅｂコレクト：API方式
API方式の場合、SSLが必須ですが、セキュリティレベルの高いSSLでないと動作しません。
クロネコwebコレクトのサポートに連絡し、「グローバルサインの企業認証型を推奨します」という回答であったため、グローバルサインの企業認証型のSSLをサーバーに設置しました。
発生しているエラー
クロネコwebコレクトテスト環境設定で、クレジットでテスト購入を行いました。
クロネコテスト環境管理画面に、クレジット情報の通知が表示されたことを確認し、クロネコテスト管理画面から、EC-CUBEへ決済情報の通知テストを行ってみました。
そうすると、以下の画像のような「決済依頼データ通知異常終了」というエラーが発生しました。
当然EC-CUBE側には通知されていませんでした。
ググったうえでクロネコサポートに問い合わせ
わからないことはGoogleで調べる。
ということで、エラーメッセージでの調査、クロネコwebコレクト側の事例検索、EC-CUBE側の事例検索など、あらゆる角度から探してみました。
しかし、探せた情報は「決済依頼データ通知異常終了」はクロネコ推奨のSSLでない場合に発生します。というものでした。
ここで、クロネコwebコレクトのサポートに電話してみました。
サポートに、文頭の環境を伝え、「決済依頼データ通知異常終了」が発生する旨を伝えたところ、SSLには問題がないが、所見では原因が特定できないため、EC-CUBEのログを送付してほしいということでしたので、ログをすべて取り、エラー等のプリントスクリーンも添付し回答を待つことにしました。
※本部ブログを書いている現時点ではまだ回答待ちです。
追記：翌日（2018/7/26）サポートより回答がありました。
ここで気になった現象を掘り下げて調べてみました。
回答を待つ間、別の角度から考えてみることにしました。
クロネコwebコレクトからEC-CUBEへ何らかの情報を通知する場合、EC-CUBE側に受信する部分があります。
EC-CUBEの受信部に問題があれば、当然通知が失敗します。
そこで何の気なしに、ブラウザで受信部にダイレクトアクセスしてみました。
そうしたところ、「Internal Server Error」が発生しました。
ただ、エラーになるのは、受信部のフォルダだけで、他のフォルダではInternal Server Errorが発生しませんでした。
フォルダのパーミッション等調べましたが、特に問題がありませんでした。
ということは、.htaccessの設定の問題が疑われました。
そこでAPI方式の受信部に設置される.htaccessを見てみました。
なるほど原因はこれでした。
php_flag mbstring.encoding_translation 0
php_value output_handler null
php_value variables_order EGPS
php_flag session.auto_start 0
php_flag session.use_trans_sid 1order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx※IPアドレスは伏せた表現にしています。
受信部の.htaccessファイルを見てみると、上記の内容が記載されていました。
本来ならば、どうということのない記述ですが、さくらサーバーの場合は致命的です。
さくらサーバーで苦労された方ならピンと来られるかと思いますが、さくらサーバーでは、.htaccessにPHPの設定をすることができません。もし.htaccessにPHPの設定を記述すると、「Internal Server Error」が発生します。
つまり、クロネコシステム側からアクセスしてもInternal Server Errorが発生するため、クロネコwebコレクトテスト管理画面からの通知が異常終了していたのです。
このようにして解決しました。
.htaccessに記述されていたPHP設定は必要な項目ですが、.htaccessには記述できないため、php.iniファイルに記述しました。
さくらサーバーでは、フォルダ単位でphp.iniの記述ができます。
.htaccessファイルは、以下のように記述しました。
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx※IPアドレスは伏せた表現にしています。
PHPの設定部分を.htaccessから削除しました。
php.iniファイルには、以下のように記述し、受信部のフォルダにアップロードしました。
mbstring.encoding_translation=0
output_handler=null
variables_order=”EGPS”
session.auto_start=0
session.use_trans_sid=1
phoinfo();を記述したphpファイルを作り、設定値が反映されていることを確認し、再度クロネコwebコレクトテスト環境管理画面より、通知テストを行ってみたところ、EC-CUBEの管理画面に通知ができました。
その後本番設定に切り替え、EC-CUBEとクロネコwebコレクト間で相互通信ができることを確認しました。
今回は、サーバーの.htaccesに関する仕様が原因でした。
問題のないSSLを導入していても、EC-CUBEの受信部がInternal Server Errorを起こしていたら、その要因を取り除かなければならないことがわかりました。
さらに要注意
クロネコテスト環境から、本番環境に切り替える際に、EC-CUBEでAPIのモジュール設定変更を行ったのですが、設定保存を実行した段階で、強制的に受信部の.htaccessが上書きされていました。
設定を保存するたびに受信部の.htaccessがデフォルト設定に上書きされるため、その度php設定部分を削除した.htaccessをアップロードしなおす必要があります。
最初これがわからず、本番環境に設定したとたん、通知エラーが発生したため慌てました。
修正版の.htaccessファイルの再アップロードで直りました。
この現象は、特定サーバーでのみ発生する要因ではありますが、解決策をググっても見つけられませんでした。本記事が少しでもお役に立てれば幸いです。
ホームページに関するお悩み事やご相談事がございましたら私どもまでご連絡ください。 鋭意ご対応申し上げます。
関連記事
