ＥＣサイトの一般的なシステム構造と、考慮点をまとめたメモ

　昨日のブログで、通論の話をしたんで、ちょっとＥＣサイトの通論なんつーのを、今日はまとめてみました。

　まあ、昨日も書いたけど、今はオブジェクト指向全盛だから、この業界的に言うと、こういう内容をユーザーからヒアリングするっていう形が一般的であって、こういうノウハウを教える人たち、別の人たち（その一派がプチリタの人たちなのかあ？？）になるんだろうけど。。

　まあ、そんなうだうだ話は、さておき、ＥＣサイト通論
　メモなんで、抜け落ちてるところは、いっぱいあると思うよ。

---

ＥＣサイトは、だいたい以下の構造に分かれる

・Ｗｅｂ上の話
　　・ＤＢから、商品表示部分（ＤＢなければいらない）
　　・ショッピングカート
　　・決済（前払いのクレジットなどの場合）

・Ｗｅｂじゃない事務処理
　　・入金処理
　　・発送

・例外系
　　・キャンセル／返品／配送不能処理

ここで、考慮点は、
（１）ＤＢを持つか持たないか
　→持つ場合、商品表示部分はＣＧＩ：デザイナーを関与させるの大変
　　　持たない場合、ショッピングカートに商品名、価格を渡す。デザイン可能。
　　 →ショッピングカートの形式がかわる
　→ＤＢを使わない場合、直接ＧＥＴ型で、適当なデータを入れられるのに注意する

（２）集金方法
　昨日のブログに書いた。
　で、問題は、どのような集金代行会社を選ぶか。
　→個人の場合、使えない代行業者あり
　　ＣＧＩを呼び出すだけでＯＫな代行業者、ＣＧＩを作らないといけない業者
　　ざまざまあるので、ここの選び方で、開発方法が変わる

・継続の場合、クレジットの情報は、サイト側で管理することになる。
　この場合、ゼウスなど、契約が違うので注意
（ゼウスの一般的な使いかたは、サイト側に顧客情報を通知しない方法だか、
　この契約方法もある。契約の仕方が違う）。

　銀行口座から引き落としの場合、口座振替依頼書を送り、それを受け取ってからになる。第一回目の引き落としには、たいてい間に合わないので、第一回目の引き落としをどうするか、考える必要あり。

　コンビニ決済の場合、自社で、あの紙をだすと、バーコードが読み取れない危険あり

　なんで、宅急便、郵便の代引きがべんり。

　郵便振替用紙は、郵便局で、宅急便の送り状は、業者にいうと、くれた気がした
（自信ない。まちがってるかも）郵便振替は、電信と一般の違いに注意
　銀行口座に振り込んでもらうときには、馬鹿が多いのに注意
（なぜか、自分の口座名に振込先を書いてしまう馬鹿がいる。誰が振り込んだか、わからんだろう）

（３）キャンセルのワークフロー
　　代行業者との、集金のからみがある。

（４）訪問販売法など、法律のからみ
　・確認画面をだす
　・とくていなんとかなんとかにもとづくひょうじというのがある。
　・個人情報保護のからみ

（５）Ｗｅｂから事務処理のつなぎ
　・ここをつなぐと、自動化できる→するかどうか
　・ＤＢ直接書き込みにすると、サーバーは自社になる（たいてい）
　・メールでやるのであれば、サーバーはＣＧＩ（メール送信）
　　事務処理は自社（メール自動取り込み）という手もある。

（６）セキュリティ・バックアップ
　ＳＳＬでやる→ＣＡは？
　
その他
・発送に関しては、事務代行業者などもある。

Fellicaの仕様置き場＆Fellicaを使って認証するシステム、作ってくれないかな！！

　mymy-mycompany分室さんのSQLインジェクション その２で、「DataAccess 」っていうクラスをつかって、ログインをチェックするお話がでてました。
　このお話、ログインをカプセル化しているわけですが、このログインのカプセル化は、ＳＱＬインジェクションの話だけでなく意味ある気がします。

　というのは、認証って、ユーザー名とパスワードだけで、なくなるような気がするんです。めんどーくさいじゃないですかあ！
　それに、ユーザー名、パスワードがわかれば、なりすましもできちゃうわけですし。。

　なんで、認証システムは、どんどん変わっていくかもしれないんで、そこだけ分離するのは、意味ありそう。

