トップページ⇒php
991コメント359KB

SNS作ってみよう

■ このスレッドは過去ログ倉庫に格納されています
0001へっぽこ君2006/09/05(火) 23:37:06ID:dR0NUQuB

そんなわけでテストよろすくお願いします。

http://tiraura.sytes.net/
0446nobodyさん2006/10/10(火) 07:45:05ID:???
モーヲタに限らず、ヲタはすべからくキモイ。これ定説。
0447nobodyさん2006/10/10(火) 09:32:09ID:???
サーバ増設して動かせるスケーラビリティーって、Java、C/C++、.NETを使ってるミドルウェアしか実現できない罠。
Perl、PHP、Ruby、Pythonでどうやって、サーバ増設して動かせるスケーラビリティーを実現するのか説明してほしい。
利用者増えて、サーバ増設して動かせるスケーラビリティーが要求される時点で十分に大規模なシステムだと思うが。
0448nobodyさん2006/10/10(火) 12:20:25ID:???
>>447

mixi じゃね？
0449nobodyさん2006/10/10(火) 13:41:42ID:???
サーバを増設するときの事も考慮して作っておくと吉

オープンソースも工夫次第
ttp://d.hatena.ne.jp/yoosaki/20060707/1152237361
ttp://goodsite.cocolog-nifty.com/uessay/2005/09/mixi_5854.html
ttp://blog.livedoor.jp/nipotan/archives/50538571.html

金があるなら、Oracle、専用のミドルウェアを買ったらいいね
0450nobodyさん2006/10/10(火) 13:46:02ID:???
今さらSNSなら1〜10万人程度で普通に動けば十分
人集めるの大変
運用コストが回収できないならサーバ増設しない
0451nobodyさん2006/10/10(火) 16:42:29ID:???
PHPでもPerlでも
レプリケーションで負荷分散すればいいんじゃ？
0452nobodyさん2006/10/10(火) 17:10:20ID:???
>>445
モーオタもキモイけど、店員もキモイでFA
0453nobodyさん2006/10/10(火) 21:46:51ID:???
今SNSつくってるんだけど、テーブル設計が悩みますね。
フレンドリストやコミュニティリストはユーザの基本情報とは別テーブルにしたほうがわかりやすいかな？

俺が考えてるのは、フレンドリストテーブルを作って、そこに、IDを２つ（自分のと友達の）をどんどん追加していく、
というものなんですが、みなさんどうしてます？
0454nobodyさん2006/10/10(火) 21:53:43ID:???
>>453
それでいいんじゃない？
0455nobodyさん2006/10/10(火) 23:42:02ID:???
とりあえず作って試すしか。
良いのができた（もちろん検証済みのを）ら晒してくれ。
実装的には将来テーブル変えることも想定して組んだ方がいい。もう一度作り直す覚悟なら何も考えなくても良いけど。

ミクシの記事とか見てると、機能ごとに鯖分けして負荷分散してるみたいだから、機能ごとに別テーブルにしておいた方が良いのかもな。
0456nobodyさん2006/10/11(水) 00:11:33ID:???
>>453
っていうかそれが普通誰でも考え付くオーソドックスな方法だと思うが。
0457nobodyさん2006/10/11(水) 01:02:53ID:???
>>453
それでいいと思うけど、疑問に感じるんなら、正規化の勉強をした方が良いと思うよ。そんなに時間かからないから。
0458nobodyさん2006/10/11(水) 01:10:37ID:???
>>453
強いて言えば、例えば会員番号が
35 → 77
77 → 35
という具合に、実質的に同じつながりを示すデータが重複しないように工夫する余地はあるかも。
0459nobodyさん2006/10/11(水) 02:24:31ID:???
>>458
いや、あえて重複させといたほうが、
あとでいろんな場面で便利に使いやすいと俺は思う。
（クエリでWHERE条件を単純に指定しやすくなる等）
0460nobodyさん2006/10/11(水) 13:39:49ID:???
機能ごとにテーブル作ってみるか。
俺の考えだと足跡機能にもテーブルが必要になりそう・・・。
0461nobodyさん2006/10/11(水) 15:52:10ID:???
>>459
そうだね。
DBを富豪的に使って（無駄があってもOK）、SQLがシンプルになるならそっちを取る。
0462nobodyさん2006/10/11(水) 19:38:18ID:???
YouTubeを作って16億ドルか。
いい商売してるね。
0463nobodyさん2006/10/11(水) 20:54:56ID:???
今時 O/R マッパつかえばよくね？
0464nobodyさん2006/10/11(水) 22:13:41ID:KMxRqEhe
以前、mixiのソースが表示されてしまう事件があったが、
あれはなんで起こったんだっけ？
ソースが見られてしまう可能性があるなら、データベースのパスワードとかどこに書いとけばいいんだ
0465nobodyさん2006/10/11(水) 22:18:02ID:???
>>463
オススメのO/Rマッパありますか？

