ガチでオンラインショップ構築ソフトを作ろうと思う
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2007/08/19(日) 22:33:55ID:???多言語対応。
高セキュリティ。
拡張機能・言語の追加は追加モジュールを入れるだけ。
柔軟なカスタマイズができる料金設定。
オンラインショップってのは、店によって結構細かい違いがでてくるものなんで
カスタマイズ性が必須だと思うんだけど、どうも既存のやつは制限が多すぎる。
自由に設定できないうえに、ソフト会社に頼むと高額な金額を要求される。
そんな人にぴったしなソフトにしたい。
ほかにほしい機能あったら頂戴。
とくに、今オンラインショップを運営しているが
こんな機能がなくて○○はいや！ってな人お願い。
たぶん、俺一人だと思いつかないから。
補足
osCommerce・ZenCartのクソ加減にはうんざりです。
0084nobodyさん
2007/09/03(月) 20:37:43ID:JW8Lz7yz辞退。
0086nobodyさん
2007/09/03(月) 21:16:15ID:???かいてくださーい。お願い。
様々な業種に対応できる設計にしたいから
いろんな情報がほしい。
マイナーな要望であればあるほどうれしい。
（その要望を必ず取り入れるわけじゃないので注意）
0087nobodyさん
2007/09/03(月) 21:21:08ID:???ベースは同じで、サイズや色の違いがあるものあるでしょ？
あれって、商品コード（JANとか）はそれぞれ違うものなんだよね？
だから特に何ってわけじゃないけど。
0088nobodyさん
2007/09/03(月) 21:24:07ID:???服とか買うとき、オプションでサイズを選べるとか
色を選べるとか、ジーンズのすそ上げするかとか、
オプションで値段が変わったり。
0091nobodyさん
2007/09/03(月) 22:50:39ID:yXs8wLPA0092nobodyさん
2007/09/03(月) 22:54:16ID:???0093nobodyさん
2007/09/03(月) 23:33:19ID:???>>1は作りそうもないのに、伸びてるよな。
って立てたのは俺だけどｗ
一応予定を言っておくと、11月ぐらいから本格的に開始かな。
今の仕事（同じようなもの作ってる）が終わって
経験つんでから別設計（拡張性・汎用性重視）で作る。
それまで、要望聞いて設計中。
>>91
了解。お勧め機能だね。そこらへんは単純なHTMLから
複雑なphpコードまで、ブロックというかガジェットというか
そういうパーツにして、好きなところにおけるような設計にするつもり。
0094nobodyさん
2007/09/04(火) 00:26:28ID:???アウトルックのスパムメール一括登録できない。
見たいな、なぜその機能がないんだ？みたいな事あっても
1の言うようにプラグイン誰かが作るところがソフトメーカー品よりある意味安心できるところだね。
鶏と卵の関係で
素の核のソフトがそれなりに使えないとプラグインを作る人も少なくなるだろうから、
1の優先順位選択のセンスにwktkする。
009594
2007/09/04(火) 00:30:48ID:???1の優先順位選択のセンスにwktkする。
↓
1の要望を取捨選択するセンスにwktkする。
0096nobodyさん
2007/09/04(火) 02:44:54ID:???EC-CUBEの3rdパーティ製テンプレートをダウソしてみたけど、何でファイルが500個以上あんのかとorz
0097nobodyさん
2007/09/04(火) 09:46:21ID:???0098nobodyさん
2007/09/04(火) 10:44:36ID:???好きなパーツをおけるようにすると、
どうしても外部のWebサービスをおこうとするよね？
それ自体は別にいいんだけど。
そういうことをするとセキュリティ上のリスクがある。
詳しく言うと、外部のWebサービス（JavaScript）を実行するため
そこが信頼できないサイトだとcoockieを奪われたりする。
ここを気をつけないといけないな。
httponlyを使ってcookieをJavaScriptから読み取れないようにする。
iframeをうまく使う。ログインページなどには外部のWebサービスなどを
入れられないようにする。うーん。他にあるだろうか？
0099nobodyさん
2007/09/04(火) 10:44:59ID:???0100nobodyさん
2007/09/04(火) 10:49:54ID:???フレームワークを使うとビュー（見た目）は分離されているので
それだけでもある程度は変更しやすい。CSSも使うし。
ただ、もう一段階上がほしいよね。
理想としては管理画面からデザインをGUIで変更したい。
CSSはデザインを変えやすいけど、やっぱり素人が使うものじゃない。
まあ大変だろうなぁ。
ファイルはなるべく少なくする方向で。格納場所は一箇所で。
俺も嫌いだよ。ごちゃごちゃ沢山あるのは。
ホームページビルダーとかで作ったHTMLを変換して使えるようにするのもありか？
0101nobodyさん
2007/09/04(火) 10:59:26ID:???出力する（X)HTMLがちゃんと考慮されており
classとかがきちんと設定されていれば、がらりと変えることは可能。
(X)HTMLがちゃんと考慮されていればCSSだけで、
1カラム、2カラム、3カラムのレイアウトに変えることも可能。
でもやっぱり限界あるよね。どうしても同じようなデザインになってしまう。
技術的な限界というか、汎用性のある(X)HTMLにしようとすると、
むしろ人間的に、うぎゃーってなってくる。
あー。それでも、デフォのXHTMLを用意して、(もちろんvalid)
CSSである程度は変えられるように作るけどね。
0102nobodyさん
2007/09/04(火) 16:23:57ID:???0103nobodyさん
2007/09/04(火) 23:59:00ID:???POSレジdata => PC data => web data => PC data 在庫管理autoなもの
tech.自慢なprogは、オンライン店舗運営者を選んでしまう。
敷居が低ければok
0104nobodyさん
2007/09/05(水) 00:57:53ID:???PC dataがなんのことかわからんが、
CSVでファイルアップロード＝> web data =>Web上で在庫管理 もしくはCSVファイルでダウンロード
なら考慮事項に入っている。
ただCSVファイルといっても、そこに含まれるデータは決まった形でないといけない（決まったフィールドがないといけない）
だからPOSレジのdataをそのまま使えることはないし、外部の在庫管理ソフトでそのまま使えたりはしない。
一度変換が必要になる。業界共通のデータ形式というものが存在しない（はず）のだからこればかりはどうしようもない。
有名なPOSレジや在庫管理ソフトなら、それ専用の取り込み・出力ツールやデータ形式変換ツールが作られ、
場合によっては付属するかもしれないけど、少なくとも俺は有名なPOSレジや在庫管理ソフトがあることを知らないな。
あったとしても、それが手に入れにくいもの、金がかかるものなら俺は作らない。俺以外の誰かが作る可能性はあるだろうけどね。
あと念のためにいっておくと、excelファイルを直接アップロードしたりには対応できないよ
（対応しないのではなく、対応することができない）
なぜならexcelファイルはデータ形式が柔軟すぎる上に、内部形式が非公開だから問題を起こさないようにするのがきわめて難しい。
phpでexcelファイルを読み書きするライブラリはあるがこれも完璧ではなく、特に日本語がはいっていたり、
セルを結合したりいろいろ変更していると不具合が発生する。まあexcelでCSVファイル扱えるから、問題ないと思うけど。
0105nobodyさん
2007/09/05(水) 01:20:48ID:???> tech.自慢なprogは、オンライン店舗運営者を選んでしまう。
どのソフトをさしてtech.自慢なprogといっているのか知らないけど、
tech.自慢なprog と オンライン店舗運営者を選んでしまう ことには
なんの関係もないよ。
tech.自慢をしているわけじゃないが、オンライン店舗運営者には、
オンライン店舗なりの最低限の知識は必要。
FTPに関する知識とかSSLに関する知識とかバックアップに関する知識とか
もし、その程度の最低限の知識も持たずに、このソフトは難しい。
tech.自慢しているだけだ。と思っているのならお帰りください。
0106nobodyさん
2007/09/05(水) 01:24:48ID:???少なくとも、使いやすいソフトというものは、tech.自慢なprog でないと実現不可能ですから。
0107nobodyさん
2007/09/05(水) 02:08:10ID:???0108nobodyさん
2007/09/05(水) 09:10:38ID:???0109nobodyさん
2007/09/05(水) 21:25:56ID:???SSL必須でいいかな？
0110nobodyさん
2007/09/05(水) 23:56:32ID:Agpiv4G60112nobodyさん
2007/09/06(木) 00:03:58ID:???いいんじゃね？
個人情報は暗号化されないといけないものだし、
SSLも使っていないショッピングサイトは失格。
0114nobodyさん
2007/09/07(金) 01:33:52ID:???・最近作り始めたくせにEUC。
・設計が古臭い。フレームワークが使われていない。
･ソースコードのSQL文がうざい。↓こんなコード嫌い。
// postgresqlとmysqlとで処理を分ける
if (DB_TYPE == "pgsql") {
$order_id = $objQuery->nextval("dtb_order","order_id");
}elseif (DB_TYPE == "mysql") {
$order_id = $objQuery->get_auto_increment("dtb_order");
}
・多言語対応さが感じられない（日本語メッセージ埋め込み。メールのヘッダにiso-2022-jpという文字を直書きなど）
・共有SSLに対応していない。
・JavaScript OFFで買えない。
・なんとなくソースコードに不吉なにおいを感じる。文字列連結いっぱいだし、
たとえば非表示商品（管理画面でのみ見れる）でも、urlにadmin=onをつけると見れちゃうわけだが良いのか？
でもまあ、全体的に物は良くできてるんじゃない?
これだけの機能を作るには相当時間かかるし、このままの仕様（＋少しソースコード修正）で
使えるという店なら、osCommerceやZenCartの代わりに使うというのはありでしょう。
でもやっぱり、一枚岩。いろんな機能が絡み合っていて、何か機能を追加、削除しようと思ったら
ソースコードに手を加えなければ行けない。これでは俺が求めるレベルの柔軟性は達成できないだろう。
0115nobodyさん
2007/09/07(金) 02:35:44ID:???あんなに文字列連結していると絶対入り込むんだ。
しかもJavaScript盛りだくさん。
ちょっと通報してくる。
0116nobodyさん
2007/09/07(金) 06:16:48ID:???SSL必須とか、気持ちは理解できるけど意味不明で、
ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
というか、SSL利用部分(追加機能)は積極的にモジュール化すべきじゃね？
納品先が決まってない場合の利用サイドでは、必ず、
「とりあえず動かす」という要求があるはずだし。
# ZenCartのインストーラを思い出してくれ
それ以前の開発ポリシの話題だが、要件定義をしっかりやって、
実現可能性に近似な言語とフレームワークを使うのがよさげ。
DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
サーバサイドMVCとクライアントサイドMVCは下手に混在させないで
別けて考えた方がいい。
0117nobodyさん
2007/09/07(金) 06:28:37ID:???未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
機能的クレーマの大半はコイツ等だったりする。
# Win98なんだけど、どおやったら良いの？
# ．．．みたいな、ダメっぽい前提をそもそも知っている顧客
こういう低レベルなリテラシしか持たないユーザに対し
どのような誘導策を考え、実現するか、が、
-互換性の無いJavaScriptを排除する
-SSLを必須としない(または、54bitSSL 対応、非SSL 許可)
という考え方に結びついている。
# 古いMacのIE5.2とか、普通に使うヤツの神経を想像してみてくれ
もちろん、対応OS、ブラウザを指定するのは重要だと思うが
アプリ機能の実現可能性とは直接的に関係が無い。
0118nobodyさん
2007/09/07(金) 09:21:39ID:???0119nobodyさん
2007/09/07(金) 09:35:23ID:GIU0vs1S0120nobodyさん
2007/09/07(金) 09:45:16ID:???いつのネタだよ。
すでに無視していい5%を切ってるよ。
0121nobodyさん
2007/09/07(金) 09:47:20ID:???開発プロセス？ なんのこと？開発なんてまだ行われてないけど？
> SSL必須とか、気持ちは理解できるけど意味不明で、
> ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
何ゆえ必要かって、それはお客さんの個人情報を守るためだよ。
> 納品先が決まってない場合の利用サイドでは、必ず、
> 「とりあえず動かす」という要求があるはずだし。
冗談はやめてくれ。どんな納品先であれ、”会員機能など個人情報を受け取る場合は”
通信内容の暗号化は必須だろ。「とりあえず動かす」なんて素人のシステムだよ。
> DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
BOMってなんだ？爆弾か？ それはさておき、
それこそ「ナニゆえ必要か明確でない機能」であり
積極的にモジュール化すべき部分だろ？ 言っていることが矛盾してるぞ。
> SSLとJavaScriptの考え方だが、
> 未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
> 機能的クレーマの大半はコイツ等だったりする。
JavaScriptは使わないほうが、より多くの人に対応できるんだが？
SSLに関しては、古いブラウザでも対応しているわけで、必須だからといって、
Win95/98ユーザが見れないことにはならない。他のシステムだが、IE5.01でもテスト済み。
オンラインショッピングで一番重要なこと。
それは運営者の都合や無知のために、脆弱なシステムで運営することじゃないのか？
一番重視するのは顧客の安全、個人情報を守ることじゃないのか？
運営者が無知なのは、まあ仕方がない。だからこそ安全側に倒したシステムであるべき。
そうは思いませんか？
どうしても納得がいかないのなら、オープンソースなので、
勝手に危険なシステムにダウングレードしてください。
0122nobodyさん
2007/09/07(金) 09:49:52ID:???そこは俺が知らなかった。すまん。
0123nobodyさん
2007/09/07(金) 10:27:18ID:???0124nobodyさん
2007/09/07(金) 13:03:06ID:???「SSL？それなんのこと？難しいことわかんない。
とりあえず売れればいい。」なのだろうが、
そんな客のことを考えないやつが、ネットショップなんてやるなと言いたい。
0125nobodyさん
2007/09/07(金) 15:06:25ID:cHWHRlBi0126nobodyさん
2007/09/07(金) 22:19:03ID:???0127nobodyさん
2007/09/07(金) 22:58:38ID:???0128nobodyさん
2007/09/07(金) 23:13:53ID:???うん。当たり前。
まあ、ウェブサイト全体をSSLする、つまりhttpsにで始まるURLしか
存在しないのなら話は別だが、Amazonとか見ればわかるように普通はあまりしない。
SSLはサーバーの負荷が高いからね。重いサイトになってしまう。
ついでにいうと、ウェブサイト全体をSSLにするを選んだ場合、共有SSLだとせっかくドメインとっても
全部が https://レンタルサーバーのドメイン/自分のドメイン/ ってなるから悲しいぞｗ
さらに技術的な話になるが、共有SSLだとドメインが違うため、別サイトと認識されセキュリティ上の理由で
cookieを渡せないためセッション（同一人物であるか）を保つのに一工夫しないといけない。
でないとカートに商品を入れていって、いざ住所などを入力する共有SSL画面になるとカートが空になっちゃう。
0129nobodyさん
2007/09/07(金) 23:21:08ID:???よくわからんが、SSL対応のページと非対応のページのURLを
初回セットアップの時にDBに登録して、
決済が入る部分はそのURLを参照する、のは駄目なのか？
俺は普段そうしているけど。もっと考えなきゃいかん話しなのか？
0130nobodyさん
2007/09/07(金) 23:26:11ID:???共有SSLでなく、独自SSLの場合で、httpとhttpsが混在する場合、
Amazonなどの大手が使っている方法。
これは対応するのは、比較的簡単なんだが、
それでも、httpでのアクセスで送ってもいいcookie、
httpsでのアクセスでしか送ってはいけないcookieにように
ちゃんと考慮して作らないといけない。
いずれにしろ、難易度の大小はあれ、ソフト開発者が
考慮しないといけないということ。
ちなみにhttpとhttpsが混ざるサイトでの共有SSL対応は一番難易度が高いです。
0131nobodyさん
2007/09/07(金) 23:29:29ID:???そりゃ、設置する人はそれだけでいいいけど、
それだけでいいように作るのは大変なんだぞ。
車走らすのには、アクセル踏めばいいだけだが、
アクセルを踏んだら車が走るような
仕組みを作るのが難しいのと同じで。
ここはWebProg板。作る人たちの板ですので。
0133nobodyさん
2007/09/07(金) 23:41:12ID:???あんたの意見は、公開されている
スクリプトをダウンロードして
サーバーにアップロードして
簡単な設定をしてインストールしているだけだ。
それ以外のなにをやったことがある？
0134nobodyさん
2007/09/07(金) 23:53:30ID:???あんた、何が言いたいか良くわからんのだが、
SSLに対応させるべきか否かというのが論点だろ？
で、俺は>>129みたいにすればどうだ？っと答えたわけだ。
それに対してソースをみてダウンロードしたとかどうとか言ってるが、
そういう問題なのか？ていうか、オープンソースのシステム作るのに、
今まで誰もやったことのない方法でシステムを組むべきなのか？
0135nobodyさん
2007/09/08(土) 00:02:05ID:???そりゃそうだろうねぇ。内部の仕組みを何もわかってないでしょ？
>>129みたいにするって意味不明なんだが。
お前、ユーザーがSSLのアドレスを設定すれば
それだけで、勝手にSSL対応が完成すると思ってるだろ？
0136nobodyさん
2007/09/08(土) 00:07:00ID:???もしかして、あんたの言うのは「サーバのSSL機能を使いましょう」
ではなく、「システム側でSSLの機能を持ちましょう」
と言うことか？俺は前者だと思ってたんだが、後者なら読み違えた。悪かった。
0137nobodyさん
2007/09/08(土) 00:23:18ID:???つかれるやつだな。本来なら話ができる最低レベルの知識に
達していないから出てくるなといいたいところなんだがな
> 「サーバのSSL機能を使いましょう」
そういう意味だよ。
HTTP（HTTPS含む)というのはセッションステートレスなの。
つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。
サーバーから見れば、誰かがカートに商品を入れた。誰かがカートを見た。
ということしかわからない。カートを見たのがAさんなのかBさんなのかわからない。
それを区別するために（他にもあるが通常は）クッキーを使う。
最初にサイトにアクセスしたときにセッションID（管理番号）を発行する。
その管理番号によってカートを見たのがAさんなのかBさんなのか区別している。
逆に言えば管理番号が奪われてしまえば他の人になり済ませてしまう。
そのためにSSLを使う。SSL使った場合、通信内容が暗号化されるから、
通信を傍受しても管理番号はわからない。
しかし、Amazonがそうであるように、常にSSLを使っているわけではない。
SSLを使わない状態でカートに商品を入れている。SSLを使わない以上管理番号が傍受される。
はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？
あなたがプログラマならここからが、あなたの仕事です。やってください。
0138nobodyさん
2007/09/08(土) 01:27:18ID:WjS/rI4a開発途中でいくらでも変更可能だし
0139nobodyさん
2007/09/08(土) 01:28:59ID:???0140nobodyさん
2007/09/08(土) 02:39:26ID:???>つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。
ホスト名かIPアドレスを保存するのは？
>>はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？
お前はSSLは「サーバの機能を使う」っと答えたよな？
じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？
また、管理番号の件だが、ログイン毎に新しいセッションIDを発行すれば？
Amazonの例ならログインするのはメルアドとパスワードが必要だ。
その時にアクセス用のセッションIDを発行する。
顧客情報にはセッションIDを保存し、そこから顧客情報を参照する。
当然ログアウト後はセッションIDが消えるから、例えセッションIDが
盗まれたとしても、他人がそれだけでログインすることは出来ない。
0141nobodyさん
2007/09/08(土) 02:56:14ID:???ﾎﾟｶｰﾝ。
むしろ、それではだめな理由を二つ以上答えなさいのネタだろｗ
0142nobodyさん
2007/09/08(土) 02:58:59ID:???がんばって調べてきたんだろうなぁ。
> お前はSSLは「サーバの機能を使う」っと答えたよな？
> じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？
まーた、的外れなことを言う。Amazon見たか？
SSLを使うページと使わないページがあるんだよ。
客が使わないんじゃない。システム的に使わないページがあるの。
0143nobodyさん
2007/09/08(土) 03:02:15ID:???はいそうだね。それじゃ次いこうか？
ログインした。新しいセッションIDを発行した。
その後で別の商品をカートに入れるために、
ログアウトせずに、非SSLページに移動した場合どうするか。
カートに入れる処理は、非SSLページという設計なのだから、
当然それは傍受される。
プログラマってのはね、君が考えているよりも多くのことを考えているんだよ。
つぎの、あなたの仕事です。
0144nobodyさん
2007/09/08(土) 03:03:20ID:???↓
当然新しいセッションIDは傍受される。
0145nobodyさん
2007/09/08(土) 03:03:25ID:???駄目な理由。
みんな固定IPじゃないから。必ずしも同じPCからアクセスするわけじゃないから。
>>142
Amazonみてねぇよ。調べてねぇし。
てかな、俺が知識不足なのは認める。お前の方が偉いわ。
でもな、そこまでSSLにこだわる必要あるのか？ってのがいいたいわけ。
突っ込んでるのも俺だけじゃないだろ。
0146nobodyさん
2007/09/08(土) 03:05:32ID:???特定時間を過ぎると、保持されているセッションIDが有効とならない方法もあるね。
で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？
あんたみたいなプログラマ様が余計な機能付けるお陰で
コストや手間が増えまくるって予測できないかな？？？
0147nobodyさん
2007/09/08(土) 03:06:04ID:???こだわらないという考えもいい。
ただし、それはSSLをちゃんとわかっている人だけが言うことを許されるセリフだ。
知らないやつが言って良いセリフではない。
0148nobodyさん
2007/09/08(土) 03:07:47ID:???> で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？
それは、SSLを全否定していることにつながっているわけだが
わかっているか？
> あんたみたいなプログラマ様が余計な機能付けるお陰で
> コストや手間が増えまくるって予測できないかな？？？
客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？
0149nobodyさん
2007/09/08(土) 03:08:51ID:???>知らないやつが言って良いセリフではない。
うんそうだね。じゃ、オープンソース使いたい奴、ひいては利用ユーザは
君ぐらいSSLに長けている人間なのかな？？
他のレスでもあったけど、「別にSSLなんて関係ないぜ」みたいに
思っている奴の方が多いだろ。あんたは単に自己を押しつけてるだけ。
高い金出してベリサインと契約して、そんなに効果あるとはおもえん。
0150nobodyさん
2007/09/08(土) 03:10:00ID:???全否定はしないが、疑問視はしてるな。
>客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？
コストをかけるのは俺ではなく、カート設置者だろ？
設置者がいらないと思えばいらないだろ。
0151nobodyさん
2007/09/08(土) 03:12:40ID:???> 君ぐらいSSLに長けている人間なのかな？？
なにが言いたいのかわからん。まあ、SSLに長けている人間ではないだろうな。
SSLに長けている人間ではないから、○○○←ここにどういうセリフを入れるつもりだ？
> 高い金出してベリサインと契約して、そんなに効果あるとはおもえん。
安い共有SSLでいいだろ。
0152nobodyさん
2007/09/08(土) 03:14:06ID:???あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。
実際に会社で客と打ち合わせする奴らならわかるだろ。
SSLなんて大抵疑問視されてるよ。どんだけ必要性を説いてもな。
それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
どうせSSL付けても流出する時はする。大手を見てみろ。
ま、SSLにこだわればいいさ。SSLを導入してないと
使えないぐらいなシステムにすればいい。そんなの誰も使わないだろうけどな。
0153nobodyさん
2007/09/08(土) 03:16:17ID:???> コストをかけるのは俺ではなく、カート設置者だろ？
> 設置者がいらないと思えばいらないだろ。
つまり、客の安全よりも、店の利益。
それも、年、たった数千円程度を優先するといいたいのだな？
0154nobodyさん
2007/09/08(土) 03:17:21ID:???> あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
> もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。
あんたは、オンラインショップを運営するのなら、
そこで買う客のことを考えたほうが良い。
0155nobodyさん
2007/09/08(土) 03:20:35ID:???SSLが疑問視されているというのなら、
その証拠を挙げてもらいたい。
SSLをつけていても流出するという理屈は、
それは、シートベルトをつけていても交通事故を起こすといっているのと同じ
それでシートベルトはするべきじゃないという理由にはならんだろ。
つまりへ理屈だ。
> それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
それはSSLを理解していないからだ。
0156nobodyさん
2007/09/08(土) 03:27:28ID:???あなたの欲しい新機能は？？
1位 14 % (167)
共有SSL対応
SSLが大概疑問視されているとは、よっぽど小さい所ばっかり相手にしているんだなｗ
しかも、必要な理由を理解させることもできない。まあ自分が理解していないんじゃしょうがないかｗ
SSLを利用していないことで、客が逃げていき、結果的に損をしているということが
わからないんだろうな。
0157nobodyさん
2007/09/08(土) 06:31:53ID:???実際SSL導入してなくて事故ったっていう事例が少ない（ない？）からだと思うが、
起きてからじゃ遅いって事が何故わからんのか。
SSL利用しないでオンラインショップの経営なんて
自動車保険に入らないで運転してるヤツとなんら変わらん。非常識そのものだ。
0158nobodyさん
2007/09/08(土) 11:08:07ID:???公開カギ使ってんだろうな？
0159nobodyさん
2007/09/08(土) 11:50:58ID:???メールに関しては別件であり、いま語る内容ではない。
論点をずらそうとしているな。
それとも、ショップを利用するお客様の個人情報を守るための
ショッピングシステムの設計について語りたいのかな？
それならそれで意見を言おう。
基本的にメールで個人情報は送らない。
メールで送るのは「注文された商品を発送しました」など
（具体的な内容は店のポリシーによる）
そして、メールのに詳細を確認するにはコチラをクリックしてください。
とかき、当然その先はSSLで暗号化された顧客情報ページ。
0160nobodyさん
2007/09/08(土) 16:12:26ID:WjS/rI4a//define("SSL_URL","https://hoge.com/";);
みたいな感じでどっちでもOKにしておけば問題ないんだよ。
もっと柔軟になれよ。
セッションはsession_regenerate_idやっておけば、完ぺきではないが
危険性は減る。それでもうだうだ言うやつは自分で作ればいいじゃない。
0163nobodyさん
2007/09/08(土) 18:06:23ID:???サーバーの運営者の間でも同じだろ。
メールで（客の）個人情報を送受信しない。
個人情報を扱うときはブラウザからやればいい。
っていうか、サーバーと運営者の間に
メールなんてつかわないでいいだろ。
注文が入ったって知らせてほしいのなら
メールの内容は「注文が入りました」だけでOK
0164nobodyさん
2007/09/08(土) 18:21:49ID:???どんなソフトでもSSLの対応が完了するって考えてるんだろ？ｗ
ところでSSL_URLでググるとEC CUBEばっかりでてくるなｗ
0165nobodyさん
2007/09/08(土) 18:30:13ID:WjS/rI4a処理？HTTPもHTTPSも処理は同じだろうが。
>>164
実際問題そうだろ。HTTPSに渡せばSSLじゃん。
0166nobodyさん
2007/09/08(土) 18:46:08ID:???お前ダメダメじゃん。
>>137でも読んでから出直してくれ。
ヒントをあげると、確かにhttpsページにアクセスすれば
そのページに限っては暗号化される。
しかし、多くのオンラインショップでは、ある理由により
カートに入れるときはhttp、決済の時はhttpsと使い分けている。
カートに入れるときと決済時のセッションIDは同じでないと
同一人物であると区別できない。
セッションIDが漏れると大変なことになる。
カートに入れるときと決済時のセッションIDは同じと言うことは
決済時には漏洩の心配が無くても、カートに入れるときに漏れる。
ここまでいえばわかるよな？
0167nobodyさん
2007/09/08(土) 19:02:13ID:???ショッピングカートCGIレベルの話してるんじゃねーの？
顧客情報を入力したらメールで運営者のところに送られてくるだけ。
そう考えれば、メールの話を持ち出してきていることも説明がつく。
想定している規模がぜんぜん違うから話がかみ合わないわなｗ
0168nobodyさん
2007/09/08(土) 20:40:06ID:WjS/rI4aおまえこそ、大丈夫か？
session_regenerate_id()で再生成も引き継ぎも可能なんだぜ。
PHPのセッションについて10回読んで顔洗って出直してこいよ。
くそむし。
0169nobodyさん
2007/09/08(土) 20:53:23ID:???で、お前、それを使った、サンプルコードかけるの？
当然、どのタイミングで、session_regenerate_id()を
実行するのかぐらいは答えられるよね？
0170nobodyさん
2007/09/08(土) 21:04:06ID:WjS/rI4aサンプルコードってｗ 1行だろうがｗ 頭悪すぎｗｗｗｗ
カート操作の度に再生成と破棄をしておけばいいんだよ。クズ.
HTTPSになってからは念のため、入力操作(POST)があった後、再生成しておけ。
これでカートを乗っ取る荒業できる奴なんてほとんどいないよ。
0171nobodyさん
2007/09/08(土) 21:04:36ID:???共有SSLの場合は、
https://www.example.com/ と
https://dokokano.server/~example.com/ という風にドメインが違うから
https://www.example.com/ で使っていたセッションIDは
https://dokokano.server/~example.com/ のページに飛んでも、
送られてきません。
そのため、session_regenerate_id()で再作成すればいいという
レベルの話じゃすみません。
知っていましたか？
0173nobodyさん
2007/09/08(土) 21:07:45ID:WjS/rI4aバカじゃないの。
おまえは1回もセッションIDを付加させちゃいけないとでも思ってるのか？
生き方反省しろ。
0174nobodyさん
2007/09/08(土) 21:08:22ID:???頭が悪いのはあんたですね。
毎回発行するのなら、
httpのセッションIDを奪った人が、本人よりも早く
httpsページに入るだけで、簡単に個人情報奪えますね。
それともhttpsに入るたびに毎回パスワードを要求するように
するつもりですか？ カートと決済ページを行き来するたびに
パスワード。使いにくいショッピングサイトですねｗ
それからPOSTにしようが何の関係もありません。
0175nobodyさん
2007/09/08(土) 21:11:01ID:???session_regenerate_id()の一行を発行するだけと貴方は言いました。
ドメインが違うと、セッションIDが送られてこないのに、
session_regenerate_id()の一行だけでどうやって対処するつもりですか？
> define("SSL_URL","http://hoge.com/";);
最初は、これだけやればいいといっていたわりに、
どんどんコードが複雑になりそうですねｗ
0176nobodyさん
2007/09/08(土) 21:14:45ID:???↑これは↓これの間違い。
http://www.example.com/
多分わかって無いだろうから説明しとく。
http://www.example.com/ でカートに入れる。
ここでセッションID 0001（本当はランダムな長い文字列）が発行される。
その後で、 https://dokokano.server/~example.com/ にくる。
ここで新たにセッションID 0002を発行しても、
セッションID、0001と0002ではIDが違うので、
0001のときにカートに入れた商品はなくなっている。
0177nobodyさん
2007/09/08(土) 21:23:19ID:S9yl+KSCsslに入るときはPOST。
認証はsslに入った後に行なう。
0178nobodyさん
2007/09/08(土) 21:25:23ID:???SSL_URLだって、session_regenerate_id()だって、
セキュリティを保つための一連のコードの中で使う一行でしか過ぎないんだよ。
0180nobodyさん
2007/09/08(土) 21:37:43ID:WjS/rI4aオナニーばっかでコードも書けない屑ばかりじゃねぇかｗ
共用SSLだろうが、セッションID付加させれば問題ないんだよ。
0181nobodyさん
2007/09/08(土) 22:45:01ID:???ttp://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
ttp://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp06/entwebapp06_05.html
0182nobodyさん
2007/09/08(土) 23:01:14ID:???そんな大量の資料出したら、
SSLのアドレスを設定するだけ
session_regenerate_id()実行すればいいだけと
言っていたやつが泣く
■ このスレッドは過去ログ倉庫に格納されています