　で、そんな新たな認証システムとして、期待しちゃうのが、ケータイのFellica（＝おサイフケータイ）を利用する形！（本当は、たいして期待してないのだが、ある言葉を書きたいために、そうする。理由は最後に、わかる）

　Fellicaには、docomoに、いろいろ申し込まないと勝手には使えない、共通領域と、iアプリから、自由につかえ、仕様書がでている、フリー領域とあるようなんで、フリー領域を、使いましょう。

　Fellicaの技術仕様書は、ここ

---

　で、たとえば、社内で、認証をとって、ログインしたい場合、

（１）その会社で作った認証用iアプリをダウンロードしてきて、
　　　そのiアプリが、その人固有のIDを作成するわけ。

　　　そのIDは、
　　　　　その人を特定できる文字列
　　　　　　（この場合、社内での認証なんで、社員番号とか）
　　　　＋ダミーの適当に発生した文字何桁か
　　　としておく。

　　　たとえば、社員番号が9001で、
　　　　　　　　適当に発生した数字が2478901
　　　だったとしたら、

　　　その人のＩＤは、 90012478901

（２）認証するとき、アプリケーションは、
　　　　　ワンタイムの公開鍵と
　　　　　そのログインしてきた人の、固有ＩＤ中、
　　　　　　　　　何桁目をとってきて、それを何桁目におくかをおくる。
　　　　　（ここで、後々のために、その人を特定できる文字列は、必ず送る）

　　　上の例だと、9001は、必ず送る。
　　　　あと、今回、頭から６桁目の4と、
　　　　　　　　　　　　　８桁目の８を使い、
　　　　さらに、それをさかさまに、送ることにする。

　　　なんで、こういう指示になる

1-6
2-5
3-4
4-3
6-2
8-1

　　この文字列と、公開鍵をクライアント側（ログインするほう）に送る。

（３）ログインするクライアントのほうは、Felicaをつかう。
　　　ログインしたい人は、ケータイをかざすと、カードリーダで読み込んで、
　　　ＩＤを取得し(90012478901)、クライアントのほうで、
　　　　そのＩＤと、（２）の指示から、番号を組み立てて、(841009)
　　　　それを公開鍵で暗号化する。このへんはjavascriptを使ってやる
　　　（それとも、こういうアプリ書いたほうが早いか？）

（４）サーバー側に、（３）の結果が送られると、
　　そこから、秘密鍵で、組み立てた数字をとりだし（841009）、
　　自分が送った規則より、ＩＤを取り出し、(9001)、
　　のこりの数字で、正しく送られてきているかチェックする
　（この場合、４と８と正しく着ているか確認）

---

　こうすると、ワンタイムで、公開鍵を使って暗号化してるんで、解読されにくいし、毎回、サーバーに送信する数字が違うから、規則がわかっても、ぜーんぶ番号を知らない限り、なりすまして送るのもたいへん（もちろん、今回は短い数字で、規則も簡単だから、偶然見破られる可能性もあるけど、ほんとうは、もっと長くする）。

　自分は、ＩＤをしらないから（ケータイに入ってるＩＤは、表示しないものとする）、ほかの人には教えられない。ほかの人は、ケータイを奪って、解析しないとわかんない。

　で、おサイフケータイなんで、持ち運びもらく。

　あとは、fellica読み込み機が安いといいんだけどね。。。

　あ、もし、この方法、使いたい人がいたら、かってにどうぞ。

　ただ、思いつきで書いただけだから、どこか、特許とられてたりするところがあるかないかとか、そういうことやってる会社があるかないかとかは、一切調べてないので、そのつもりで（そのへんは、自己責任で）。

（実は、この部分は、まえふりだから。あとで、なんでこんな話をしてるのかの理由がわかる）

---

　で、これが、普及してくれると、なにがいいって、
　ウィリアムのいたずらみたいに、ケータイを持ってない人は、システムが使えない！
　それは、会社がこまる。

　っていうことで、会社がケータイをかって、くれるかもしんない！！

　それがいい

（って、そんだけのために、こんなこと、いってんのかい。　自分で買えよって！！）


　っていうわけで、

Docomoさん、
Fellicaを使った、汎用的なワンタイムパスワードの認証システムの
開発をしてください。

おねがいりんこのぷー

（って、言ってるんだよね。小倉優子って！ちがうかな。。。ちょっち自信ない。
　じつはきょうは、この言葉が書きたくて、ここまで無理やり引っ張った ^^;)