PHPならpropelとか？
DB処理部分は、ADOdbとか使っても良いかと思います。

勉強のためにDBラッパを自作してみますか？
0466nobodyさん2006/10/11(水) 22:25:37ID:???
>>464
不可逆的な暗号化を施して、保存するのがオーソドックスな処理でしょうか？
0467nobodyさん2006/10/11(水) 22:43:52ID:???
そんな恐ろしい事件があったのか＞ソース表示
どういう原理でそうなったんだろう
Apacheの設定ミス？
0468nobodyさん2006/10/11(水) 22:48:48ID:???
Boofy
0469nobodyさん2006/10/12(木) 00:56:08ID:???
う〜ん、フレンドの最新日記表示の仕組みがいまいち思い浮かばない。
0470nobodyさん2006/10/12(木) 01:21:02ID:???
Zend_DBは程よく抽象化されてて、拡張性も高いから使いやすいな
0471nobodyさん2006/10/12(木) 01:31:24ID:???
SQLが複雑になってもエンジンの解析に時間喰われる程度で、CPU速いの積んどけば十分だろうけど、DB別けとかないとディスクアクセスで上限来て頭打ちに成ると思うけどなあ。
学者とか理論重視なら綺麗さにこだわるだろうけど。実運用経験者なら、システム全体の負荷が重要だと思うが。
0472nobodyさん2006/10/12(木) 03:07:04ID:???
>>467
けっこう多くの人がソース持ってるよ
でも肝心な部分が抜けてたから、そのままパクるのは無理
0473nobodyさん2006/10/12(木) 05:04:50ID:???
>>464
DBへの接続パスなど重要情報を書いたファイルはドキュメントルートより上に置いてrequire。
こうすれば仮にApacheの設定ミスでソースが見えちゃっても無問題。

