ガチでオンラインショップ構築ソフトを作ろうと思う

**nobodyさん** · 2007/08/19(日) 22:33:55

もちオプソで。

多言語対応。
高セキュリティ。
拡張機能・言語の追加は追加モジュールを入れるだけ。
柔軟なカスタマイズができる料金設定。

オンラインショップってのは、店によって結構細かい違いがでてくるものなんで
カスタマイズ性が必須だと思うんだけど、どうも既存のやつは制限が多すぎる。
自由に設定できないうえに、ソフト会社に頼むと高額な金額を要求される。
そんな人にぴったしなソフトにしたい。

ほかにほしい機能あったら頂戴。
とくに、今オンラインショップを運営しているが
こんな機能がなくて○○はいや！ってな人お願い。
たぶん、俺一人だと思いつかないから。

補足
osCommerce・ZenCartのクソ加減にはうんざりです。

**nobodyさん** · 2007/08/19(日) 22:44:48

適当にアイデアを並べていく。

・柔軟な商品タイプの設定

商品タイプとはZenCartにあるやつ。
たとえば、本という商品タイプには属性としてISBNがある。など。

そういうのを「運営者が」（←重要なところ）自由に作成・変更できる。

ZenCartの場合、いちいちテーブル定義して
それに入れたり表示したりとプログラムを変更しないといけない。

**nobodyさん** · 2007/08/19(日) 22:47:33

　終　了

**nobodyさん** · 2007/08/19(日) 22:48:37

・値段がないもの、値段固定ができる

無料商品、固定価格商品対応。

スーパーの肉・魚みたいに、この商品は3個買った1000円になる

**nobodyさん** · 2007/08/19(日) 22:52:24

会員・期間・時間の条件の違いで複数の価格設定ができる。

柔軟なページ修正、特定の商品のページだけ
WYSYWIGエディタで修正することが可能。
特定の商品に限り、はでなPOPを入れるなど。

**nobodyさん** · 2007/08/20(月) 01:57:12

こういう類の物はカスタマイズだけでどうこうできないんだよ。
ある程度の大枠フレームワークは作ることができるかもしれないけどね。
大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ？
あきらめな。

**nobodyさん** · 2007/08/20(月) 03:59:41

> こういう類の物はカスタマイズだけでどうこうできないんだよ。
その理由は？

> 大体、業種によってDBのテーブルがまったく異なるのをどうやって吸収するのよ？
DBのテーブルがまったく違うのなら
拡張モジュールで変えれば良いだけの話だろ。
DBのテーブルってプログラムから変更することができるんだぜ？
まさか、知らなかったのか？ｗ

**nobodyさん** · 2007/08/20(月) 08:05:07

ようは自分がほしいものを作ってくれスレだべ

**nobodyさん** · 2007/08/20(月) 11:37:36

>>8
いいえ。貴方が欲しい機能を書けば私が作ります。

**nobodyさん** · 2007/08/20(月) 11:46:22

アイデアぱくっておれすげ～～って言いたいだけの小僧ですか

**nobodyさん** · 2007/08/20(月) 12:08:13

本気でOSSでやりたいというなら
プロトタイプをSourceForgeなりGoogleCodeHostingなりで公開すればいい
それすらやらないようでは到底無理

**nobodyさん** · 2007/08/20(月) 14:03:33

>>10
俺すげーとは言わないので、アイデア下さい。
アイデアというか要望。

**nobodyさん** · 2007/08/20(月) 15:41:14

携帯サイトとPCサイトの商品DB連動
佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
詳細写真の枚数、自由指定
アフィリエイト機能
特別に作ったHTMLページも利用可能に

３０万くらいで作って
zencartの改造でもいい

**nobodyさん** · 2007/08/20(月) 15:41:42

>>1が考えているテーブル設計はどんな感じなの？

**nobodyさん** · 2007/08/20(月) 17:34:45

＞携帯サイトとPCサイトの商品DB連動

連動させない作りのほうがキモいだろ．．．。

**nobodyさん** · 2007/08/20(月) 19:02:06

MVCで作ってれば携帯とPCは両方対応できるな。

**nobodyさん** · 2007/08/20(月) 19:08:32

またk.k.プロジェクツか！
とりあえず>>1はコテつけろ

**nobodyさん** · 2007/08/20(月) 23:34:22

>>14
商品タイプの部分はクラステーブル継承がいいかなと思っている。
でもJOINの負荷を考えると具象テーブル継承も捨てがたいかなと思っている。

具象テーブル継承だとデータが重複して保存されるから運用時に
商品タイプをいじると大規模なデータ変更（あるテーブルからあるテーブルに
大量にデータコピー）が起こりそうだなぁ。

基本の商品データは商品コードと型情報のみ。（タイトルぐらいあってもいいか？）
そのほかの項目はすべてモジュールで定義。
なんと価格すらもオプション。必須項目ではないのだ。
（だって100円ショップみたいに価格固定だと価格項目は必要ない）

**nobodyさん** · 2007/08/20(月) 23:38:42

> 詳細写真の枚数、自由指定

OK OK
ついでに縮小サイズとか自動で作成。キャッシュあり。
携帯の場合もそれぞれにあわせた形式で。

**nobodyさん** · 2007/08/20(月) 23:41:20

共有SSLのURL対応
（共有SSLのURLとはhttps://レンタルサーバー/独自ドメイン/的なやつのこと）

**nobodyさん** · 2007/08/21(火) 01:38:21

image(
id,
item_id,
path,
file_name,
type,
alt,
del_flg
)

**nobodyさん** · 2007/08/22(水) 03:37:16

>>17
恥を知りなさい
>>1
きっと買収します

**nobodyさん** · 2007/08/22(水) 10:54:37

無理無理。
何でもかんでも構築ソフト任せだと顧客が痛い目見るってことで実用性はない。

**nobodyさん** · 2007/08/22(水) 11:13:29

ｋｋぷろじぇくそと同じ道を歩むスレとなったか

**nobodyさん** · 2007/08/22(水) 11:52:06

kk-projectsに憧れます

1 ◆oBaAHYinW2 · 2007/08/22(水) 12:56:44

コテつけるからアイデアかもんべいび～

**nobodyさん** · 2007/08/22(水) 13:11:06

>>23
根拠はあるの？そうなった実例。

**nobodyさん** · 2007/08/22(水) 15:45:43

>>27
多分>>23は市販のWebショップ作成ソフトかosCommerceあたりのWebアプリケーションで
痛い目に遭っただけちゃうか

**nobodyさん** · 2007/08/22(水) 16:06:32

あれもこれもと入れ込むよりは、アドインできる仕様にしてAPIを公開
するってのが今時の流れじゃないのか？

**nobodyさん** · 2007/08/22(水) 19:42:45

>>29
ですよね。コアはなるべくシンプルに！

で、話は変わりますけど、まあある程度の機能
（たとえばヤマト送り状CSV作成機能）は
アドインでプログラマが作ったプログラムを組み込むのは
仕方ないと思います。

でも商品の項目程度はプログラミング知識の無い運営者でも
管理画面から変更できたほうがいいと思うのです。
こういう場合どういう設計にしましょう？

１．データベーススキーマを動的に変更。
設計としてはシンプルだが、項目の追加・削除とかで問題でそう？
SQLのALTERにはRDBMSごろと制限がいろいろ。

２．商品項目テーブルを作る。
|商品コード|項目名|値|
|1 | タイトル | なんとか|
|1 | ISBN | 4798105538|
|1 | 価格 | 5800|
自由に項目を追加・削除できるが、パフォーマンス（特に検索時）悪そう。

３．商品項目ごとにテーブルを作る。
ISBNテーブル
|商品コード|値|
|1 | 4798105538|
検索自体は早くなるかもしれないが、
JOIN多すぎでパフォーマンス低下＆JOINの数制限に引っかかる。

どれもしっくりきません。

**nobodyさん** · 2007/08/23(木) 08:30:06

後で追加するようなもんは
そんなにモリモリ検索しないだろうから
辞書にでもしてシリアライズしてテキストにして、つっこんでおけば。

**nobodyさん** · 2007/08/23(木) 09:57:27

そもそもDBが本当に必要なほどの商品数があって、売り上げも上がるところなら
作ってもらってる。
楽天をみてもわかるがほとんどのところは商品100個以下。

**nobodyさん** · 2007/08/23(木) 10:18:09

>>32
本当にそうだろうか？

DBが本当に必要なほど商品数がある場合は
楽天とか使えずに、また既存のオンラインショップシステムじゃ
重かったり、使い勝手が悪かったりで、仕方なく作るしかない。
が正解では無いだろうか？

13 · 2007/08/23(木) 14:57:20

だれかzencartの改造３０万くらいでやらない？

**nobodyさん** · 2007/08/23(木) 15:26:48

