ECサイトのセキュリティの原則 - 最近の情報漏洩に対して
どうもお久しぶりです。
今日は、最近多発しているECサイトの情報漏洩についてです。
最近、いくつかのWebサイトでおきた情報漏洩のニュースを良く聞きます。
特に、ECサイトでの通常考えられない様な漏洩もあったりするので、発注者側、開発者側の人に対して強く言いたい事があります。
漏れたら危険な情報は持たない
こう言ってしまうと余計な危機感をあおりそうで嫌ですが、基本的に全てのWebサーバは侵入可能です。
どれくらい難しいかという話で、時間や労力を考えなければインターネットに繋がっている全てのサーバは侵入可能なのです。
Webサイトのセキュリティは、それを踏まえた上で、「侵入されても最悪の事態を防ぐ」「侵入させにくくする」という視点で対策を施す必要があります。
なんだか原発と似てますね。
「事故が起きない事を前提に考えてはいけない」という事です。
その為には、基本的なログインIDやパスワードの管理や接続IPの制限、ミドルウェアの保守等も当然ですが、なによりかにより最強なのが「情報を持たない」という事です。
持っていない情報は漏洩のしようがありません。コレが最強です。
では、ECサイトで漏れたら致命的な情報とは何でしょうか？
実害が発生しうる可能性が最も高く、危険度MAXなのが決済情報、それもクレジットカードの情報です。
最近起きた情報漏洩の最悪なケースがコレです。
クレジットカード決済で必要な情報は、カード番号と有効期限、カード名義人情報です。
それだけだとあまりにも危険なので、インターネットで決済する場合に追加で付与された情報がセキュリティコードという、クレジットカード裏面に記載されている3桁の番号です。
この漏洩を起こしたグローバルデータのサイトの場合、なんとこの情報をセットでサーバ内に保持していたのす。
僕らECサイトを制作する事を生業としている人間からは信じられない仕様です。
原発に例えると、「燃料棒を監視も施錠も無い庭の物置に積んどいた」くらいの危険度です。
通常、ECサイトでクレジットカード決済を行う場合、カード番号や有効期限などの決済に必要な情報を、Webサイト上で入力してもらいますが、その情報はECサイト側では保持しません。
ECサイトでは受け取ったカード番号等を、保存せずにそのまま決済代行会社のサーバに安全な通信で送信し、結果を受け取ります。
保存したとしても一時的にサーバのメモリ上にその分だけ保存され、1/100秒くらいで消えてしまいます。
また、カード情報を入力しないでも、1度カード決済をすれば2回目以降はカード番号の入力を省略できる機能があります。
これは、ECサイト内の顧客IDとカードの決済情報を決済代行会社側が結びつけておいて、顧客IDと店舗の契約情報を結びつけて決済ができるという仕組みです。
この場合、店舗の決済ID、暗号鍵、顧客IDが無いと決済できず、そのECサイトのサーバからしか決済を受付ない様になっています。
つまり、カード情報なんかWebサーバで持っていなくても、正規の手順を踏めば正常な決済は可能なのです。
これは予想ですが、グローバルデータではレンタルした端末を返却した後に決済をするので、それまでカード情報を持っていないといけないと思ったのでしょう。
あまりにも決済についての知識が無さ過ぎる仕様です。
考えられる理由としては、
- 制作会社が顧客IDで決済できる事を知らなかった。
- グローバルデータ側がこの仕様を強要した
のいずれかだと思います。
ECに詳しくない制作会社の方へお願いです。
決済については決済代行会社の方が聞いて無い事まで詳しく教えてくれます。ちゃんとサービス内容や仕様を勉強してください。
ECサイトを発注者の方へお願いです。
利便性を優先するあまりに、危険な仕様を強制しないでください。概ね利便性とセキュリティの強さは反比例します。
それにより事故が起きた場合の被害額を考えれば、おのずと正しい判断ができるはずです。
できれば、個人情報についても決済代行会社さんで持って頂きたい位ですね。
EC-CUBEの脆弱性について
さて、お話し変わってEC-CUBEです。
先日、2.11系に危険度の高い脆弱性が発見されました。
http://www.ec-cube.net/info/weakness/
まだパッチを当てていないサイトはすぐにでもバックドア等の確認をして、パッチを当ててください。バージョンアップの必要はありませんが、パッチを充てるだけでは不十分です！改ざんされていないか確認してください。*1
制作会社にお願いしても大した金額は取られません。
今回の脆弱性についての詳細は、EC-CUBE東京ユーザーグループで、EC-CUBEのエバンジェリストでもある川口先生が詳しく解説もしてくれています。
これを機会に、東京近郊の方はぜひユーザグループへの参加もお願いします。「参加」ボタンクリックするだけです。
今回の脆弱性についてですが、SQLインジェクション、XSSとWebアプリの脆弱性のお手本の様な脆弱性のオンパレードです。
でも、EC-CUBEのクレジットカード決済モジュールは、サーバ内にカード情報を保持する様には作られていません。
なので、顧客のカード情報が漏洩する事はありません。
ある条件が揃った際に情報が漏洩する危険性があるというもので、EC-CUBEでは会員のログインパスワードは暗号鍵を混ぜた状態で暗号化されており、ショップの管理者でさえもパスワードを知る事はできません。*2
EC-CUBEはオープンソースであり、株式会社ロックオン主導で開発が進められていますが、多くをボランティアの開発者に支えられています。
その為、時にこういったバグが出てしまう事が稀にあります。
でも、川口先生をはじめ、主要メンバーはECサイト構築のプロなので、漏れても最悪の事態を招かない様に作られています。
また、公式のインテグレートパートナーやコミッターには、一般公開前にこういった脆弱性情報が通知され、公開前にパッチを当てる事ができる様になっています。
コミッターのひとりとして、EC-CUBEのこういった「事故が起きる前提で考える」体制も評価のひとつに加えて頂きたいと思います。
海外向けショッピングサイトも制作可能！ EC-CUBEに多言語対応版が登場！！
ついにリリースされました！EC-CUBEの多言語対応版です。
過去に中国語版がこそっとリリースされて無かった事にされたりと、EC-CUBEで日本語以外の言語を扱う事は色々ありましたが、今回ついに正式にリリースされました！
今回僕は開発にはあまり関わっていませんが、concrete5のローカライズでの経験をふまえ、多言語化する際に翻訳のしかたなど色々口を出させて頂きました。
今回のEC-CUBEの多言語版ですが、残念ながらひとつのサイトで日本語、英語など複数の言語を使えるものではありません。
英語のECサイトやスペイン語のECサイトなど、ひとつのサイトでひとつの言語を使える様になるという物です。
それでも、使い慣れたEC-CUBEで海外向けにECサイトを作る事ができるというのは、ショップオーナーさんにとっては嬉しいことなのではないでしょうか？
ついでに英語版のフォーラムもスタート！
多言語版のEC-CUBEがリリースされた事により、英語のサポートフォーラムもオープンしました。
まだまだ書き込みは少ないですが今後どんどん書き込みが増えていくことでしょう。
僕も英語の勉強がてらなるべく書き込む様にしたいと思っています。
余談ですが、このフォーラムには日本語版のフォーラムと同じ様にバッチ制度があるのですが、その名前にちょっと違和感を覚えますw
一番下のランクは「芸者」じゃないと思うんですよねw
あと一番上は「NINJYA」でしょ！富士山じゃない！！
今は英語版のみ
多言語版といっても、現在は英語の言語ファイルのみリリースされています。
今後、他の言語ファイルも順次追加されていくとの事で、予想ですがスペイン語とか早めに出るんじゃないかなー？と思ってます。
もちろん、オープンソースなので自分で言語ファイルを作る事もできます。
言語ファイルの作り方
言語ファイルは、
/data/locales/
に格納されています。
ここのja.poというファイルをpoeditというソフトで編集し、言語ファイルを作ります。
EC-CUBEの言語ファイルはconcrete5等の言語ファイルと違って、メッセージID（msgid）に普通の英文ではなく、どんな文章、単語なのかをあ表す英語ベースのIDを使っています。
これは、日本語では同じ表記でも英語など他の言語にした場合に表記が変わるものがあるためです。*1
一通り翻訳が終わったら言語ファイルを同じディレクトリに別名で保存すればOKです。
拡張子が.poファイルとは別に、拡張子が.moのファイルができると思います。この.moファイルがプログラム内で使われます。
プラグイン作者は大変
さて、こうなってくるとプラグインが大変です。
日本語だけでなく、英語や他の言語にも対応させた方が利用者は増えるのですが、言語ファイル作るのが面倒です。
また、日本語版と多言語版両方に対応させるとなると、また一苦労です。
将来的には多言語版1本にまとめて欲しいですね。
ロックオンさんに強く言っていきたいと思います。
海外向けECサイトをやってみよう！
せっかく多言語版が出たので海外向けECサイトをやってみましょう。
最初は英語サイトだけで充分です。世界の多くの国で英語は第二言語として利用されており、想像以上に自社の顧客の絶対数を増やしてくれます。
ただ、何点か気をつけないといけない点があります。
税金
関税や消費税など、国や販売主体をどこに置くかによって税金の計算が変わってきます。
だいたい、関税は計算する事が難しいので、「だいたいこれくらいだよ〜」という案内にだけとどめておき、あとはその国の税関でかかったのを大人しく払ってもらう感じです。
消費税も国によっては商品によって税率が変わったり、別途別の税金がかかったりと複雑になりがちなので、事前によく調査しましょう。
配送
日本の配送業者は素晴らしいんです。
よく、「佐川は扱いが荒い」とか話を聞きますが、海外だと「届かない」「遅れれる」なんて結構ざらです。
お客さんの手元に届く前に商品が紛失してしまった場合や、配送中に破損があった場合など、「届ける」事に関しては国内の常識が通用しません。
売れないもの
販売先の国や販売する商品によっては届け出が必要だったり、そもそも販売できないもの等があります。
これも事前にしっかり調査しておきましょう。
日本の商品って結構売れます。
さいごに、日本の商品って意外と海外に売れます。
商売柄、海外向けに日本の商品を販売されているオーナーさんとお話しする機会が何回かありましたが、皆さん口を揃えて言うのが
「日本製はすごい！」
という事です。
よく、「Made in Japanはもう終わった」みたいな話を聞きますが、水にはじまり生活雑貨（特に生理用品）などは日本のものがダントツな様です。
「ウチの商品は外人には売れないよ〜」と思ってらっしゃる方、一度しらべてみてください。
本当に日本の商品って海外で人気なんです。
今後、日本は少子化や色々な要因で国内の需要は減少していきます。
需要の減っていく国内で、少ない利益率で奮闘していくよりも、広く世界に対して売っていく必要があるのではないでしょうか？
*1:複数系など
古巣のエスキュービズムという会社で学んだ事
あけましておめでとうございます。
クロスキューブの佐々木です。本年もよろしくお願いします。
今日は、古巣の噂話が耳に入ったので、株式会社エスキュービズムという会社について書こうかと思います。
確か今から5年くらい前の27才の頃、僕はこのエスキュービズムという会社で働いていました。
それまで働いていた会社では自社の社内システムの開発と保守が主な仕事だったのですが、自分たちのためではなく、お客様のためにシステムを作りたくてこの会社に入りました。
当時、エスキュービズムはEC-CUBEのゴールドパートナーで、ベンチャーキャピタルから出資を受けビジネスマッチンングの自社サービスの開発に集中しているときでした。
そんな時に
「ECやりたい」と面接を受け、
「もうEC-CUBEやめるつもり」と言われ
「もったいないなぁ」と言ったら
「じゃあ、やって」と採用されました。
この会社は、社長が東大 > リクルート > 起業で、CTOも早稲田の理工学部の院とかを出てる、インテリ起業でした。
今思うと「よく僕なんかを採用したなー」と思います（笑。
正直、ツライ事もたくさんありましたが、今日はこの会社で学んだ素晴らしいことについて書こうと思います。
続きを読むなぜWordPressではなくconcrete5なのか その2
前回、長くなってしまったの分けた記事の第2弾です。前回の記事はこちらからどうぞ。
なぜWordPressではなくconcrete5なのか その1
concrete5は素人向けのCMS
concrete5は素人向けのCMSです。
こう言うと変な誤解を受けそうですが、concrete5はMicrosoftのWordが普通に使えるレベルの人をターゲットに設計されています。
つまり、Webの素人です。
これはどういう事かと言うと、実際にコンテンツを作るべき人はWebの素人である事が殆どだという事です。
Webサイトは公開したら終わりではありません。
SEO的にも常に更新し続け、情報を発信し続ける事が必要です。
しかも最近は求められるそのスピードもドンドン速くなっています。
昔の様に、制作会社に更新を依頼して、上がってきた物を確認して...ではチャンスを逃し、間に合わない事が多いのです。
管理画面を見て「ウッ！」とならない
EC-CUBEとconcrete5に共通する所に「直感的に扱える」という点があります。
僕はEC-CUBEに出会う前はosCommerceやZenCart等を利用していました。
EC-CUBEに出会った時に感激したのが管理画面の出来の良さです。
正直、osCommerceやZenCartの管理画面は字やメニューが多く開いた瞬間に「ウッ!」となっていたのですが、EC-CUBEの管理画面はごくごく自然に馴染めました。
これと同じ様にXoopsやJoomla!等の汎用CMSの管理画面には正直「ウッ!」となっていました。
concrete5にはそれを感じなかったのが興味を持つキッカケでした。
これはどういう事かと言うと、「迷わない」という事です。
僕は一般の人よりも多くのWebサイトを見て、CMSやツールをいじっています。そんな僕ですら「ウッ！」となる管理画面なら、一般の人にとっては、ただただ恐怖でしょう。
UXの勉強をするとわかるのですが、ユーザにとってWebサイトを閲覧するという行為は想像以上にストレスを与えています。
ボタン一つクリックするのも、画面をスクロールさせるのも嫌がり、如実に直帰率やCVRに結びつきます。
極端に言うと、ユーザは求めている情報を探す事が大嫌いです。
そこにある事を求めています。
これは管理画面でも一緒です。
使いにくい管理画面はユーザのモチベーションや効率を下げ、コンテンツの作成の足を引っ張り、結果としてサイトの価値を下げてしまいます。
その点、concrete5は管理画面を見ずとも、作っているページを直接見ながら編集出来るので非常に直感的にコンテンツを作る事ができます。
concrete5は運用フローを作るCMS
concrete5はそのドラック&ドロップによる直感的なページレイアウトの作成機能ばかり目立ってしまいますが、一番重要な機能は細かな権限設定機能にあります。
これがどういう事かと言うと、ユーザ、グループ毎に使えるメニューを制限し、運用フローを限定出来ると言う事です。
例えば、ニュースページだけ更新する業務の広報担当者がいたとします。
その人にとって製品情報ページは関係ありません。日々の業務で必要なのは正確な情報を「新着情報一覧」というページの下層に速やかに作っていく事だけです。
concrete5では広報担当者に「新着情報一覧」ページの下層にのみページを追加できる権限を設定する事ができます。
また、余計なヘッダーやサイドバーを設定する必要もありません。そういった要素はサイト管理者が事前に管理画面からテンプレートとして設定しておく事ができます。
また、コンポーザーという機能があり、Wordpressの様なフォームに上から順番に入力していけばサイト設計者の意図通のページができあがる機能もあります。（このフォームも管理画面から自由に設定できます。）
- 広報担当者はconcrete5にログインしたら、メニューバーからコンポーザーの「書き込み」というメニューを選択し、用意されたフォームに上から順番に入力していきます。
- リリースに添付するPDFファイルを同じ画面でアップロードし、画像があれば画像もアップロードし、同じ画面内で見出し画像用にクロップします。
入力画面拡大 - その後、作成したページを保存し、上長に報告します。
- 上長は承認前のページを閲覧し、内容に問題が無ければ「承認」ボタンをクリックしてページを公開します。
この様に、concrete5ではそのユーザの業務に必要なメニュー、権限だけを付与し不要な物を表示してユーザを迷わせる事をしない様にWebサイトを構築することが出来ます。
ページを作れる作れないだけでなく、承認作業や、挿入出来るコンテンツの種類まで設定する事ができます。
concrete5でサイトを構築する際は、実運用時の効率を考えた「業務に合わせた運用フロー、UIのデザイン」が最も重要な要素になってきます。
つまりCMSで「ユーザを迷わせない」事ができるわけです。
それも自由に細かく設定できます。
しかもHTML構造を崩される心配もありません。
次回は「カスタマイズ前提」の構造？ です。
なぜWordPressではなくconcrete5なのか その1
どうも、お久しぶりです。
お仕事に追われている間に、あれよあれよと時間が過ぎ、あっと言う間に前回の更新から4ヶ月近く経ってしまいました。
実は先日、僕が参加しているconcrete5というCMSの日本語コミュニティの主要メンバーで、コンクリート ファイブ ジャパン株式会社という新会社を設立しました。*1
僕も一応CTOという肩書きを頂きました。
そのせいか、最近ではEC-CUBEのお仕事よりもconcrete5のお仕事の方がずっと増えてきています。
今日は、なぜ今最も熱く、ノリにノっているWordPressではなくconcrete5という少しマイナーなCMSなのか？という事を書きたいと思います。
（書いてたら随分と長くなってしまったので、何回かに分ける事にしました。）
EC-CUBE3対応！デザインカスタマイズガイドブック
新しくなったEC-CUBE3に対応したデザインカスタマイズブック。2017年1月現在 EC-CUBE3のデザインカスタマイズについて解説されている書籍はこれだけです。とりあえず買いましょう！
concrete5でブログ？
EC-CUBEのカスタマイズを主な事業としてきたクロスキューブですが、ECサイト以外のWebサイトも数多く制作してきました。ただ、クロスキューブでは単純なHTMLのサイトを作った事は無く、私達に求められるのは何かしら機能的なWebサイトばかりで、WordPressやJoomla!を使ったりもしてきましたが、どうもしっくりきませんでした。
そんな時に出会ったのがconcrete5という非常に直感的な汎用CMSでした。
WordPressは非常に優秀な素晴らしいプロダクトです。
長年、多くの有志によって開発が続けられ、熟成した非常に考えられた素晴らしいプロダクトになっています。
ただ、僕がWordPressを使った時に思ったのは
「これはCMSじゃないな、ブログツールだ」
という感想です。
CMSとは「コンテンツ マネジメント システム」略です。解りやすく言うと「コンテンツ管理システム」です。
ここで言うコンテンツには様々な種類がありますが、WordPressはその歴史から「記事」というものをベースに構成されているので、記事以外のコンテンツの扱いは少々苦手です。
ただ、WordPressの素晴らしい点にプラグインの豊富さがあります。
こういったプラグインを活用し、ページやカスタムフィールドを活用する事によって汎用CMS的な使い方ができ、多種多様なWebサイトを構築する事ができます。
しかし、それはconcrete5でブログを作る様な物です。
もっと解りやすく言うとフライパンでケーキを焼く様な物です。
はたしてそれは最適解なのでしょうか？
これは何もWordPressに限った事ではありません。
EC-CUBEでもありますし、もっ身近なところでは何でもエクセルで作ってしまう「エクセル職人」という人々がいます。
多分、皆さんの会社にも１人2人はいると思うのですが、どんな物でもエクセルで作ってしまう人々です。
こういった場合、多くのケースで「一番慣れてるから」という理由でツールを決めてしまいます。
自分だけが使う物であればそれで問題ありません。きっと最も効率が良いと思います。
ただ、僕らの様なお客様の為にWebサイトを作る人間はそうはいきません。
僕らが求めないといけないのは、「クライアントに提供する価値の最大化」です。
「一番得意だから」「慣れているから」「いつも使っているから」「他所もそうだから」という理由で採用するツールを決めてしまうのは、ある意味思考停止と言えます。
クライアントにとって何が最適なのか？という思考をすっ飛ばして、「○○で作るためにはどうすれば良いか？」という考えに移ってしまっています。
- 「一番得意」
- 作業効率が良く学習コストがかからないので短期間で安価に提供できる
- 「他所もそうだから」
- ベンダーが数多く存在し、開発後のクライアントの選択肢が広い
など、何となく考えている理由にもちゃんとした理由はあります。
ただ、制作会社はもっと考える必要があると思っています。
- リリース後の管理運用は？
- ユーザの使いやすさは？
- 後々機能を追加したくなったら？
等々です。
だから僕らはconcrete5でブログは作りません。
ブログを作る時はWordPressを使い、国内向けのECサイトを作る時はEC-CUBEを使います。*2
次回は「concrete5は素人向けのCMS」です。
メンバー募集中です！
4年が経ちました
先月、おかげ様で法人として登記してから無事最初の決算を迎える事ができました。
最初、会社を辞めフリーランスとして活動し始めた時には「いつまで続けられるかな？」と思っていたのですが、独立してかれこれ4年になろうとしています。
今、こうして振り返ると、何とお客様に恵まれていた事かと驚きます。
正直、少人数でやっていると何かトラブルが発生した時にリカバリに時間がかかり、お客様にご迷惑をかけてしまう事もありました。
そんな時でも、一方的にこちらを責めるのでは無く、プロジェクトを成功させるために進んで協力して頂けるお客様ばかりでした。
本当にありがとうございます。この場をかりて御礼申し上げます。
人手が足りません。
とは言え、いつまでもお客様の好意に甘えている訳にもいきませんし、ご迷惑をかけるなんて二度とご免です。
そこで体制を強化すべく、今まで以上に広くメンバーを募集する事にしました。
募集ポジションは、
- アルバイト（時給）
- 役員（年棒制）
です。
「働いてもいいよ」と言う方は、 info@xross-cube.com までぜひご連絡願います。
求める人物像
- 国籍年齢経験学歴性別職種一切不問
- 「独立しようかな」って思ってる方、又は現在フリーランスで活動されている方はちょうど良いと思います。
- 「仕事をもらう」のではなく、「仕事を作れる」人
- 僕らが「一緒に仕事したい」と思える人
弊社で働く事について、メリットとデメリットをご案内しておきます。
メリット
- 自由です。
- 好きな事をやってください。
- 勤務時間、業務内容は法に触れない範囲で自由です
- 仲間がサポートします
- あなたがやりたい仕事に足りない部分を補います。マーケティングや営業、技術的なサポートなど、可能な限り協力します。
- 報酬は自分で決める
- 稼げる額だけ好きに決めてください。
- 出社しなくていい
- 弊社は基本在宅勤務です。出社する所がありません。
- コワーキングスペース、喫茶店、友達の家、プールサイド、好きな場所で仕事してください。
- 家族との時間を多くとれます
デメリット
- 責任があります
- 自由の代わりに重い責任があります。あなたの事業は全てあなたの肩にかかっています。
- あなたが稼がないと、あなたの報酬が支払えません。
- 資金力は皆無です
- 吹けば飛ぶ様な小さな会社です。
- まだまだ安定していません
- 安定を第一に求める方には不向きです
- オフィスはありません
- かっこいいオフィスで働きたい方には不向きです。
ここで、弊社の企業風土というか、どんな会社なのかをご案内します。
一般的な企業とは大きく違います。
独立した理由
僕は金銭的な理由から17才で社会に出たので、様々な企業でいろんな仕事をしました。
イケイケのバイト仲間で始めたベンチャーから、高学歴で頭の良い人ばかりのスタートアップ、1部上場企業など、大小様々です。
それぞれの会社で素晴らしい所があり、また欠点もありました。
ただ、共通して存在する問題は「雇う側」と「雇われる側」に埋められない非常に大きな溝がある事です。
どんなに社長と従業員の距離が近い会社でも、そこの溝はとても深く大きいものでした。
酷い場合だと、経営陣は従業員の事を使い捨ての駒としか考えておらず、従業員も自分の給料の事しか考えていませんでした。
その結果、
- 無駄な残業
- 今の自分の業務への固執
- 不信
- 不当解雇
などなど様々な問題がありました。
でも溝があって当然なんです。
なぜなら経営者と従業員には法で定められた責任や立場が大きく違うからです。
この事が解ったとき、少なくとも国内には自分が求める企業が無い事を知り、独立しました。
法人化した理由
お客様に「個人事業主だと稟議通しにくいよー」と言われた事も大きいですが（笑）、一番大きな理由は
１人の力は非常に小さいという事です。
人間の場合、1=1ですが、1+1=2じゃないって事です。
信頼出来る仲間と助け合って目標に向かって進んで行く時の破壊力は以前経験して知っていました。
「雇う側」と「雇われる側」に大きく溝が出来てしまうなら、「雇う側」しかいない会社を作ればいいと思ったんです。
僕らが目指すところ
僕らの求めるものは、非常に小さく一般的で「充実した人生」を求めています。
金銭的に困窮する事無く生活し、幸せな家庭を持って、自分がやりがいを感じられる仕事をして笑って死にたいです。
なので会社の目指すところは会社で働く人が幸せになる事です。
これは良く誤解されるのですが、自分さえ幸せならいいという物ではありません。
「自分さえ儲かっていればいい」という状況で本当に幸せでしょうか？
僕はそんな社会は嫌です。皆で笑い合える様な社会が良いです。
「自分さえ儲ればいい」と思っている人となんか働きたく無いです。
でも僕にはやりたい事がたくさんありお金もたくさん必要です。
お金大好きです（笑）
小さい会社のまま終わる気もありません。
なので弊社のスローガンは、「目指せ堅実に一攫千金！」です。
書き始めたら長文になってしまいましたが、興味を持って頂けたらぜひご連絡願います。
あなたがどうしたら充実した人生を送れるか聞かせてください。
FuelPHPとCodeIgniterでCMS作ってパフォーマンスを比べてみた
FuelPHP Advent Calendar 2011 ということで、PHP フレームワーク FuelPHP に関するブログをクリスマスまでお届けしています。前日の@9ensanさんの記事はFuelPHPで作るログイン管理
過去記事一覧は、FuelPHP Advent Calendar 2011
CodeIgniterという軽量で高速な非常に気に入っているPHPのフレームワークがあるのですが、最近ライセンス問題が怪しいのと、バージョン2系になってから開発体制も怪しくなっていたので似た様なフレームワークを探していました。
すると、concrete5でもお世話になっている@kenji_sさんがFuelPHPをベタ褒めしていたので試してみる事にしました。
なるべく実際の環境に近い様にと超簡単なCMSを作って比べてみます。
このWebアプリがやっている事は、
- ページのパスからDB叩いてページID取得
- ページIDからそのページのコンテンツをDBから取得
- テンプレートファイルで指定してある描画エリアをキーにしてコンテンツをテンプレートファイル内に描画
と言う様なconcrete5っぽい動きをしています。
時間の都合でトップページ分のデータしか登録していませんし、そもそもCMSなのにコンテンツの登録機能とか作っていません。
まあ、でもベンチには充分だと思います。
可能な限り似た様な処理になる様に同じ様にコントローラとモデル、ビューファイルを作って同じ様に処理しています。
DBも同じテーブルを使っており、両方ともmysqli関数で接続しています。
サーバはさくらのクラウドです。
使ったバージョンはCodeIgniterはVer.2.1.0、FuelPHPはVer.1.1-RC1です。
ちょっとFuelPHPのDBまわりの設定で手間取りましたし、そもそもFuelPHPの正しいお作法に則って書かれているか怪しいですが、とりあえず出来ました。
で、例のごとくapacheベンチをかけて見ます。
ab -n200 -c200 http://cloud.xross-cube.net/CI/ ab -n200 -c200 http://cloud.xross-cube.net/Fuel/
ベンチ結果
で、結果は以下の通りです。
| Requests per second | CodeIgniter | FuelPHP |
|---|---|---|
| 1回目 | 42.74 | 39.38 |
| 2回目 | 30.51 | 46.43 |
| 3回目 | 17.15 | 17.46 |
| 4回目 | 45.06 | 46.77 |
| 5回目 | 44.87 | 21.95 |
| 平均 | 36.06 | 34.39 |
結論から言うとパフォーマンスは変わらなそうな感じです。
今回の環境はクラウド環境なのでどうもムラがある様です。
ちなみに、APCを有効にしてベンチかけたら下記の様な感じでした。*1
| Requests per second | CodeIgniter | FuelPHP |
|---|---|---|
| 1回目 | 126.33 | 72.11 |
| 2回目 | 119.95 | 26.98 |
| 3回目 | 37.30 | 17.46 |
| 4回目 | 25.92 | 93.03 |
| 5回目 | 119.19 | 49.71 |
| 平均 | 85.74 | 51.86 |
ちょっとCodeIgniterの方が速いですね。
結論
FuelPHPは書き方や使い方もCodeIgniter近いですし、なによりライセンスがMITでパッケージ機能があるのでかなり良い感じです。
今後も引き続き使ってみたいなーと思いました。
次は@ounziwさんの「FuelPHP の view に PHPTAL デザインテンプレートを使う」です。
*1:アプリ側でキャッシュ指定とかはしていません。
超使える！EC-CUBEのAPI機能のモジュールが無料で公開されてました！
久しぶりのブログです。
気付いたら全開前回の記事から数ヶ月経ってしまっていました。
先日EC-CUBEのクラウドサーバがファーストサーバさんからリリースされ、色々な特典が付いている事もあって盛り上がっている様です。
その中でもfacebook連携機能と言うのが特に良い感じです。
どんな機能なのかな？と内容を見てみると、EC-CUBEにAPIモジュールをインストールし、facebookのアプリからそのAPIをたたくという物でした。
無料で公開中！
で、このAPIモジュール、株式会社ドリームブリッジさんという会社が開発されたのですが無料で公開されているんです！
EC-CUBE商品検索APIモジュール
しかも2.4系用と2.11系用両方あります！
いやー、素晴らしすぎます。
しかもxmlやjsonやphpのシリアライズ値とか色んな出力形式に対応しています。
元々、僕もEC-CUBEにはAPIが必要だと思って色々実装の仕様を検討していました。色々参考になる仕様があって、どの仕様に合わせようかと思っていて手が止まっていたんですが、ついに出ました！
EC-CUBE 2.11系で変わった事 -商品一覧の取得方法-
EC-CUBEも2.11.1がリリースされましたね。
遅ればせながら2.4系から2.11系*1で変わったところをご紹介していきたいと思います。
今回は遅いクソだと言われ続けていた商品一覧の表示処理の部分についてです。
2.4系からEC-CUBEをいじってる方はまずココで「アレ？」ってなるのではないでしょうか？
1回の表示でSQLを2回発行する様になった
EC-CUBEの商品情報は主に、メインの商品情報と、「規格」と呼ばれるサイズや色違いの商品情報を取得している商品から構成されています。
そこにカテゴリ情報なんかが結合されて商品一覧を表示しているのですが、MySQLではサブクエリからのSELECTでインデックスが利用されないなど、複数のテーブルを複雑に結合している為にパフォーマンスはかなり犠牲にされていました。
特にMySQLで動かした場合は規格を増やすと最悪サイトが止まるレベルの重さでした。
コアの開発者の大河内さんはこの部分にも非常に心を痛めており、「次のバージョンでは絶対に改善させる！」と考えていた様です。
2.11.0で新しく追加されたSC_Product
EC-CUBEの2.11では2.4系には無かったSC_Productというクラスが新たに追加されました。
MVCで言うと「Productモデル」の様な物で、商品の表示関連の処理はここに書かれています。
2.11系ではデータベースでviewを使わない様に変更されています。
なので商品一覧を取得する際は、まず検索条件とソート順で表示する分だけの商品IDを取得し、その後でその商品IDから一覧で表示する情報を取得する様になっています。*2
僕も最初見た時は
「何で2回に分けてるんだ？」
と思いましたが、理由を聞いたところこの方法がPostgreSQL、MySQL共に一番早かった様です。
なので、もし商品一覧で表示する項目や並び順をカスタマイズされたいのであれば、一度このクラスの動きを追っておく事をオススメします。
EC-CUBE2.4.4以前のバージョンに存在するクロスサイトリクエストフォージェリの脆弱性への対応
2011年5月10日、JVNからEC-CUBEの2.4.4以前のバージョンに存在するCSRFの脆弱性に関する情報が公開されました
JVN#37878530 EC-CUBE におけるクロスサイトリクエストフォージェリの脆弱性
*1
CSRF*2とは、簡単に言うと、どんなサイトやHTMLメールからでも、ユーザの意図しない情報をターゲットのサイトに送信させて、望まない操作をさせる事が出来るという物です。*3
特にサイト管理者の方はEC-CUBEの管理画面にログインしたままの状態で、よく解らないリンクやボタンをクリックしない様にしましょう。*4
2.11.0以降のバージョンには存在しませんので、2.11.0以降を利用されている方は大丈夫です。*5
2.4系から2.11系へのデータ移行ツールもリリースされていますが、2.11系は2.4系とは大きく変わり、簡単にはバージョンアップ出来ないのも事実です。
特に多数のカスタマイズを加えていると、より作業量は増えてしまいます。
とりあえず2.4系をそのまま使って、この脆弱性に対応する為のやり方を今回はご紹介します。
*1:クリックしなくても開いただけで攻撃も可能です
*3:具体的にどんな事が出来るかは、ここで書く事は控えさせて頂きます。
*4:管理画面にログインしている時は、ブラウザで他のウィンドウやタブを開かない様にして、コマメにログアウトすれば平気です。
*5:2.11の開発中にこの辺の話や作業をしました。