>>466
不可逆な暗号じゃ接続できないだろうよ。
0474nobodyさん2006/10/12(木) 07:12:56ID:???
いっそ、ほとんどのソ−スをリクアイアで読み込むような記述にしとけば、あんなに盛大に漏らすことも無かったのにな。
鯖管理者募集してたから新人が設定ミスったのだろうな。ろくに動作確認もせずに鯖公開するアフォは危険(w
0475nobodyさん2006/10/12(木) 08:19:04ID:???
>>474
＞いっそ、ほとんどのソ−スをリクアイアで読み込むような記述

つまり、直接叩いたURL（例：hoge.php）には、require("hoge_hontai.php");と１行だけしか記述しないってことだよね？
俺も自作のWebシステムをそのように変更しようかと悩んでるところなんだけど、
それによってレスポンスとか性能に問題が出ないかと思案中。
まあ、大した影響は無いだろうとは思うんだけど、ユーザ数や同時アクセス数などが増えた場合にどうなるかが未知数。
0476nobodyさん2006/10/12(木) 08:30:04ID:???
誤差の範囲内でしょ
0477nobodyさん2006/10/12(木) 08:41:33ID:???
>>473
SNSユーザーのパスワードと勘違いしてたｗ
0478nobodyさん2006/10/12(木) 09:28:34ID:???
>>476
そうかな・・・そうだといいけど
誰かテストしてみてくれないかな。。。
（自分でやりたいけど、abの使い方すらよく分かってない orz）
0479nobodyさん2006/10/12(木) 13:03:07ID:Rh+mM1tm
cookieにパスワード持たせちゃうのは危険だよね・・・・
0480nobodyさん2006/10/12(木) 14:55:13ID:???
>>479
どういう場面でパスワードをクッキーで保存するんだ？
0481nobodyさん2006/10/12(木) 15:09:17ID:Rh+mM1tm
ログインしたあと、
ユーザー専用のページをまたぐときもっていないとならないんですが・・・・・
0482nobodyさん2006/10/12(木) 16:16:25ID:???
PHPならセッション使えば？
0483nobodyさん2006/10/12(木) 16:22:01ID:???
>>481
発想を少し変えて、ログイン処理した後は、ログインした状態を持ち歩けばいいんじゃない？
0484nobodyさん2006/10/12(木) 17:08:44ID:???
>>483
つまりそれを普通「セッション」と言うんだけどね。
0485nobodyさん2006/10/12(木) 18:11:38ID:???
クッキーとセッションは別物の仕組です。
（このレスだけを読んで、入門者の方が誤解しないように、念のためフォロー）

クッキーは、クライアント側のPCに保存されている
セッションは、サーバ側のPCに保存されている
＝それぞれデータを保持している場所が異なります。

クッキーにしろ、セッションにしろ、必要なければパスワードを保存して持ち歩くんじゃなくて、
パスワードの代わりにログインフラグの値を持ち歩いて、ページ毎の処理をすればいいんじゃない？と。
0486nobodyさん2006/10/12(木) 18:43:28ID:???
>>485
お前の説明だと、ド素人が余計に誤解する恐れあり。

特に、クッキーにログインフラグを持たせちゃダメだろｗｗｗ
いくらでも改ざん出来るんだから。
0487nobodyさん2006/10/12(木) 18:52:39ID:???
いっそのこと会員全員にトークン配っちゃえばいいんじゃね？
0488nobodyさん2006/10/12(木) 22:35:57ID:QUaWl9r8
>>485
いや、設定によってはクッキーで保存するようにできるよ。
俺はそうしてる。

>>486
改竄はされねーだろ。
0489nobodyさん2006/10/12(木) 23:22:35ID:???
>>488みたいなバカがいるせいで、脆弱なWebシステムは永遠に無くならない。
0490nobodyさん2006/10/13(金) 00:28:16ID:???
>>488みたいなアホがいるせいで、また俺のブックマークレットコレクションが増えた。

javascript:void%28%28function%20%28%29%20%7B%0Adocument.cookie%3Dprompt%28%22Set-Cookie%3A%22%2C%20%22%22%29%3B%0A%7D%29%28%29%29%3B
0491nobodyさん2006/10/13(金) 00:46:06ID:nZS7xPDu
XSSなんて許すサイトは論外
0492nobodyさん2006/10/13(金) 00:49:46ID:???
>>488＝>>491
バカかお前は。
XSSなんか使わなくても、クッキーにログインフラグを格納してたら
いくらでも自由にログインできちゃうっつーの（PC所有者自身が、な）。
それについて「自分のPCのクッキーだから問題ない」というのなら、お前はセキュリティ・センスがゼロだ。
0493nobodyさん2006/10/13(金) 00:52:27ID:nZS7xPDu
PC所有者自身なら問題ないだろ
0494nobodyさん2006/10/13(金) 01:01:11ID:???
ネカフェだったら？
0495nobodyさん2006/10/13(金) 01:04:24ID:nZS7xPDu
ブラウザを閉じればセッションは終わる。
0496nobodyさん2006/10/13(金) 02:35:53ID:???
ID:nZS7xPDuが激痛な件について。
0497nobodyさん2006/10/13(金) 09:51:27ID:???
間違ったことは言ってないよな
0498nobodyさん2006/10/13(金) 10:02:11ID:???
一部勘違いしたことを言っとる。
特にログインフラグをクッキーに持たせるなんて愚の骨頂でしかない。
0499nobodyさん2006/10/13(金) 11:23:01ID:EL3EStb/
>>498
何がだめか俺もわからん。
498がどうしてるのか教えてくれ
0500nobodyさん2006/10/13(金) 11:41:45ID:???
>>499
簡単に言えばセッションとクッキーの混同だな。

セッションでもクッキーを使うけど、どのように使っているかを理解していない。
セッションではセッションIDをクッキーに含めるだけで、その他のデータ（たとえばフラグなど）は
絶対に格納しない。格納したらセッションの意味がない。
0501nobodyさん2006/10/13(金) 12:00:01ID:???
>>500
セッションにID以外のデータを含めないのはわかったけど、
具体的にそれからどうするの？
0502nobodyさん2006/10/13(金) 12:48:25ID:???
(1) クッキーとセッションは、まず仕組と使い方を理解する
(2) クッキーやセッションを使う場合のセキュリティ対策方法を理解する

>>485は(1)の話

(2)は
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html
http://www.amazon.co.jp/gp/product/4883374718
あたりを参考にして、セキュアな利用に心がけてください。
0503nobodyさん2006/10/13(金) 12:53:35ID:???
>>501
携帯サイトはクッキー使えない
クッキーなしで動作するサイトを作ろう！
そうすればPCサイトでも、クッキーなしで動作するものが作れるはず。
0504nobodyさん2006/10/13(金) 13:02:29ID:???
>>503
携帯なら個体識別番号じゃまいか
0505nobodyさん2006/10/13(金) 13:14:50ID:???
セッションの話なら、こっちで詳しく聞けると思うよ。

http://pc8.2ch.net/test/read.cgi/php/1064399467/l50
【PHP】セッションについて語ろう！【PHP】
0506nobodyさん2006/10/13(金) 13:24:28ID:???
>>504
携帯サイトで、個体識別番号（サブスクライバID）が取得できない時はどうやってユーザーの識別をしてますか？
セッションIDをURLに付加してページ遷移させる！？

http://bbs.sekkaku.net/faq/220.html
http://tachibana.blog.ocn.ne.jp/blog/2006/05/ez_7a39.html
0507nobodyさん2006/10/13(金) 13:26:47ID:???
>>506
あいことばでも決めとけばいいじゃん
0508nobodyさん2006/10/13(金) 18:01:02ID:???
否定だけして、具体的にログインフラグを持たせないで画面推移する方法が出されてない件ｗｗ
0509nobodyさん2006/10/13(金) 18:15:15ID:???
これはひどい
05105002006/10/13(金) 19:22:53ID:???
>>508
だからお前はバカで基地害でクズなんだよ。
セッションの仕組みをよく理解しろと言っただろうが。
きちんと調べて勉強したのか？

仕組みを理解したのなら、各種フラグはクッキーじゃなくてセッション変数に
持たせるのだという「当たり前の方法」が分かるはずだが。
0511へっぽこ君 ◆vPBS8pifwk 2006/10/13(金) 19:40:34ID:???
クッキー使いまくってるorz
日々勉強じゃぁ
0512nobodyさん2006/10/13(金) 21:32:43ID:???
httpsとセキュアクッキーじゃないならなにやっても無駄。
0513nobodyさん2006/10/13(金) 22:07:49ID:???
あれ？セッションってクッキーに保存されるんだろ？
0514nobodyさん2006/10/13(金) 22:34:41ID:???
post や get でもいいんじゃまいか？
0515nobodyさん2006/10/14(土) 02:50:54ID:???
http://pc8.2ch.net/test/read.cgi/php/1160727068/5
>ドメインが違うことによりクッキーが共有できないことによるセッションIDの
受
>け渡しが簡単にできない問題を解決して初めて「共有SSL対応」と言える。

SSL対応ページとSSL非対応ページを使い分けられる作りにしておきたいですね。
0516sage2006/10/14(土) 02:51:28ID:S3lbqA/j
>>511
　基本的にクッキーに入れて良いのは盗まれたり改ざんさ
れたりしてもいい値だけと考えたほうが間違いがないよ。
　ページ間で結果を繋ぐなら、クッキーに入れるのは乱数化
した文字列（セッション番号）だけにしておくといい。
session_id=lkjdajenn322115
　みたいな感じ。で、プログラムの一番最初にそれをキーに
して他のデータを読む。要は500氏の言う通りなんだけどね。

　500氏が怒ってる理由はクッキーの改ざん問題かな？
　login=1ならログインしてる、login=0ならしてない、とい
うようなフラグをクッキーに入れる仕様だと、改ざんにめちゃ
めちゃ弱くなる。なんせ1に改ざんするだけで認証を不正にパスされて
しまう。
　同じ理由で、重要なデータ、たとえばユーザーIDがクッキーに入って
たりするのもかなりヤバイ。IDが２の奴が、ID=1　というように値を改
ざんしたらID１の名前と権限で操作ができてしまう。

　セキュリティはめんどいけどやるしかない、がんがれ511。
0517nobodyさん2006/10/14(土) 02:56:12ID:???
　ゴメンsage損ねたorz
0518nobodyさん2006/10/14(土) 04:05:39ID:???
どうやってセッションIDが正式に発行されたものと証明させる？
0519nobodyさん2006/10/14(土) 04:11:55ID:???
>>518
スーパーハカーがサーバーに保存されてるセッションIDをクッキーに仕込んだらちょっとやばいかも
まあそんなことできるってことは既にサーバーがハッキングされてるんだろうから考える意味ないか
0520nobodyさん2006/10/14(土) 06:56:22ID:???
別にSSLやセキュアクッキーを使わずとも、
セッションFixationを防ぐ手段はいくつかある。
0521へっぽこ君 ◆vPBS8pifwk 2006/10/14(土) 09:42:45ID:???
idとパスとログインフラグをcookieにしこんでます。
ID:unko Pass:unkounko Login_flg:0 or 1

画面更新毎に
いずれか1つでも違えばエラーで弾いくというユーザー認証をしています。
これをcookieを使わず処理するにはどうすればいいんだろう・・・
セッションなんかサパーリだぁ

ログイン時にセッションというものを発行してサーバーに保存→画面更新毎に認証チェック？？
そもそもセッションってなんだろう。何を元に生成しているんだろう。IP？OS？
んで、そのセッション番号とIDがリンクしているわけですか。
いまいちわかんない。

cookieにセッションIDを入れ込むやり方と直接ID・PASSを入れるのと、どう違うのか
セッションを使わないとcookieファイルを見ればIDとPASSが分かるから？
家族や友達などPC共有している人にバレテしまうという意味でのセキュリティのなさを言われてるんですかね？
でもそのセッションIDの書かれたcookieをコピーしてしまえば他人のアカウントでアクセスできそうな気も。
いや、上の方でcookie使わないみたいな事書いてたから、使わず済むのか。
う〜んう〜〜ん。

なんか的外れな事言ってそう。。わけわかんなくなってきた。
この週末使って勉強してみます。。
0522nobodyさん2006/10/14(土) 09:55:14ID:???
>>521
＞idとパスとログインフラグをcookieにしこんでます

・・・。

http://www.soi.wide.ad.jp/class/20030011/slides/10/
0523nobodyさん2006/10/14(土) 09:58:25ID:???
mixiの携帯サイトの仕組みがいまいちわからんな。
お気に入りに保存でURLみても変数もってないし。
携帯だからクッキーじゃないし。
何だろ？
0524へっぽこ君 ◆vPBS8pifwk 2006/10/14(土) 09:59:08ID:???
>>522
・・・。

やべーよそりゃ！っていうのは伝わりました。
どこがやばいのかは、いまいち分かりませんがorz

参考サイト見てみます。ありがとうございます。
0525nobodyさん2006/10/14(土) 10:12:45ID:???
セッションidも偽装すればいくらでも横取りできるよなあ。
１０万セッションぐらい総当たりすれば１セッションぐらい取れると思う。
Pen4なら１０万試しても１０分もかからないよ。
0526nobodyさん2006/10/14(土) 10:40:28ID:???
>>525の言ってることは非現実的というか、計算がちょっと大雑把すぎるが、
それはそれとして、セッションIDのブルートフォース・アタックを
防御する仕組みを考えないといけないな。

ApacheもしくはPHPで標準装備してくれないかなぁ。
0527nobodyさん2006/10/14(土) 12:08:24ID:???
>>524
俺も色々ｸﾞｸﾞって勉強してみた。

１．セッションIDっていうのを発行して、それをユーザのクッキーに入れる。
セッションIDは他と重複しないランダムな値。既存の暗号作成ライブラリーを使うのが吉。

２．ユーザの細々とした情報は、自分のサーバに保存しておく。
例えば、セッションIDを名前としたテンポラリーファイルを作って、その中にユーザ情報を保存

３．ユーザが最アクセスした時、クッキーからセッションIDを取り出し、そのセッションIDのファイル
があれば、認証済みとする。また、買い物情報等はこのテンポラリーファイルに保存する。

誰か指摘してくれると嬉しい。
0528nobodyさん2006/10/14(土) 14:13:00ID:???
その保存と読み出しを自動でやってくれるのがセッション変数だな。
0529nobodyさん2006/10/14(土) 14:19:48ID:???
セッションidを偽造すれば他人のテンポラリーファイルを操作することは簡単という訳だね。
0530nobodyさん2006/10/14(土) 14:34:21ID:???
おまいら随分基本的なこと話してますね
0531nobodyさん2006/10/14(土) 14:54:56ID:???
要するに、ランダムな番号が割り振られた整理券みたいなもんだな。
0532nobodyさん2006/10/14(土) 17:23:29ID:???
膨大な整理券を用意できれば、本人の代わりもランダムにできると。
0533nobodyさん2006/10/14(土) 17:34:36ID:???
0-9a-zA-Zだと52種類
30文字だとすると52^30
一度にログインしてるユーザーなんて多くて10万程度だろう
100000/(52^32)
がんばって総当たりしてね＾＾
0534nobodyさん2006/10/14(土) 17:39:29ID:???
100000/(52^30)だった
3.31054649 * 10^(-47)

>>525
重要なのはレスポンスが返ってくるまでの時間な
0535nobodyさん2006/10/14(土) 17:57:30ID:???
62な。
0536nobodyさん2006/10/14(土) 21:12:08ID:???
よくわからん。
セッションIDってクッキーに保存されてるPHPSESSIDのことだよな？
ログインフラグにせよこれにせよ、どっちにしろクッキーに保存されるんだから同じじゃないの？
0537nobodyさん2006/10/14(土) 22:16:55ID:???
総当りとか･･合致するセッションIDを発見する前に、DoSが成立するね。
で、そんな大量にリクエスト送ってくるぁゃιぃ人は弾いちゃえばおｋっと

>>536
保存される内容が違うでしょ
要は書き換えらたり見られたりしちゃ困る物はクッキーに保存しちゃダメって事さ
0538nobodyさん2006/10/14(土) 22:17:50ID:90O7Bnz3
open-gorotto ってどうなっちゃったの？
鯖が死んでるみたいだけど。
0539nobodyさん2006/10/14(土) 22:23:38ID:???
>>527
セッションに一般的な概念・仕組みだね。まあ概ねそれで良し。
で、実際にPHPでセッションを使うにはそんな小難しいことを知らんでも専用の関数で楽チン。

>>536
同じじゃない。セッションIDってのは、いわば「鍵」である。
この「鍵」を使って、サーバにあるデータ（セッション・ファイルの中身）にアクセスできる。
鍵だけでは何の意味もない。鍵を見ても鍵でしかない。見て意味のあるデータは、鍵のかかった「箱」に入れるわけだ。
0540nobodyさん2006/10/14(土) 22:28:50ID:8uNXTSbc
if(!_SESSION['login']) { header('blahblah'); }
とかじゃだめってこと？じゃあどうやるの？
セッションIDがわかったとしてもそれがログインしてるか調べないといけないよね？
0541nobodyさん2006/10/14(土) 22:29:40ID:???
総当りが心配ならセッションデータにホスト名入れて照合すればいい
0542nobodyさん2006/10/14(土) 22:30:30ID:???
SNS作る以前にセッションの講義しなきゃならんのか
0543nobodyさん2006/10/14(土) 22:45:04ID:???
SNSにたどり着くまでの壮大な物語の序章だったとは、
このとき誰もが・・・



うんざりした
0544nobodyさん2006/10/14(土) 23:23:22ID:???
open-gorotto ってどうなっちゃったの？
鯖が死んでるみたいだけど。
0545nobodyさん2006/10/15(日) 00:29:11ID:???
少しだけマジレスすると入力と出力がアトミックなhiddenのほうが安全。
どこぞの権威あるサイトみたいにhiddenよりセッションのほうが安全などと言い切ると
ろくに理解も確認もしないで真似するやつが出てくるので非常に危険。
セッション変数にSQL文を入れるやつまで出てくる有様なのでいたずらされないように気をつけてね♪
■ このスレッドは過去ログ倉庫に格納されています