>>34
安すぎ。学生にでもやらせればいいんじゃね？

**nobodyさん** · 2007/08/23(木) 15:43:54

じゃあ、やってくれる学生いませんかー？

**nobodyさん** · 2007/08/23(木) 16:13:27

>>34-36
どんなビンボー学生でも割に合う仕事と割に合わん仕事ぐらい見分けがつくだろ。

**nobodyさん** · 2007/08/23(木) 16:26:41

20万以下でやってくれるだろｗ

**nobodyさん** · 2007/08/23(木) 17:01:36

>>13

＞携帯サイトとPCサイトの商品DB連動
Zencart用だったらシェアウェアで出てる

＞佐川、ヤマト用、送り状作成ソフトにインポートできるCSV作成
エクスポートとインポートの区別つけてよ

＞詳細写真の枚数、自由指定
Zencartでも3枚ぐらい貼れる　それで足らんかったらHTMLで書く
wysiwigエディタで画像URL指定で貼れるはず

＞アフィリエイト機能
要るか？ホントに勝てる商品ならA8とかに出したほうが良さげ
っていうかコレもシェアウェアで有る＞Zencart用モジュール

＞特別に作ったHTMLページも利用可能に
Zencartの1.3x系なら追加ページ書けたはず
それで足らんかったらXOOPSモジュール化されたZOXもある

＞３０万くらいで作って

**nobodyさん** · 2007/08/23(木) 17:56:21

とある会社はECと物流のデータ連動できるサイト構築で
イニシャル1900万
ランニング60万とるらしいが高いね

**nobodyさん** · 2007/08/23(木) 20:50:32

言語的にはPHPとMySQLで十分だな。楽天もそうみたいだし。

>>1
テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
考えるが、デザイン面も考えないと、ユーザは食いつかない。

**nobodyさん** · 2007/08/24(金) 00:48:28

>>41
> テンプレート編集機能もいるだろ。プログラマーはプログラムの部分ばかり
> 考えるが、デザイン面も考えないと、ユーザは食いつかない。
一応これ↓に含めていたつもり・・・(´；ω；｀)ﾌﾞﾜｯ

> 5 名前：nobodyさん[sage] 投稿日：2007/08/19(日) 22:52:24 ID:???
> 柔軟なページ修正、特定の商品のページだけ
^^^^^^^^^^^^^

そういや前々から思っているんだけど、WYSYWIGエディタはあるけど、
CSSまで含めてWYSYWIGで修正できるものってないよな・・・？
俺としてはテンプレートをWYSYWIGで修正したい！（どうやって！？）

**nobodyさん** · 2007/08/24(金) 00:57:11

CMS的な機能もいるよな。

オンラインショップのトップにきたら
決まったように、最近入ってきた商品とか
売れ筋の商品とか適当に表示。

それはそれで考えなくて良いから、便利な点もあるんだけど、
今月の○○特集とか派手なPOPをおいて、
さらに詳細な記事（コンテンツ）書いて、
そして商品の販売につなげるとかやりたいじゃん？

好きなページを作れるのはもとより、好きなブロックを作って
いろんな場所に埋め込める必要があるよな。

ついでに期間限定機能つきで。

**nobodyさん** · 2007/08/24(金) 10:32:55

http://xoops.ec-cube.net/modules/xoopspoll/pollresults.php?poll_id=2
あひゃ。要望ぱくりｗ

1位 12 % (135)
共有SSL対応
2位 12 % (127)
ダウンロード商品販売機能
3位 10 % (112)
納品書発行
4位 9 % (97)
ポイントシステムをON・OFF可能に
5位 7 % (81)
クーポン券を発行機能
6位 4 % (43)
合計金額に応じた代引手数料
7位 3 % (38)
ギフト対応
8位 3 % (35)
クレジットカード決済機能
9位 3 % (35)
アフィリエイト機能(1～3段階ティアコミッション)
10位 2 % (31)
非会員購入の顧客管理機能

共有SSLって要望高いんだな

**nobodyさん** · 2007/08/24(金) 22:51:32

デザイン面はどのレベルまで持って行けるんだ？
XOOPS以上の見た目は必要だぞ。

**nobodyさん** · 2007/08/25(土) 03:16:11

ズープスは最低クラスだな。
ワードプレスくらい自由度あるといい

**nobodyさん** · 2007/08/25(土) 07:32:05

>>45
さすがに最低限の機能としてテンプレートは使うので
テンプレート言語かできる程度の知識があれば自由自在。

フレームワークを使うので、必然的にそうなるわけだけど。

最終的には、Ajaxを使って自由にブロックを配置、移動させたいねぇ。

**nobodyさん** · 2007/08/25(土) 07:37:50

ところで格安共有サーバーで動かすことを考えるとPHPが一番？

suEXECがあるからセキュリティ的にPerlも気になってはいるんだけど、
あんまり流行っていない気がする。
それにPerl用のフレームワークって実質的にCPAN必須な感じだし。
（CPANは共有サーバーで使えないことも多い）

PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
CodeIgniterやAkelosも気になっている。
どれもPHP4でも動いて、PEAR必須じゃないよね？
(PEARも共有サーバーで使えないことがある。手動で入れるのも不可能ではないが
場合によってはかなり面倒なことがあるのでなるべく使わないようにしたい）

**nobodyさん** · 2007/08/25(土) 12:23:33

>PHPを使うとしたら、CakePHPが今のところ一番勢いがあるだろうか。
そうなの？ソースとかある？

**nobodyさん** · 2007/08/25(土) 13:34:54

テンプレートエンジンはSmartyな。

**nobodyさん** · 2007/08/25(土) 15:42:00

>>50
別にかまわない。というか、
拡張モジュールでテンプレートエンジン切り替えられるようにするけど、
個人的には、PHPそのままでもシンプルな状態なら
テンプレートと本質的には変わらないと思っている。

<h1>{$text}</h1>

<h1><?php echo $text; ?></h1>

多少長くなる程度。
問題はビューの部分で複雑なコードを書くのが悪いのであって。

**nobodyさん** · 2007/08/25(土) 18:38:05

>>51
Smartyのページキャッシュ使ってDBの接続コスト
減らせばいいんだよ。
どうせ、PEAR使うといろいろと面倒だろ？

**nobodyさん** · 2007/08/25(土) 20:06:06

KKprojectsも応援しています。

**nobodyさん** · 2007/08/25(土) 21:40:45

SmartyとかPEARとか使ったら、拡張性悪くなるんじゃないか？
>>1はオープンソースとして作りたい分けなんだから、
後からユーザが改造出来る形が良いだろ。

と言うわけで、純粋なPHPのコードだけでいいと思う。

**nobodyさん** · 2007/08/25(土) 23:02:31

KKprojectsもそう思います。

**nobodyさん** · 2007/08/26(日) 10:01:46

PEARはもう十分に普及してますよ。

**nobodyさん** · 2007/08/26(日) 19:21:31

このスレはご覧のスポンサーがお送りしております

提供：K.K.projects

**nobodyさん** · 2007/08/26(日) 19:28:08

>>56
いや、普及しているかどうかというより、
PEARのパッケージマネージャを
入れるにはシェルが必要でしょ？

と書いておきながら、go-pear.phpを
入れて普通に動いているような気もするんだけど・・・。
それでも、微妙に不安定な感じもする。よくわからない。

パッケージマネージャを使わないでPEARを入れるのは
経験が少ない人にとっては大変だし。

まあ、使わないでやれるのならそれに越したことは無い。

**nobodyさん** · 2007/08/26(日) 21:16:47

てか、あまり普及してるのもセキュリティ的に良くないんじゃないか？
それより独自で関数増やしていく方が、オリジナル性でると思う。

**nobodyさん** · 2007/08/27(月) 09:20:58

時間の無駄ｗ

**nobodyさん** · 2007/08/27(月) 13:07:30

PEAR使うんなら、同梱しておけばいい。
ライセンス的に大丈夫であれば。

**nobodyさん** · 2007/08/29(水) 15:44:46

これOmotiじゃね？

**nobodyさん** · 2007/08/29(水) 23:14:05

どうみても本７です。本当にありｇ(ry

**nobodyさん** · 2007/08/30(木) 15:38:19

ぬこえもんなんか言ってよ！

**nobodyさん** · 2007/08/30(木) 19:03:30

バカな提案していい？

携帯だけで、ショップ運営。

商品の管理や写真アップや顧客管理など
最初のシステム設置を除くほぼすべてを
携帯電話のみで行えるシステム。

もちろん携帯電話でPC用サイトが見れる
フルブラウザを使うわけではない。

バカらしい？俺もそう思う。だがしかし、
もしかしたらそういうのを望んでいる人がいるのかもしれない。

もしそういうASPとかあったら教えて。

**nobodyさん** · 2007/08/30(木) 21:31:30

今日、「ショップ運営者が自由に商品タイプを作れる機能」について
すばらしい発想がうかんだ。

この方法なら、いろんな商品タイプを作ったうえで、
なおかつ拡張モジュールによる柔軟な拡張を実現できそう。
あとは、検索・ソートをどうにかすれば。

数百、数千程度ならどう作っても問題ないとは思うけど
結構負荷高いだろうからなぁ。特にソートとか。
いろんな商品タイプを作ったうえで、どうソートさせるか

**nobodyさん** · 2007/08/30(木) 22:56:35

求められてるのは「かつて無い新機能」ではなくて
「既出機能の全部入り」だと思うなあ

多くの人の不満は「あのソフトにはAと言う機能があるけどBと言う機能が無い」
「このソフトにはBと言う機能はあるけど、Aと言う機能が無い」
あちらを買えばこの機能が立たずみたいなところに尽きると思う。

ここで要望を集めたソフトを作るのも良いけど、それだけだと
既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
ベースとしてトップシェアのソフト+トップシェアソフトの不満点解消
と言う目標設定があるといいと思う。
はなからこのスレの要望をほとんど満たしたものになるんじゃないかな。

そのジャンルで今トップのソフト買って使ってみてそのスレ見てくる。
※今だとネットショップ・オーナー２かな？
そうすると「後これさえあればとりあえず文句無いのにな」という意見が散見される筈。
つまりトップのソフトの不満を解消したのをサクッと出せば（まあ実際に作れたらの話）
ほとんどの人は満足すると思う。
逆に言えば今トップのソフトと同等以上の「全部入り」が作れないなら
使ってくれる人も少ないだろうから新たに作る意味はあまり無いような気がする。

1：トップシェアのソフトと同等の機能（パクリ上等）+不満点トップ5～10箇所を解消
2：致命的なバグが無い+新OSやバグ修正にちゃんと対応してくれる。
この二点さえクリアできれば市販ソフトと同等の値段でも買う人多いと思うよ。

後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな

**nobodyさん** · 2007/08/30(木) 23:58:14

で、>>1さんは何で作るの？
PHPとMySQL？
どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね

**nobodyさん** · 2007/08/31(金) 00:03:09

>>67レスどうも
> 「既出機能の全部入り」だと思うなあ
そうかなぁ？ osCommerce、Zen Cart、某シェアウェア、と使ったけど、
どれでも、なにかの機能をOFFにするんだよね。
たとえば、レビュー機能なんていりません。ってな感じで。あまりにも機能が多すぎると
初心者の人は使いづらい。管理しなくてはならない事が増えるから。

機能はつける。つけるけど、その大部分は拡張モジュールとしてつけたいんだ。
そして、どういう拡張モジュールの組み合わせでもちゃんと動く。
（現実には完璧にするのは不可能だろうけどなるべくうまくいくように）
そういう柔軟性を持たせたい。

残念ながらosCommerceやZenCartはこれができない。これはこのバージョンとの
組み合わせでしか動かない。またこれとこれは同じファイルを修正する必要があるから
（プログラムができない人には）両方同時に組み込めない。など。

> ここで要望を集めたソフトを作るのも良いけど、それだけだと
要望を集めるのは、実はその要望を実現するというよりか、その要望を後からでも簡単に組み込める
仕組みを提供したいから。だからそこ想定外の要望がほしい。この要望を実現するには
大幅な設計変更が必要じゃないか！と思うぐらいのものを先に洗い出しておきたい。

> 既存ソフトにはある機能を実装し忘れた新たな不満を抱えたソフトの誕生になりかねないから
実装し忘れたなら、その機能を拡張モジュールとして後から組み込めばいい。そういう風にしたい。
完璧を目指してもそれは無理。システムを一枚岩として作るから、あとあと機能を追加しづらくなって
これは○○が足りないといわれる。

> 後、他ソフトからの商品データがまんま使えるとか自動変換とかあれば完璧かな
そういうのはインポートモジュールで。需要があるのなら（自分を含めた）誰かが作るさ。

**nobodyさん** · 2007/08/31(金) 00:19:09

>>68
> PHPとMySQL？
> どうせなら、PDO使ってMySQLとSQLite対応のものにしてよね

PDOは使ったことないけど、いまざっと調べたところ、使わないという結論になるだろう。
その理由はPHP5以上じゃないといけないから。

PHP4の出番はまだまだあるとはいえ、サポートも打ち切られる（た？）みたいだから
切り捨てるというのも、悪くはない考えなんだが・・・。

今のところはCakePHPを使う予定。今仕事で使っているのがこれだから俺としては一番実績がある。
CakePHPならPHP4,PHP5でも動くし、データベースもMySQL、PostgreSQL、SQLite、他さまざまなRDBMSに対応。

CakePHPで決定ではないが、何かのフレームワークを使う。ただし、上のほうでも書いたが
PEARやCPAN(言語にPerlを選んだ場合）など入れづらい外部ライブラリに依存するもの。
入れるのにシェルを使用するものは候補外。なるべく多くの環境で動くものを使う。

さすがにRDBMSを使用しないで作るのはキツイが・・・。
フレームワークって大概（全部？）RDBMSを使うように作られているし。

**nobodyさん** · 2007/08/31(金) 00:24:37

これから作るのに死亡カウントダウンがいよいよ始まったPHP4かい

**nobodyさん** · 2007/08/31(金) 00:27:57

しゃーないじゃん。仕事で使っているサーバーがPHP4で
抜ける許可下りないんだから (T-T)

別にCakePHPならPHP4用として作る必要はないから
問題ないよ。普通に作れば勝手に対応している。

**nobodyさん** · 2007/08/31(金) 00:30:24

RedHat エンタープライズとかなんとかのどれかのバージョン。
PHP4が入っているわけだが、そのサポート期間まだまだあるから
たぶん今PHP4を使っているサーバー。しばらくはそのままだと思うよ。(T-T)

混乱とか客の都合とか考えずにずばっとアップグレードしちゃえば良いのに。

**nobodyさん** · 2007/08/31(金) 13:42:40

問題ないか？
新規にサバを契約しようとしたら、そろそろRHELは5になろうかと
いう時期だよ。
他人が使おうと思っても、契約できるレンサバがないって話になる。

**nobodyさん** · 2007/08/31(金) 13:49:54

ZendFrameworkで希望

**nobodyさん** · 2007/08/31(金) 15:33:18

俺もZendが良いな。
それかCI。

**nobodyさん** · 2007/08/31(金) 18:28:29

http://www.itmedia.co.jp/enterprise/articles/0702/28/news028.html

> NexenServicesが発表した2006年8月現在の統計では、
> いまだPHP 4が全体の90％を占めており、
> PHP 5の利用はまだ広まっているとはいえません。

いまPHP4のシェアはどれくらいかソースある？
それ次第ではZendFramework選択肢に入れてもいいけど。

> Code Igniter
悪くは無い。

**nobodyさん** · 2007/08/31(金) 22:26:03

このソフトで一気にPHP4からPHP5へ移行させるくらいの気概が欲しいもんだな。

**nobodyさん** · 2007/09/01(土) 01:31:33

本のISBNってどこかで公開されてる？

**nobodyさん** · 2007/09/01(土) 01:43:25

amazonのAPIで良いんじゃないの？

**nobodyさん** · 2007/09/01(土) 01:44:29

AmazonはBOOKデータベースから買ってる。
http://www.nichigai.co.jp/newhp/dcs/book_f.html

**nobodyさん** · 2007/09/01(土) 02:21:14

ルート権限と鯖だけ売ったらどうだ。
あとはオンラインショップ構築ソフトの紹介だけ。
好き勝手やりたい奴が人様の作った環境を素直に使うとは思えん・・

**nobodyさん** · 2007/09/01(土) 10:44:37

>>82
それただのASPｗ

**nobodyさん** · 2007/09/03(月) 20:37:43

要望を書きたいがなんか難しそうな話になってるから
辞退。

**nobodyさん** · 2007/09/03(月) 20:57:28

>>84
気にしなくていいと思うよ
このスレだって最初から小難しい話で盛り上がってたわけじゃないんだし

**nobodyさん** · 2007/09/03(月) 21:16:15

>>84
かいてくださーい。お願い。

様々な業種に対応できる設計にしたいから
いろんな情報がほしい。

マイナーな要望であればあるほどうれしい。
（その要望を必ず取り入れるわけじゃないので注意）

**nobodyさん** · 2007/09/03(月) 21:21:08

ところで前から気になっていたんだけどさ、靴とか服とか
ベースは同じで、サイズや色の違いがあるものあるでしょ？
あれって、商品コード（JANとか）はそれぞれ違うものなんだよね？

だから特に何ってわけじゃないけど。

**nobodyさん** · 2007/09/03(月) 21:24:07

オプションという機能をつけよう（つけられるようにしよう）と思う。

服とか買うとき、オプションでサイズを選べるとか
色を選べるとか、ジーンズのすそ上げするかとか、
オプションで値段が変わったり。

**nobodyさん** · 2007/09/03(月) 21:31:29

>>88
オプションじゃなく、当然カートについてる機能。

**nobodyさん** · 2007/09/03(月) 22:01:02

>>89

たぶん、あなたは勘違いをしている。

**nobodyさん** · 2007/09/03(月) 22:50:39

ポテトもいかがですか？機能

**nobodyさん** · 2007/09/03(月) 22:54:16

しかしここ最近急にのびてきたね、ここ

**nobodyさん** · 2007/09/03(月) 23:33:19

>>92
>>1は作りそうもないのに、伸びてるよな。

って立てたのは俺だけどｗ

一応予定を言っておくと、11月ぐらいから本格的に開始かな。
今の仕事（同じようなもの作ってる）が終わって
経験つんでから別設計（拡張性・汎用性重視）で作る。

それまで、要望聞いて設計中。

>>91
了解。お勧め機能だね。そこらへんは単純なHTMLから
複雑なphpコードまで、ブロックというかガジェットというか
そういうパーツにして、好きなところにおけるような設計にするつもり。

**nobodyさん** · 2007/09/04(火) 00:26:28

方向性としてｌベッキーとかＷＩＮＡＭＰみたいなのを作るわけか。

アウトルックのスパムメール一括登録できない。
見たいな、なぜその機能がないんだ？みたいな事あっても
1の言うようにプラグイン誰かが作るところがソフトメーカー品よりある意味安心できるところだね。

鶏と卵の関係で
素の核のソフトがそれなりに使えないとプラグインを作る人も少なくなるだろうから、
1の優先順位選択のセンスにwktkする。

94 · 2007/09/04(火) 00:30:48

あ、分かると思うけど一応訂正。

1の優先順位選択のセンスにwktkする。
↓
1の要望を取捨選択するセンスにwktkする。

**nobodyさん** · 2007/09/04(火) 02:44:54

スキンというのかテンプレートというのか、外観デザインは変更しやすいのが良いね。
EC-CUBEの3rdパーティ製テンプレートをダウソしてみたけど、何でファイルが500個以上あんのかとorz

**nobodyさん** · 2007/09/04(火) 09:46:21

CSSでおｋ

**nobodyさん** · 2007/09/04(火) 10:44:36

でさ。ブロックと言うかガジェットというか、
好きなパーツをおけるようにすると、
どうしても外部のWebサービスをおこうとするよね？
それ自体は別にいいんだけど。

そういうことをするとセキュリティ上のリスクがある。
詳しく言うと、外部のWebサービス（JavaScript）を実行するため
そこが信頼できないサイトだとcoockieを奪われたりする。
ここを気をつけないといけないな。

httponlyを使ってcookieをJavaScriptから読み取れないようにする。
iframeをうまく使う。ログインページなどには外部のWebサービスなどを
入れられないようにする。うーん。他にあるだろうか？

**nobodyさん** · 2007/09/04(火) 10:44:59

cssじゃデザインまで変わらないでしょｗ

**nobodyさん** · 2007/09/04(火) 10:49:54

>>96
フレームワークを使うとビュー（見た目）は分離されているので
それだけでもある程度は変更しやすい。CSSも使うし。

ただ、もう一段階上がほしいよね。
理想としては管理画面からデザインをGUIで変更したい。
CSSはデザインを変えやすいけど、やっぱり素人が使うものじゃない。
まあ大変だろうなぁ。

ファイルはなるべく少なくする方向で。格納場所は一箇所で。
俺も嫌いだよ。ごちゃごちゃ沢山あるのは。

ホームページビルダーとかで作ったHTMLを変換して使えるようにするのもありか？

**nobodyさん** · 2007/09/04(火) 10:59:26

>>99
出力する（X)HTMLがちゃんと考慮されており
classとかがきちんと設定されていれば、がらりと変えることは可能。

(X)HTMLがちゃんと考慮されていればCSSだけで、
1カラム、2カラム、3カラムのレイアウトに変えることも可能。
でもやっぱり限界あるよね。どうしても同じようなデザインになってしまう。

技術的な限界というか、汎用性のある(X)HTMLにしようとすると、
むしろ人間的に、うぎゃーってなってくる。

あー。それでも、デフォのXHTMLを用意して、(もちろんvalid)
CSSである程度は変えられるように作るけどね。

**nobodyさん** · 2007/09/04(火) 16:23:57

blogは同じ中身でも大胆にルックを変えれるぜ？

**nobodyさん** · 2007/09/04(火) 23:59:00

間抜けなﾂｯｺﾐｽﾏｿ
POSレジdata => PC data => web data => PC data　在庫管理autoなもの

tech.自慢なprogは、オンライン店舗運営者を選んでしまう。
敷居が低ければok

**nobodyさん** · 2007/09/05(水) 00:57:53

> POSレジdata => PC data => web data => PC data　在庫管理autoなもの

PC dataがなんのことかわからんが、
　CSVでファイルアップロード＝> web data =>Web上で在庫管理もしくはCSVファイルでダウンロード
なら考慮事項に入っている。

ただCSVファイルといっても、そこに含まれるデータは決まった形でないといけない（決まったフィールドがないといけない）
だからPOSレジのdataをそのまま使えることはないし、外部の在庫管理ソフトでそのまま使えたりはしない。
一度変換が必要になる。業界共通のデータ形式というものが存在しない（はず）のだからこればかりはどうしようもない。

有名なPOSレジや在庫管理ソフトなら、それ専用の取り込み・出力ツールやデータ形式変換ツールが作られ、
場合によっては付属するかもしれないけど、少なくとも俺は有名なPOSレジや在庫管理ソフトがあることを知らないな。
あったとしても、それが手に入れにくいもの、金がかかるものなら俺は作らない。俺以外の誰かが作る可能性はあるだろうけどね。

あと念のためにいっておくと、excelファイルを直接アップロードしたりには対応できないよ
（対応しないのではなく、対応することができない）

なぜならexcelファイルはデータ形式が柔軟すぎる上に、内部形式が非公開だから問題を起こさないようにするのがきわめて難しい。
phpでexcelファイルを読み書きするライブラリはあるがこれも完璧ではなく、特に日本語がはいっていたり、
セルを結合したりいろいろ変更していると不具合が発生する。まあexcelでCSVファイル扱えるから、問題ないと思うけど。

**nobodyさん** · 2007/09/05(水) 01:20:48

>>103
> tech.自慢なprogは、オンライン店舗運営者を選んでしまう。

どのソフトをさしてtech.自慢なprogといっているのか知らないけど、
tech.自慢なprog とオンライン店舗運営者を選んでしまうことには
なんの関係もないよ。

tech.自慢をしているわけじゃないが、オンライン店舗運営者には、
オンライン店舗なりの最低限の知識は必要。
FTPに関する知識とかSSLに関する知識とかバックアップに関する知識とか

もし、その程度の最低限の知識も持たずに、このソフトは難しい。
tech.自慢しているだけだ。と思っているのならお帰りください。

**nobodyさん** · 2007/09/05(水) 01:24:48

tech.自慢なprog で使いにくいソフトはあるかもしれないが、

少なくとも、使いやすいソフトというものは、tech.自慢なprog でないと実現不可能ですから。

**nobodyさん** · 2007/09/05(水) 02:08:10

■■■■■■■■■■■■■■■■■■■■終了■■■■■■■■■■■■■■■■■

**nobodyさん** · 2007/09/05(水) 09:10:38

tech.自慢なprog(笑)

**nobodyさん** · 2007/09/05(水) 21:25:56

ところで会員機能など個人情報を取得する場合
SSL必須でいいかな？

**nobodyさん** · 2007/09/05(水) 23:56:32

POSTはSSLって習っただろう

**nobodyさん** · 2007/09/06(木) 00:01:34

>>110
どこの常識だよｗ
GETであってもURLは暗号化されるっちゅーの

**nobodyさん** · 2007/09/06(木) 00:03:58

>>109
いいんじゃね？
個人情報は暗号化されないといけないものだし、
SSLも使っていないショッピングサイトは失格。

**nobodyさん** · 2007/09/06(木) 23:49:31

>>1
これは？
ttp://www.ec-cube.net/

**nobodyさん** · 2007/09/07(金) 01:33:52

>>113
・最近作り始めたくせに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の代わりに使うというのはありでしょう。

でもやっぱり、一枚岩。いろんな機能が絡み合っていて、何か機能を追加、削除しようと思ったら
ソースコードに手を加えなければ行けない。これでは俺が求めるレベルの柔軟性は達成できないだろう。

**nobodyさん** · 2007/09/07(金) 02:35:44

あー。ほーらいわんこっちゃない。
あんなに文字列連結していると絶対入り込むんだ。
しかもJavaScript盛りだくさん。

ちょっと通報してくる。

**nobodyさん** · 2007/09/07(金) 06:16:48

少し期待してスレ見たけど、開発プロセスが甘いんじゃない？

SSL必須とか、気持ちは理解できるけど意味不明で、
ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
というか、SSL利用部分(追加機能)は積極的にモジュール化すべきじゃね？

納品先が決まってない場合の利用サイドでは、必ず、
「とりあえず動かす」という要求があるはずだし。
# ZenCartのインストーラを思い出してくれ

それ以前の開発ポリシの話題だが、要件定義をしっかりやって、
実現可能性に近似な言語とフレームワークを使うのがよさげ。

DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
サーバサイドMVCとクライアントサイドMVCは下手に混在させないで
別けて考えた方がいい。

**nobodyさん** · 2007/09/07(金) 06:28:37

SSLとJavaScriptの考え方だが、
未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
機能的クレーマの大半はコイツ等だったりする。
# Win98なんだけど、どおやったら良いの？
# ．．．みたいな、ダメっぽい前提をそもそも知っている顧客

こういう低レベルなリテラシしか持たないユーザに対し
どのような誘導策を考え、実現するか、が、
-互換性の無いJavaScriptを排除する
-SSLを必須としない(または、54bitSSL 対応、非SSL 許可)
という考え方に結びついている。
# 古いMacのIE5.2とか、普通に使うヤツの神経を想像してみてくれ

もちろん、対応OS、ブラウザを指定するのは重要だと思うが
アプリ機能の実現可能性とは直接的に関係が無い。

**nobodyさん** · 2007/09/07(金) 09:21:39

なんかえらそうに低レベルとか語ってるけど、結局大した事言ってないよなｗ

**nobodyさん** · 2007/09/07(金) 09:35:23

なんかえらそうに語ってみたが、どんなレベルの情報が必要だったんだい？

**nobodyさん** · 2007/09/07(金) 09:45:16

＞未だにWin95/98ユーザは馬鹿に出来ない数が居るし

いつのネタだよ。
すでに無視していい5%を切ってるよ。

**nobodyさん** · 2007/09/07(金) 09:47:20

> 少し期待してスレ見たけど、開発プロセスが甘いんじゃない？
開発プロセス？なんのこと？開発なんてまだ行われてないけど？

> SSL必須とか、気持ちは理解できるけど意味不明で、
> ナニゆえ必要か明確でない機能は、開発初期で盛り込まないほうがいい。
何ゆえ必要かって、それはお客さんの個人情報を守るためだよ。

> 納品先が決まってない場合の利用サイドでは、必ず、
> 「とりあえず動かす」という要求があるはずだし。
冗談はやめてくれ。どんな納品先であれ、”会員機能など個人情報を受け取る場合は”
通信内容の暗号化は必須だろ。「とりあえず動かす」なんて素人のシステムだよ。

> DOM、BOMを利用しようと思えばJavaScript利用も仕方ない。
BOMってなんだ？爆弾か？それはさておき、
それこそ「ナニゆえ必要か明確でない機能」であり
積極的にモジュール化すべき部分だろ？言っていることが矛盾してるぞ。

> SSLとJavaScriptの考え方だが、
> 未だにWin95/98ユーザは馬鹿に出来ない数が居るし、
> 機能的クレーマの大半はコイツ等だったりする。
JavaScriptは使わないほうが、より多くの人に対応できるんだが？
SSLに関しては、古いブラウザでも対応しているわけで、必須だからといって、
Win95/98ユーザが見れないことにはならない。他のシステムだが、IE5.01でもテスト済み。

オンラインショッピングで一番重要なこと。
それは運営者の都合や無知のために、脆弱なシステムで運営することじゃないのか？
一番重視するのは顧客の安全、個人情報を守ることじゃないのか？
運営者が無知なのは、まあ仕方がない。だからこそ安全側に倒したシステムであるべき。
そうは思いませんか？

どうしても納得がいかないのなら、オープンソースなので、
勝手に危険なシステムにダウングレードしてください。

**nobodyさん** · 2007/09/07(金) 09:49:52

あぁ、BOMってBrowser Object Modelのことなのね。
そこは俺が知らなかった。すまん。

**nobodyさん** · 2007/09/07(金) 10:27:18

なんだか顔まっかにした必死な人がいるなｗ

**nobodyさん** · 2007/09/07(金) 13:03:06

サイト運営者からしたら、
「SSL？それなんのこと？難しいことわかんない。
とりあえず売れればいい。」なのだろうが、
そんな客のことを考えないやつが、ネットショップなんてやるなと言いたい。

**nobodyさん** · 2007/09/07(金) 15:06:25

SSL必須でもさほど問題ない気がする

**nobodyさん** · 2007/09/07(金) 22:19:03

Byte Order Mark だろ、普通。

**nobodyさん** · 2007/09/07(金) 22:58:38

そもそも、SSLなんてオープンソース提供者側が、考慮する物なのか？

**nobodyさん** · 2007/09/07(金) 23:13:53

>>127
うん。当たり前。

まあ、ウェブサイト全体をSSLする、つまりhttpsにで始まるURLしか
存在しないのなら話は別だが、Amazonとか見ればわかるように普通はあまりしない。
SSLはサーバーの負荷が高いからね。重いサイトになってしまう。

ついでにいうと、ウェブサイト全体をSSLにするを選んだ場合、共有SSLだとせっかくドメインとっても
全部が https://レンタルサーバーのドメイン/自分のドメイン/ ってなるから悲しいぞｗ

さらに技術的な話になるが、共有SSLだとドメインが違うため、別サイトと認識されセキュリティ上の理由で
cookieを渡せないためセッション（同一人物であるか）を保つのに一工夫しないといけない。
でないとカートに商品を入れていって、いざ住所などを入力する共有SSL画面になるとカートが空になっちゃう。

**nobodyさん** · 2007/09/07(金) 23:21:08

>>128
よくわからんが、SSL対応のページと非対応のページのURLを
初回セットアップの時にDBに登録して、
決済が入る部分はそのURLを参照する、のは駄目なのか？

俺は普段そうしているけど。もっと考えなきゃいかん話しなのか？

**nobodyさん** · 2007/09/07(金) 23:26:11

ひとつ足りなかった。

共有SSLでなく、独自SSLの場合で、httpとhttpsが混在する場合、
Amazonなどの大手が使っている方法。
これは対応するのは、比較的簡単なんだが、
それでも、httpでのアクセスで送ってもいいcookie、
httpsでのアクセスでしか送ってはいけないcookieにように
ちゃんと考慮して作らないといけない。

いずれにしろ、難易度の大小はあれ、ソフト開発者が
考慮しないといけないということ。
ちなみにhttpとhttpsが混ざるサイトでの共有SSL対応は一番難易度が高いです。

**nobodyさん** · 2007/09/07(金) 23:29:29

>>129
そりゃ、設置する人はそれだけでいいいけど、
それだけでいいように作るのは大変なんだぞ。

車走らすのには、アクセル踏めばいいだけだが、
アクセルを踏んだら車が走るような
仕組みを作るのが難しいのと同じで。

ここはWebProg板。作る人たちの板ですので。

**nobodyさん** · 2007/09/07(金) 23:39:53

>>131
作る側の意見で答えているんだが、間違っているのか？
他のオープンソース見ても、そうしてると思うんだが。

**nobodyさん** · 2007/09/07(金) 23:41:12

>>132
あんたの意見は、公開されている
スクリプトをダウンロードして
サーバーにアップロードして
簡単な設定をしてインストールしているだけだ。

それ以外のなにをやったことがある？

**nobodyさん** · 2007/09/07(金) 23:53:30

>>133
あんた、何が言いたいか良くわからんのだが、
SSLに対応させるべきか否かというのが論点だろ？
で、俺は>>129みたいにすればどうだ？っと答えたわけだ。

それに対してソースをみてダウンロードしたとかどうとか言ってるが、
そういう問題なのか？ていうか、オープンソースのシステム作るのに、
今まで誰もやったことのない方法でシステムを組むべきなのか？

**nobodyさん** · 2007/09/08(土) 00:02:05

> あんた、何が言いたいか良くわからんのだが、
そりゃそうだろうねぇ。内部の仕組みを何もわかってないでしょ？

>>129みたいにするって意味不明なんだが。
お前、ユーザーがSSLのアドレスを設定すれば
それだけで、勝手にSSL対応が完成すると思ってるだろ？

**nobodyさん** · 2007/09/08(土) 00:07:00

>>135
もしかして、あんたの言うのは「サーバのSSL機能を使いましょう」
ではなく、「システム側でSSLの機能を持ちましょう」

と言うことか？俺は前者だと思ってたんだが、後者なら読み違えた。悪かった。

**nobodyさん** · 2007/09/08(土) 00:23:18

>>136
つかれるやつだな。本来なら話ができる最低レベルの知識に
達していないから出てくるなといいたいところなんだがな

> 「サーバのSSL機能を使いましょう」
そういう意味だよ。

HTTP（HTTPS含む)というのはセッションステートレスなの。
つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。
サーバーから見れば、誰かがカートに商品を入れた。誰かがカートを見た。
ということしかわからない。カートを見たのがAさんなのかBさんなのかわからない。

それを区別するために（他にもあるが通常は）クッキーを使う。
最初にサイトにアクセスしたときにセッションID（管理番号）を発行する。
その管理番号によってカートを見たのがAさんなのかBさんなのか区別している。

逆に言えば管理番号が奪われてしまえば他の人になり済ませてしまう。
そのためにSSLを使う。SSL使った場合、通信内容が暗号化されるから、
通信を傍受しても管理番号はわからない。

しかし、Amazonがそうであるように、常にSSLを使っているわけではない。
SSLを使わない状態でカートに商品を入れている。SSLを使わない以上管理番号が傍受される。

はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？

あなたがプログラマならここからが、あなたの仕事です。やってください。

**nobodyさん** · 2007/09/08(土) 01:27:18

まぁ、大きな問題じゃないだろ。
開発途中でいくらでも変更可能だし

**nobodyさん** · 2007/09/08(土) 01:28:59

中身のないコメントありがとう。

**nobodyさん** · 2007/09/08(土) 02:39:26

>>137
>つまり、一度目にアクセスした人と二度目が同じ人であるかわからない。

ホスト名かIPアドレスを保存するのは？

>>はい、ここからで問題。管理番号が盗まれます。さてどうやってこれを解決しているのでしょうか？

お前はSSLは「サーバの機能を使う」っと答えたよな？
じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？

また、管理番号の件だが、ログイン毎に新しいセッションIDを発行すれば？
Amazonの例ならログインするのはメルアドとパスワードが必要だ。
その時にアクセス用のセッションIDを発行する。

顧客情報にはセッションIDを保存し、そこから顧客情報を参照する。
当然ログアウト後はセッションIDが消えるから、例えセッションIDが
盗まれたとしても、他人がそれだけでログインすることは出来ない。

**nobodyさん** · 2007/09/08(土) 02:56:14

> ホスト名かIPアドレスを保存するのは？

ﾎﾟｶｰﾝ。

むしろ、それではだめな理由を二つ以上答えなさいのネタだろｗ

**nobodyさん** · 2007/09/08(土) 02:58:59

>>140
がんばって調べてきたんだろうなぁ。

> お前はSSLは「サーバの機能を使う」っと答えたよな？
> じゃ、サーバの機能（SSL）を使わない奴の面倒まで見るのか？

まーた、的外れなことを言う。Amazon見たか？
SSLを使うページと使わないページがあるんだよ。
客が使わないんじゃない。システム的に使わないページがあるの。

**nobodyさん** · 2007/09/08(土) 03:02:15

> また、管理番号の件だが、ログイン毎に新しいセッションIDを発行すれば？
はいそうだね。それじゃ次いこうか？

ログインした。新しいセッションIDを発行した。
その後で別の商品をカートに入れるために、
ログアウトせずに、非SSLページに移動した場合どうするか。

カートに入れる処理は、非SSLページという設計なのだから、
当然それは傍受される。

プログラマってのはね、君が考えているよりも多くのことを考えているんだよ。
つぎの、あなたの仕事です。

**nobodyさん** · 2007/09/08(土) 03:03:20

当然それは傍受される。
　　　↓
当然新しいセッションIDは傍受される。

**nobodyさん** · 2007/09/08(土) 03:03:25

>>141
駄目な理由。
みんな固定IPじゃないから。必ずしも同じPCからアクセスするわけじゃないから。

>>142
Amazonみてねぇよ。調べてねぇし。
てかな、俺が知識不足なのは認める。お前の方が偉いわ。
でもな、そこまでSSLにこだわる必要あるのか？ってのがいいたいわけ。
突っ込んでるのも俺だけじゃないだろ。

**nobodyさん** · 2007/09/08(土) 03:05:32

>>143
特定時間を過ぎると、保持されているセッションIDが有効とならない方法もあるね。

で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？
あんたみたいなプログラマ様が余計な機能付けるお陰で
コストや手間が増えまくるって予測できないかな？？？

**nobodyさん** · 2007/09/08(土) 03:06:04

> でもな、そこまでSSLにこだわる必要あるのか？ってのがいいたいわけ。

こだわらないという考えもいい。

ただし、それはSSLをちゃんとわかっている人だけが言うことを許されるセリフだ。
知らないやつが言って良いセリフではない。

**nobodyさん** · 2007/09/08(土) 03:07:47

>>146

> で、「当然傍受される」って言うけど、実際に傍受される確率はどのくらい？

それは、SSLを全否定していることにつながっているわけだが
わかっているか？

> あんたみたいなプログラマ様が余計な機能付けるお陰で
> コストや手間が増えまくるって予測できないかな？？？

客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？

**nobodyさん** · 2007/09/08(土) 03:08:51

>>147
>知らないやつが言って良いセリフではない。

うんそうだね。じゃ、オープンソース使いたい奴、ひいては利用ユーザは
君ぐらいSSLに長けている人間なのかな？？

他のレスでもあったけど、「別にSSLなんて関係ないぜ」みたいに
思っている奴の方が多いだろ。あんたは単に自己を押しつけてるだけ。
高い金出してベリサインと契約して、そんなに効果あるとはおもえん。

**nobodyさん** · 2007/09/08(土) 03:10:00

>>148
全否定はしないが、疑問視はしてるな。

>客の個人情報を守るためのコストをかけたくないと、そういいたいのですか？

コストをかけるのは俺ではなく、カート設置者だろ？
設置者がいらないと思えばいらないだろ。

**nobodyさん** · 2007/09/08(土) 03:12:40

> うんそうだね。じゃ、オープンソース使いたい奴、ひいては利用ユーザは
> 君ぐらいSSLに長けている人間なのかな？？
なにが言いたいのかわからん。まあ、SSLに長けている人間ではないだろうな。
SSLに長けている人間ではないから、○○○←ここにどういうセリフを入れるつもりだ？

> 高い金出してベリサインと契約して、そんなに効果あるとはおもえん。

安い共有SSLでいいだろ。

**nobodyさん** · 2007/09/08(土) 03:14:06

もう寝るからSSL信者様にひとつ。

あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。

実際に会社で客と打ち合わせする奴らならわかるだろ。
SSLなんて大抵疑問視されてるよ。どんだけ必要性を説いてもな。
それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
どうせSSL付けても流出する時はする。大手を見てみろ。

ま、SSLにこだわればいいさ。SSLを導入してないと
使えないぐらいなシステムにすればいい。そんなの誰も使わないだろうけどな。

**nobodyさん** · 2007/09/08(土) 03:16:17

>>150

> コストをかけるのは俺ではなく、カート設置者だろ？
> 設置者がいらないと思えばいらないだろ。

つまり、客の安全よりも、店の利益。
それも、年、たった数千円程度を優先するといいたいのだな？

**nobodyさん** · 2007/09/08(土) 03:17:21

>>152
> あんたは利用者、金出す奴、実際に設置しようと思う奴の声に
> もう少し耳を傾けた方が良い。家でパソコンばっかりしてないでさ。

あんたは、オンラインショップを運営するのなら、
そこで買う客のことを考えたほうが良い。

**nobodyさん** · 2007/09/08(土) 03:20:35

>>152
SSLが疑問視されているというのなら、
その証拠を挙げてもらいたい。

SSLをつけていても流出するという理屈は、
それは、シートベルトをつけていても交通事故を起こすといっているのと同じ
それでシートベルトはするべきじゃないという理由にはならんだろ。
つまりへ理屈だ。

> それでも「あればいいや」って言うぐらいな気持ちで付けるんだ。
それはSSLを理解していないからだ。

**nobodyさん** · 2007/09/08(土) 03:27:28

http://xoops.ec-cube.net/modules/xoopspoll/pollresults.php?poll_id=2
あなたの欲しい新機能は？？
1位 14 % (167)
共有SSL対応

SSLが大概疑問視されているとは、よっぽど小さい所ばっかり相手にしているんだなｗ
しかも、必要な理由を理解させることもできない。まあ自分が理解していないんじゃしょうがないかｗ

SSLを利用していないことで、客が逃げていき、結果的に損をしているということが
わからないんだろうな。

**nobodyさん** · 2007/09/08(土) 06:31:53

たまーにいるよな、SSLイラネっていうヤツ。
実際SSL導入してなくて事故ったっていう事例が少ない（ない？）からだと思うが、
起きてからじゃ遅いって事が何故わからんのか。
SSL利用しないでオンラインショップの経営なんて
自動車保険に入らないで運転してるヤツとなんら変わらん。非常識そのものだ。

**nobodyさん** · 2007/09/08(土) 11:08:07

SSLについてこれだけ語りながら、メールはどうしてるんだろうなｗ
公開カギ使ってんだろうな？

**nobodyさん** · 2007/09/08(土) 11:50:58

メールはメールでちゃんとやればいいだけの話だろう。
メールに関しては別件であり、いま語る内容ではない。
論点をずらそうとしているな。

それとも、ショップを利用するお客様の個人情報を守るための
ショッピングシステムの設計について語りたいのかな？

それならそれで意見を言おう。

基本的にメールで個人情報は送らない。
メールで送るのは「注文された商品を発送しました」など
（具体的な内容は店のポリシーによる）

そして、メールのに詳細を確認するにはコチラをクリックしてください。
とかき、当然その先はSSLで暗号化された顧客情報ページ。

**nobodyさん** · 2007/09/08(土) 16:12:26

define("SSL_URL","http://hoge.com/";);
//define("SSL_URL","https://hoge.com/";);

みたいな感じでどっちでもOKにしておけば問題ないんだよ。
もっと柔軟になれよ。
セッションはsession_regenerate_idやっておけば、完ぺきではないが
危険性は減る。それでもうだうだ言うやつは自分で作ればいいじゃない。

**nobodyさん** · 2007/09/08(土) 16:29:26

>>159
だれが客との間のメールの話してんだよ。
鯖と運営者の間の話だ。

**nobodyさん** · 2007/09/08(土) 18:02:25

>>160
それは、httpsのアドレスを設定しているだけであって、
肝心の処理が書いて無いんですが？

**nobodyさん** · 2007/09/08(土) 18:06:23

>>161
サーバーの運営者の間でも同じだろ。

メールで（客の）個人情報を送受信しない。
個人情報を扱うときはブラウザからやればいい。

っていうか、サーバーと運営者の間に
メールなんてつかわないでいいだろ。
注文が入ったって知らせてほしいのなら
メールの内容は「注文が入りました」だけでOK

**nobodyさん** · 2007/09/08(土) 18:21:49

>>160は、定数SSL_URLを設定すれば、それだけで、
どんなソフトでもSSLの対応が完了するって考えてるんだろ？ｗ

ところでSSL_URLでググるとEC CUBEばっかりでてくるなｗ

**nobodyさん** · 2007/09/08(土) 18:30:13

>>162
処理？HTTPもHTTPSも処理は同じだろうが。

>>164
実際問題そうだろ。HTTPSに渡せばSSLじゃん。

**nobodyさん** · 2007/09/08(土) 18:46:08

>>165
お前ダメダメじゃん。

>>137でも読んでから出直してくれ。

ヒントをあげると、確かにhttpsページにアクセスすれば
そのページに限っては暗号化される。

しかし、多くのオンラインショップでは、ある理由により
カートに入れるときはhttp、決済の時はhttpsと使い分けている。

カートに入れるときと決済時のセッションIDは同じでないと
同一人物であると区別できない。

セッションIDが漏れると大変なことになる。

カートに入れるときと決済時のセッションIDは同じと言うことは
決済時には漏洩の心配が無くても、カートに入れるときに漏れる。

ここまでいえばわかるよな？

**nobodyさん** · 2007/09/08(土) 19:02:13

顧客管理機能が無い、小規模向け
ショッピングカートCGIレベルの話してるんじゃねーの？

顧客情報を入力したらメールで運営者のところに送られてくるだけ。
そう考えれば、メールの話を持ち出してきていることも説明がつく。

想定している規模がぜんぜん違うから話がかみ合わないわなｗ

**nobodyさん** · 2007/09/08(土) 20:40:06

>>165
おまえこそ、大丈夫か？
session_regenerate_id()で再生成も引き継ぎも可能なんだぜ。
PHPのセッションについて10回読んで顔洗って出直してこいよ。
くそむし。

**nobodyさん** · 2007/09/08(土) 20:53:23

>>168
で、お前、それを使った、サンプルコードかけるの？

当然、どのタイミングで、session_regenerate_id()を
実行するのかぐらいは答えられるよね？

**nobodyさん** · 2007/09/08(土) 21:04:06

>>168
サンプルコードってｗ 1行だろうがｗ頭悪すぎｗｗｗｗ
カート操作の度に再生成と破棄をしておけばいいんだよ。クズ.

HTTPSになってからは念のため、入力操作(POST)があった後、再生成しておけ。
これでカートを乗っ取る荒業できる奴なんてほとんどいないよ。

**nobodyさん** · 2007/09/08(土) 21:04:36

>>168
共有SSLの場合は、
https://www.example.com/ と
https://dokokano.server/~example.com/ という風にドメインが違うから

https://www.example.com/ で使っていたセッションIDは
https://dokokano.server/~example.com/ のページに飛んでも、
送られてきません。

そのため、session_regenerate_id()で再作成すればいいという
レベルの話じゃすみません。

知っていましたか？

**nobodyさん** · 2007/09/08(土) 21:05:34

>>170
アンカーミスった>>169な。

**nobodyさん** · 2007/09/08(土) 21:07:45

>>171
バカじゃないの。
おまえは1回もセッションIDを付加させちゃいけないとでも思ってるのか？
生き方反省しろ。

**nobodyさん** · 2007/09/08(土) 21:08:22

>>170
頭が悪いのはあんたですね。

毎回発行するのなら、
httpのセッションIDを奪った人が、本人よりも早く
httpsページに入るだけで、簡単に個人情報奪えますね。

それともhttpsに入るたびに毎回パスワードを要求するように
するつもりですか？カートと決済ページを行き来するたびに
パスワード。使いにくいショッピングサイトですねｗ

それからPOSTにしようが何の関係もありません。

**nobodyさん** · 2007/09/08(土) 21:11:01

>>173
session_regenerate_id()の一行を発行するだけと貴方は言いました。

ドメインが違うと、セッションIDが送られてこないのに、
session_regenerate_id()の一行だけでどうやって対処するつもりですか？

> define("SSL_URL","http://hoge.com/";);
最初は、これだけやればいいといっていたわりに、
どんどんコードが複雑になりそうですねｗ

**nobodyさん** · 2007/09/08(土) 21:14:45

https://www.example.com/
↑これは↓これの間違い。
http://www.example.com/

多分わかって無いだろうから説明しとく。

http://www.example.com/ でカートに入れる。
ここでセッションID 0001（本当はランダムな長い文字列）が発行される。

その後で、 https://dokokano.server/~example.com/ にくる。
ここで新たにセッションID 0002を発行しても、

セッションID、0001と0002ではIDが違うので、
0001のときにカートに入れた商品はなくなっている。

**nobodyさん** · 2007/09/08(土) 21:23:19

クッキーで商品情報を保存。
sslに入るときはPOST。
認証はsslに入った後に行なう。

**nobodyさん** · 2007/09/08(土) 21:25:23

まったく、セキュリティが簡単なコード一つでどうにかなるわけないだろｗ

SSL_URLだって、session_regenerate_id()だって、

セキュリティを保つための一連のコードの中で使う一行でしか過ぎないんだよ。

**nobodyさん** · 2007/09/08(土) 21:26:32

>>177
そうそう。そういったコードが必要。
まだ足りないけどね。
一行、二行でできるもんだいじゃない。

**nobodyさん** · 2007/09/08(土) 21:37:43

やれやれ、何年前の話してるんだか・・・
オナニーばっかでコードも書けない屑ばかりじゃねぇかｗ
共用SSLだろうが、セッションID付加させれば問題ないんだよ。

**nobodyさん** · 2007/09/08(土) 22:45:01

とりあえず落ち着こうぜ
ttp://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
ttp://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp06/entwebapp06_05.html

**nobodyさん** · 2007/09/08(土) 23:01:14

>>181
そんな大量の資料出したら、
SSLのアドレスを設定するだけ
session_regenerate_id()実行すればいいだけと
言っていたやつが泣く

**nobodyさん** · 2007/09/08(土) 23:07:51

>>181
あと、それらに加えて共有SSLではドメインが一致しないため
単純にcookieだけでセッションのやり取りが出来ないって問題があるね。

**nobodyさん** · 2007/09/09(日) 03:44:21

Web制作の料金はいくらが妥当？7案件目
http://pc11.2ch.net/test/read.cgi/hp/1189071609/50

50 名前：Name_Not_Found[sage] 投稿日：2007/09/08(土) 21:52:59 ID:???
>>35-36
いいか、冷静に考えろ。試しに15の内容をWebPro板でも持っててみろ。
「お前、10時間もかかるのかよwww」って笑われるのがオチだぞ。
今やフレームワーク使って、既存ライブラリもあるだろうし、
管理画面のデザインもあらかたCSSで基礎は作ってるだろ。

仕様書はディレクターが客から要望聞いて作ってくるだろ。
15程度の内容なら、要件定義も少ない。DB構造すら既存の構造でOKだろ。

煽る前に冷静に考えろって。15程度の案件、どう考えても3桁いかん。
学生PGがバイト感覚でやるレベルだろ。

スレ違いではあるんですがオンラインショップがらみということで
こんなことをいってるちょっと面白い奴が上のスレにいるんで遊びにきてください。

**nobodyさん** · 2007/09/09(日) 09:27:27

1回作ったら、2回目以降ははやくやすくできるのは当たり前。
それやって稼がないとソフトハウスはおいしくないわな。
当たり前だが客に安くしないよ。ｗ　内部的に安くあげるという話。

**nobodyさん** · 2007/09/09(日) 10:04:16

それは当たり前だが、10時間とかアフォだろｗ
1から作るって事は、たいてい何かやりたいことがあるわけで、
その打ち合わせだけでも（ｒｙ

**nobodyさん** · 2007/09/10(月) 03:04:02

こいつはhttpsにしたら自動的にSSLになると思ってるに違いない！

**nobodyさん** · 2007/09/10(月) 03:26:32

いや、httpsにしたらそのページに限っては自動的にSSLにはなるが、
SSLを使っていても、ちゃんとした使い方でないと情報を防げるわけじゃないし、
その状態でセッション管理やら共有SSL対応やらhttpとhttps間の
情報のやり取りを、安全に行うするには、それなりに大変ということ。

**nobodyさん** · 2007/09/10(月) 12:44:21

タイムリーだなーｗ
SSLを使っていても、ちゃんとした使い方をしないとこういう問題がおきると。
っていうか、Google、Microsoft、Yahooもアウトかよ。
世の中ダメダメジャンｗ

Googleなど大手サイトのcookie転送に問題発覚、認証かわされる恐れ
http://www.itmedia.co.jp/news/articles/0709/10/news007.html

それによると、cookieを使って認証を行っているWebサービスの中には、
最初にユーザーネームとパスワードを入力してログインするときには
暗号化されたhttpsセッショャ唐ﾅ認証用cookieを設定していても、
セッション全体が暗号化されておらず、その後そのcookieをhttpで
転送しているサイトがある。

**nobodyさん** · 2007/09/10(月) 19:24:12

共有SSLなんてものがあるんだな。昔はこんなものなかったよね？
で、自分なりに調べてみたけど、これってシステム開発者
にとっては面倒このうえないな。
SSLそのものの存在意義も犯されるような気がするんだが、
そのあたりについて考察してるような記事とか、
どこかにころがってないかね？ちょっと見つけられなかったので。

個人的には、少なくともセキュリティが気になるのであれば
共有サーバ上でオンラインショップをやること自体があり得ない
んでは？と思う。「共有サーバ上でオンラインショップやりたいから
共有SSL対応してよ」というのはセキュリティ意識が
高いんだか低いんだかよくわかんないな。

**nobodyさん** · 2007/09/10(月) 21:08:36

共有SSL自体はかなり前からあるきがするよ。
本当に面倒きわまりない。しかし、EC-CUBEでも共有SSL対応が要望第一位だったりする・・・

> SSLそのものの存在意義も犯されるような気がするんだが、
本当にｗでもSSLも取ろうと思ったら簡単に取れるようだし、独自SSLも今となっては
存在意義が薄れてるきがするね。そしてEV-SSLなんてものも出てきた・・・。
高いんだよこのやろう。そのうち、金が出せる大手はEV-SSLが標準になって、
中小企業のSSLは注意扱いにされてしまいそう。誰か裏で糸引いて無いか・・・？

話は戻して共有SSLだけど、これ本当に厄介だよな。
でも、ちょっとアクロバット的なことをすることになるだろうけど、
httpとhttpsが混ざっている独自SSLサイトと同レベルのところまではいけそうな感じ。

ドメインにレンタルサーバー名が入る所はもちろんどうしようもないけど。
（というかドメイン名がこんなんで変に思わないんだろうか？詳しくない人は
ドメイン名なんて気にしない。詳しい人は共有SSLだとわかる。ということだろうか？

> 個人的には、少なくともセキュリティが気になるのであれば
> 共有サーバ上でオンラインショップをやること自体があり得ない
> んでは？と思う。
まったく持ってその通り。でも専用サーバーにすると、サーバー管理者
もしくはマネージメントサーバーにさらに金がかかる罠。

> 「共有サーバ上でオンラインショップやりたいから共有SSL対応してよ」
小さい突っ込みだが、共有サーバーでも独自ドメイン＋
独自SSL（普通は別途費用がかかる）は使える。

金が無いところは、素直に楽天とかASPでもを使っていてくれと言うところだが、
それなりに使えるショッピングカートがオープンソース（無料）であるばかりに・・・

**nobodyさん** · 2007/09/10(月) 23:28:02

>>190
超正論だけど、共用でショップやるのは許してやってくれ。

**190** · 2007/09/10(月) 23:41:59

EV-SSLなんていうものもあったのね。
時代についていってないなorz

まぁ、ぱっと見は、共有SSLで

>ドメインにレンタルサーバー名が入る所はもちろんどうしようもないけど。
>（というかドメイン名がこんなんで変に思わないんだろうか？詳しくない人は
>ドメイン名なんて気にしない。詳しい人は共有SSLだとわかる。ということだろうか？
有名なレンタルサーバ名（？）であるなら
それを見て「あぁ、共有SSLに飛んだのか」とわかるだろうってこと？
えっ、ちょいとおまいさん。。。
第三者にとっては、
共有SSLサイトなのか
フィッシングサイトなのか区別がつかない
ってことも意味してるのかい？
であるなら、恐るべし共有SSL・・・

>> 「共有サーバ上でオンラインショップやりたいから共有SSL対応してよ」
>小さい突っ込みだが、共有サーバーでも独自ドメイン＋
>独自SSL（普通は別途費用がかかる）は使える。
当然そうですよねorz

**190** · 2007/09/10(月) 23:58:09

>>192
あっ、すんません。
実地では正論が常に通用するものではないとは
わかってるつもりです。
共有サーバー上のショップを全否定するつもりはありません。
どのような方法であろうとメリット、
デメリットあるでしょうし。

ただ、共有SSLの可能性というか限界を知っておきたいな
という気がしたものですから。

**nobodyさん** · 2007/09/11(火) 00:59:36

共有SSLの限界。簡単なところから。

・独自ドメインでhttps運用できない。

・レンタルサーバーのドメインでいいのなら、すべてhttpsで運用することはできる。
（つまり、https://レンタルサーバーのドメイン/自分のフォルダ/ 以下のみで運用)

・レンタルサーバーのドメインでいいのなら、httpとhttpsが混在するサイトを、
独自ドメインの場合と同じように運用できる。
（つまり、http://独自ドメイン/ と https://独自ドメイン/ というよくあるhttpとhttpsの混在構成は、
http://レンタルサーバーのドメイン/自分のフォルダ/ と https://レンタルサーバーのドメイン/自分のフォルダ/ の混在と同等）

結局のところ、http://独自ドメイン/ と https://独自ドメイン/自分のフォルダ/ というドメインが違うものの混在が
http://独自ドメイン/ と https://独自ドメイン/ の同じドメインでの混在と同レベルのセキュリティを
達成できるかという話になるかと思うがどうだろうか？

**nobodyさん** · 2007/09/11(火) 01:33:07

で、>>1さんはWikiくらいたちあげたらどう？

**nobodyさん** · 2007/09/11(火) 03:08:21

けっきょくなんも作ってない口だけ野郎だったってわけか

**nobodyさん** · 2007/09/11(火) 17:13:18

あと、携帯からだと、共有SSLはダメである場合が多いね。

**nobodyさん** · 2007/09/11(火) 18:25:46

>>198
ベリサインかジオトラストなら大丈夫だけど、安いのは難しい。

**nobodyさん** · 2007/09/12(水) 22:37:31

別に最初から完璧なモノを作る必要は無いんじゃないの？
まずは簡単にオンラインショップ（的な何か）を作れる所から始めて
ｾｷｭﾘﾃｨやその他問題は、後から頑張るって方向で。
設計的に問題がある場合は後から一度大破壊して1から作り直し。

いつまでもスレ消費して議論で10スレ使うよりその方が早い