- 1 名前：nobodyさん mailto:sage [2008/12/23(火) 00:36:15 ID:???]
- PHPのフレームワークに関する話題用のスレッド
●国外産●
symfony
ttp://www.symfony-project.com/
code igniter
ttp://codeigniter.com/
Zend Framework
ttp://framework.zend.com/manual/ja/index.html
CakePHP
ttp://www.cakephp.org/
Yii Framework ←New!! (Dec 03, 2008)
ttp://www.yiiframework.com/
●国産
ちいたん
ttp://php.cheetan.net/
Ethna
ttp://ethna.jp/
guesswork
ttp://classic.guesswork.jp/
maple
ttp://kunit.jp/maple/
●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
pc11.2ch.net/test/read.cgi/php/1219581817/
- 179 名前：nobodyさん mailto:sage [2009/01/29(木) 00:07:10 ID:???]
- >>168
Yii使いならメモとかドキュメントとかその他なんでもいいから晒してくれ
- 180 名前：nobodyさん mailto:sage [2009/01/29(木) 01:00:41 ID:???]
- Javaの企業需要はまだなくならない
ASP.NET系も同じく糞ゲイツ派企業の鉄板
PHPはなんだかんだでライトユーザーシェアはなくならない
---かべ---
PerlはもうすでにWebProgのCOBOL
Rubyは永遠に下火
そのた：話題に上らないほどにマイナー
>>176
PHPがだめぽってのはすごく理解できるが、
そこで何ゆえPerlなんかを選んでしまった理由を聞いてみたいｗ
- 181 名前：nobodyさん mailto:sage [2009/01/29(木) 01:21:22 ID:???]
- つうか、web屋ならPerl、PHP、Rubyあたりは一通り理解できて然るべきだろ。
軽量言語如きで信者論争とか、アホらしいっつうかアホそのものだ。
- 182 名前：nobodyさん mailto:sage [2009/01/29(木) 01:35:52 ID:???]
- 理解できるのと実際組めるのとは別物だよなぁ。
昔、簡単な物ならPerlで書けたけど、今はうpロダでさえ作れないかも。
PHPしか書けないWeb屋が居てもいいよねw
- 183 名前：nobodyさん mailto:sage [2009/01/29(木) 01:41:58 ID:???]
- そりゃ理解できるし組めるが、できることなら糞言語は使いたくないんだ。
- 184 名前：nobodyさん mailto:sage [2009/01/29(木) 01:51:42 ID:???]
- 組めないってことは理解できてないんだろ
- 185 名前：nobodyさん mailto:sage [2009/01/29(木) 18:23:40 ID:???]
- 調べてみたけどいまいち情報が無いので聞かせてください。
フレームワークのSSL対応ってどうなっているのでしょうか？
単純にページをhttps://以下に置けばSSL対応になるとかいうのではありません。
http://以下の特定のページに着たらhttps://以下にリダイレクトするというものでもありません。
私が聞きたいのは、SSLページと非SSLページにまたがったアクションで
情報がどのようにセキュアに扱われているかということです。
具体的に言えば、たとえばAmazonなど、非SSLページでカートに入れて、そこからSSLページにとんで
住所などの個人情報とカートの情報を結びつけて会計処理を行えます。
また逆に個人情報を入れてからカートに追加と言う処理もあります。
SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
こういう部分をフレームワークは解決してくれているのでしょうか？
解決してくれているとしたら、どういった設計になっているのでしょうか？
- 186 名前：nobodyさん mailto:sage [2009/01/29(木) 18:26:56 ID:???]
- そこまで気にするならセッションIDなんてアクセス毎に変えればいいじゃん
- 187 名前：nobodyさん mailto:sage [2009/01/29(木) 18:31:21 ID:???]
- というかセッションIDを取れたからってどうなるというのか
- 188 名前：nobodyさん mailto:sage [2009/01/29(木) 18:42:10 ID:???]
- あらためて、明確にしておきます。
私が知りたいのは、フレームワークで
この問題をどう解決しているのか？
または解決していないのか？
ということです。
- 189 名前：nobodyさん mailto:sage [2009/01/29(木) 20:08:05 ID:???]
- 百聞は一見にしかず、実際に見てみるのが早かろう
- 190 名前：nobodyさん mailto:sage [2009/01/29(木) 20:15:44 ID:???]
- 所詮PHPプログラマ的なやりとりでワロタｗ
PHPはアンセキュアな糞フレームワークばかり
secure属性もしらなそうだな。
- 191 名前：nobodyさん mailto:sage [2009/01/29(木) 20:45:27 ID:???]
- フレームワークでって言われても何のフレームワークの話なのか
PHPにフレームワーク1つしかないと思ってるんだろうか
- 192 名前：nobodyさん mailto:sage [2009/01/29(木) 20:52:01 ID:???]
- セキュアなシステムを組んだ経験が浅い子の戯言です。
気にしないでやってください。
なぜなら、フレームワークに依存するレベルの話じゃない。
フレームワークを使ってどう実装するかという設計の問題です。
- 193 名前：nobodyさん mailto:sage [2009/01/29(木) 21:12:16 ID:???]
- Yiiはこんな感じ
ttp://www.yiiframework.com/doc/guide/topics.security
- 194 名前：nobodyさん mailto:sage [2009/01/29(木) 22:59:54 ID:???]
-
>>185,188
- 195 名前：nobodyさん mailto:sage [2009/01/29(木) 23:22:59 ID:???]
- >>194
俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。
>>193で端的に答えられているが、それ以外はわざとか限界か知らんが
ことごとくピントはずれでいい感じだなｗ
で、そのYiiのようなクッキーValidationは他のフレームワークにもあったような。
- 196 名前：195 mailto:sage [2009/01/29(木) 23:33:39 ID:???]
- って書いたが、これはCookieの改竄はチェックできてもそもそものセッションキーを盗まれた
場合には意味ないね。
考えられるシンプルな対策で、非セキュアなページではセッションを使わない、もしくは
セキュアページと共有しないってのは正味ありえないか
- 197 名前：nobodyさん mailto:sage [2009/01/29(木) 23:48:44 ID:???]
- 非セキュアなページと、セキュアなページを同一セッションで結ぶのはユーザーの利便性の問題。
セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
その上で、承認後はセッションIDを毎ページ切り替えるってのが普通。
非セキュアなゾーンでセッションキーを盗んでも、匿名の個人情報が見れるだけで
実害はほとんどない。
これはフレームワーク層じゃなくて、ビジネスロジック層で実装するもんだよ。
- 198 名前：nobodyさん mailto:sage [2009/01/30(金) 00:47:54 ID:???]
- だからアクセス毎にセッションID変えればええやん
- 199 名前：nobodyさん mailto:sage [2009/01/30(金) 00:56:28 ID:???]
- YOU全部HTTPSでやっちゃいなよ
- 200 名前：nobodyさん mailto:sage [2009/01/30(金) 02:29:11 ID:???]
- 俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。 （ｷﾘｯ
- 201 名前：nobodyさん mailto:sage [2009/01/30(金) 03:47:52 ID:???]
- 煽ってるとこすまんが、同意するよ。
PythonやらRubyやらPerlがphpと比べてどうのとか、
ぜんぜん関係なかったし。
- 202 名前：nobodyさん mailto:sage [2009/01/30(金) 08:04:53 ID:???]
- >>197
>セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
これがわからん。どうやって確認するの？
例えばユーザでログインした後、トップページからお問い合わせフォーム（もしくはその確認画面）に進んだだけで
パスワード入力を求められるようなサイトは現実的かな？
Amazonみたいに、重要な操作の前にいちいちパスワード入力を求めるっていう感じかな。
それとも、セッションに頼らない確認方法があるんだろうか。
流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
- 203 名前：nobodyさん mailto:sage [2009/01/30(金) 08:27:30 ID:???]
- だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
アマゾンのように、長いセッションを維持するサイトでは、重要な操作の前に、
必ずパスワードを確認させて、セキュアなセッションは短くしている。
Yahooでもクッキーを数種類使いつつ、クラムというフォーム追跡を埋め込んで、
通常ログイン状態とセキュアログイン状態を識別、追跡している。
だから、パスワードの再確認を求められるケースとそうじゃないケースがある。
そういうギミックを持ってないところは、ショップなどのように金銭が絡むところは
まるっとHTTPSで実装する。
> 流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
それはどういうレイヤーで話をしてるの？
プロトコルの欠陥？ネットワーク盗聴？ブラウザーのバグ？
- 204 名前：nobodyさん mailto:sage [2009/01/30(金) 08:44:58 ID:???]
- >>202
盗まれても良いための「ワンタイム」トークンじゃないの？
- 205 名前：nobodyさん mailto:sage [2009/01/30(金) 10:08:00 ID:???]
- >>203
クッキーが盗まれる、っていう現象で想定のメインは「ネットワーク盗聴」じゃね？
他にもあるのか俺は知らんが。
例えばXSSで盗まれるのであればSSLなんて関係ないわけだし
>>204
毎回セッションIDを変えるってので兼用できてそうな気がするから、併用して
冗長にしてチェック、かな？
どのみちタイムアウトの設定次第の様な気がする。
- 206 名前：nobodyさん mailto:sage [2009/01/30(金) 10:33:33 ID:???]
- >>205
ネットワーク盗聴ならSSL下では問題ないって前提でいいわけだよな。
(SSL下でも解読できるとか行っちまったら元もこもない）
SSL下でsecure属性をつけたクッキーを出すのが普通なんで、
復路の盗聴はないし、ワンタイムトークンを使う限り
タイムアウトはセキュアセッションと同等でいいよな。
あんまりにも普通なこと過ぎて書くのが恥ずかしくなってきたわ。
- 207 名前：nobodyさん mailto:sage [2009/01/30(金) 10:39:58 ID:???]
- >>203
> だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
そういう場合に、どっちの方式をとるかは設計の問題だね。
だけどフレームワークの意味をもう一度思い出してほしい。
汎用的で複雑な処理を簡単に実装できることだ。
重要な操作の前に確認したいのなら、
プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。
- 208 名前：nobodyさん mailto:sage [2009/01/30(金) 10:43:17 ID:???]
- >>197
> 匿名の個人情報が見れるだけで実害はほとんどない。
これは笑う所かいな？ｗ
個人情報＝本名・住所等
匿名の本名・住所等が見れるだけで実害はほとんどない。
匿名になってないじゃないか〜い。
- 209 名前：nobodyさん mailto:sage [2009/01/30(金) 10:46:19 ID:???]
- >別ウインドウを出したとき問題になる。
AmazonやYahooでいつ別ウインドウが出るってんだ
その手のサイトでログイン後に別ウインドウとかアホ設計だろうに
- 210 名前：nobodyさん mailto:sage [2009/01/30(金) 10:49:28 ID:???]
- >>209
別ウインドウってのは人間が出すんだよ。
ネットワークが遅いから、過去の履歴の詳細をいくつも別ウインドウで開くとか
（一つのウインドウの内容を見ている間に、他のページの読み込みが終わっている）
- 211 名前：nobodyさん mailto:sage [2009/01/30(金) 10:51:55 ID:???]
- >>208
もしかしてそこが笑うところ？
> 個人情報＝本名・住所等
そんな決めつけでよくやってられるな。
たとえば、性別とか好みとかカートの中身とか、クリック動向とか
個人を特定できないが個人に関係する情報も個人情報だろが
- 212 名前：nobodyさん mailto:sage [2009/01/30(金) 10:52:36 ID:???]
- >>207
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。
ない。
- 213 名前：nobodyさん mailto:sage [2009/01/30(金) 10:55:22 ID:???]
- 毎回セッションIDを変える方法は
連続でリロードすると問題になる。
サーバーでは値が変わっているが、
クライアントでは新しい値を受け取っていないなど。
- 214 名前：nobodyさん mailto:sage [2009/01/30(金) 10:55:54 ID:???]
- >>207
> だけどフレームワークの意味をもう一度思い出してほしい。
> 汎用的で複雑な処理を簡単に実装できることだ。
セキュアセッションは汎用的でも複雑でもないだろ。
関数一発挟むだけなのに、それをプロパティで設定しろってか。
- 215 名前：nobodyさん mailto:sage [2009/01/30(金) 10:57:40 ID:???]
- >>213
あほ？
別ウインドウを出したり、連続リロードで動作しちゃいけないのがセキュアゾーン
- 216 名前：nobodyさん mailto:sage [2009/01/30(金) 10:57:52 ID:???]
- セキュアページに入る前に
必ず認証が必要だというが、
Amazonはそうなっていない。
これを実現できるフレームワークは皆無ってことでおｋ？
- 217 名前：nobodyさん mailto:sage [2009/01/30(金) 11:00:03 ID:???]
- >>215
だが、Amazonは別ウインドウを出しても、連続リロードしても問題ない。
これを実現できるフレームワークは皆無ってことでおｋ？
- 218 名前：nobodyさん mailto:sage [2009/01/30(金) 11:01:38 ID:???]
- >>216
アマゾンはそうなってるよ。
すでにセキュアトークンを持ってれば別
フレームワーク乞食乙
- 219 名前：nobodyさん mailto:sage [2009/01/30(金) 11:04:46 ID:???]
- >>218
それは、ブラウザ起動して初めてログインした場合だろ。
一度ログインしていれば、非セキュアページから
セキュアページに入るときにパスワードは要求されない。
一度注文履歴を見たあとで、トップに戻れ。
トップから、もう一度注文履歴を見る間にパスワードを聞かれるか？
- 220 名前：nobodyさん mailto:sage [2009/01/30(金) 11:12:49 ID:???]
- >>214
> 関数一発挟むだけなのに、それをプロパティで設定しろってか。
関数一発挟むだけじゃないな。
Windowsプログラミングじゃあるまいし。
パスワード入力ダイアログを出して終わりじゃないんだよ。
認証が必要になった場合に、他のページに飛ばさないといけない。
そこから戻らないといけない。
一回目（認証前）と戻ったときの二回目（認証後）で違う処理をしないといけない。
必ずパスワードを出すというわりに、認証後はパスワードを出さないという風に矛盾している。
- 221 名前：nobodyさん mailto:sage [2009/01/30(金) 11:23:06 ID:???]
- >>207
> あと、毎回セッションIDを変える方法は、
> 別ウインドウを出したとき問題になる。
ただ単に、どっちかのセッションが使えなくなるだけじゃない？
問題なし
- 222 名前：nobodyさん mailto:sage [2009/01/30(金) 11:24:24 ID:???]
- >>219
それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください
>>220
よーくわかった。(ry
- 223 名前：nobodyさん mailto:sage [2009/01/30(金) 11:25:39 ID:???]
- >>219
> すでにセキュアトークンを持ってれば別
ってちゃんと書いてるだろ。
- 224 名前：nobodyさん mailto:sage [2009/01/30(金) 11:39:10 ID:???]
- そもそもAmazonはJavaで独自実装だから
PHPフレームワークスレでこんな機能が全て実現できるフレームワークは
PHPにないよね！って言われた所でなんなんだっていう
ちなみにPerlでもJavaでもASPでもそんなフレームワークはない
その辺は自分で実装する
- 225 名前：nobodyさん mailto:sage [2009/01/30(金) 12:33:45 ID:???]
- >>207
>だけどフレームワークの意味をもう一度思い出してほしい。
>
>汎用的で複雑な処理を簡単に実装できることだ。
>重要な操作の前に確認したいのなら、
>プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
>
>YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
>作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
これがフレームワークが提供すべき汎用的な機能かと言うとどうだろうね？
- 226 名前：225 mailto:sage [2009/01/30(金) 12:35:02 ID:???]
- 追記：
「Webアプリケーションフレームワークが」提供すべきかどうか、ね。
- 227 名前：nobodyさん mailto:sage [2009/01/30(金) 12:46:45 ID:???]
- 重大なセキュリティに絡む部分をオープンなフレームワークで吸収したら
そこにバグがあったらそれ使ってるシステムみんな死亡じゃん
クリティカルな部分は独自に実装するからバグがあってもなんとななるわけで
- 228 名前：nobodyさん mailto:sage [2009/01/30(金) 13:17:58 ID:???]
- >>227
んなこといったら、プレースホルダ使いたい、使わせたい為だけにPEAR::DB使ってた人間とか涙目だろ。
実際そういった判断は、凡PGに任せるより遙かにセキュアだったと思うがな
フレームワーク（というか基底ライブラリ）の有用性の一面を完全否定っすか。
- 229 名前：nobodyさん mailto:sage [2009/01/30(金) 13:34:34 ID:???]
- >>227
問題はバグがどうたらじゃないよ
設計や計画にはちゃんとした理解が必要だが、コーディングが難しかったり
面倒だったりするわけじゃないからFWに任せる内容じゃないってことだよ。
コーディングの助けっていう意味程度なら、どのFWにもセキュアセッション
を扱う機能や、ワンタイムトークンを自動でハンドリングするフォーム要素とか
一通りのものは揃ってる。
が、ページ遷移設計まで自動化してほしいとは思わないけどな。
PieceFrameworkあたりなら、その辺はすでに実装済みかもしれんけど。
- 230 名前：nobodyさん mailto:sage [2009/01/30(金) 13:36:33 ID:???]
- CakePHPは実際AuthComponentで誰でもログインできるってバグ出して死亡したけどなｗ
ああいうのはFWで吸収しない方がいい
- 231 名前：nobodyさん mailto:sage [2009/01/30(金) 13:38:02 ID:???]
- >>229
きちんと実装されるかどうかじゃなくて、フレームワークの場合は
そういうバグがありましたって公開されちゃうから、フレームワーク使ってるのバレると
悪用されるってことじゃないの？
独自実装ならクソみたいな実装でも中はどうなってるかアタックするまで解らんのだし
- 232 名前：nobodyさん mailto:sage [2009/01/30(金) 13:43:38 ID:???]
- >>230
言ってみれば各フレームワークも、それぞれの独自実装の固まりだからな
ある程度のライブラリくらい共用して欲しいような気もする今日この頃。
APIも統一されるし。
- 233 名前：nobodyさん mailto:sage [2009/01/30(金) 13:53:53 ID:???]
- cookieのsecure属性を理解してないヤツが混じってる予感。
- 234 名前：nobodyさん mailto:sage [2009/01/30(金) 13:57:42 ID:???]
- >>230
それは、バグがあるのがわるいだけだろｗ
- 235 名前：nobodyさん mailto:sage [2009/01/30(金) 14:24:52 ID:???]
- ごっつい根本的な質問で恐縮ですが
PHPって複数のセッションを同時に利用することってできるの？
それができるかできないかで、ものすごく話が変わってくるような。
・・・できないんだろうな。$_SESSION だもんな・・・
- 236 名前：nobodyさん mailto:sage [2009/01/30(金) 14:32:51 ID:???]
- >>235
微妙にスレチだぞ＞くだすれ行けって感じだが・・・
無理やりFWレイヤーの話に持ってくると、Zend_Sessionではセッションの配列で
ネームスペース的な扱いをして、使い分けている。
でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
分割して持てるか？って話をしたいわけだよな？
PHPが受け入れるセッションID自体は一つ。それは正しい。
解は二つ。
クッキーと独自のバックエンドを使って、自前でセッション機構を作る。
セッションを理解してれば、簡単。
ちなみにYahoo!はPHPでこの方式を採用してる。
もう一つは、セッションそのものは永続化しておいて、セッションネームスペース内
に侵入を許す際に、そのネームスペースに対する適切なアクセスかどうかを個別のクッキーで検証する。
ZFで実装してるやつはたぶんこれがFA
- 237 名前：nobodyさん mailto:sage [2009/01/30(金) 14:42:03 ID:???]
- >>234
いや
これがCakePHPだから、セキュリティ情報として全世界にこういうバグありますよって公開されちゃうわけよ。
その情報を見てクラッカーが仕掛けてくる可能性が高い。
もし仮に自分で全て実装したものに同じバグがあったとしても、よっぽどしっかりクラックされない限り、誰にも知られることはない。
- 238 名前：nobodyさん mailto:sage [2009/01/30(金) 14:47:27 ID:???]
- >>236
> でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
> 分割して持てるか？って話をしたいわけだよな？
ですです。それができれば、盗聴（非SSL）でセッションハイジャックされたとしても
その中には非セキュア用の情報しかないし、セキュア用のセッション（ログイン状態）等と
簡単に切り分けできるなーと。
ただ、他の言語の実装をみても、「セッション」ってもの自体の考え方が、どうやらサーバ-
クライアントで1対1っぽい？
＞解は二つ。
もう一つ、セッションはあくまでsecureで利用して、非セキュアな情報はみんなCookieに
放り込めばいいじゃない！ってふと思いついた。
最低4KB×20(50？)個なら、とりあえず普通に使えそうとか。
- 239 名前：nobodyさん mailto:sage [2009/01/30(金) 14:54:52 ID:???]
- Cookie切ってる奴多いのに通用するのかそれ
セキュリティソフトのせいで動きませんみたいなサイトになるぞ
- 240 名前：nobodyさん mailto:sage [2009/01/30(金) 15:02:01 ID:???]
- Cookie切ってる奴多い？
根拠は？
- 241 名前：nobodyさん mailto:sage [2009/01/30(金) 15:09:40 ID:???]
- >>239
もしかしてセッションIDをフォームに手で埋めるのが標準？
まじでか
- 242 名前：nobodyさん mailto:sage [2009/01/30(金) 15:14:39 ID:???]
- >>239
Cookie切ったら普通にセッション動かないけど？
- 243 名前：nobodyさん mailto:sage [2009/01/30(金) 15:15:10 ID:???]
- みなさ〜ん、そろそろスレチですよっと。
- 244 名前：nobodyさん mailto:sage [2009/01/30(金) 15:18:00 ID:???]
- ほかの言語の話になってるよりましだし、いいんじゃないの？
- 245 名前：nobodyさん mailto:sage [2009/01/30(金) 15:32:12 ID:???]
- SSLの話題が出ているので便乗質問。
共有SSLに対応しているフレームワークってある？
www.aaa.com/
https://www.rental-server.com/~aaa.com/
こうなっているときに、ドメイン名違うし、パス違うしで
セッション保てないわで、困るんだよね。
- 246 名前：nobodyさん mailto:sage [2009/01/30(金) 15:33:30 ID:???]
- クッキー切ってるような変人相手にする必要なし
むしろブラクラに飛ばしてやれ
- 247 名前：nobodyさん mailto:sage [2009/01/30(金) 15:34:14 ID:???]
- Cookie切ってセッション動かないとかどんなクソ実装だよ
それじゃ携帯サイト対応できねーじゃん
- 248 名前：nobodyさん mailto:sage [2009/01/30(金) 15:39:41 ID:???]
- うーん。セキュリティ周りをちゃんと説明しているサイトが見つからない。
クッキー切っている場合（携帯対応）のセッションで
cookieにsecure属性をつけた場合の動作と同じことを
ちゃんとやっているのか確証を得たいが見つからない。
- 249 名前：nobodyさん mailto:sage [2009/01/30(金) 15:48:16 ID:???]
- Cookieが普通で携帯が異常なだけだろ。
- 250 名前：nobodyさん mailto:sage [2009/01/30(金) 15:54:21 ID:???]
- DoCoMoの携帯がクッキー非対応で異常だからってことで、
非対応にしてるサイトってあんまないけどな。
結局Cookie使わなくてもセッションは維持できる。
- 251 名前：nobodyさん mailto:sage [2009/01/30(金) 16:09:01 ID:???]
- >>247
携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。
PerlならMobaSifがあるけどなぁ。
- 252 名前：nobodyさん mailto:sage [2009/01/30(金) 16:17:17 ID:???]
- >>245
>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう
クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか
- 253 名前：nobodyさん mailto:sage [2009/01/30(金) 16:23:31 ID:???]
- URLにセッションID差し込んでCookie使わない実装にするのなんて普通だろ
IDはアクセス毎に変える
- 254 名前：nobodyさん mailto:sage [2009/01/30(金) 16:30:00 ID:???]
- >>253
これを言い出すと、もうセッションIDのクッキーをsecureにする意味もないな
- 255 名前：nobodyさん mailto:sage [2009/01/30(金) 16:40:23 ID:???]
- >>253
PHPの$_SESSION自体そういう仕様になってなかったか？
- 256 名前：nobodyさん mailto:sage [2009/01/30(金) 17:04:49 ID:???]
- use_trans_sid
- 257 名前：nobodyさん mailto:sage [2009/01/30(金) 17:05:43 ID:???]
- まぁ、URLに差し込むだけじゃ携帯全機種対応は無理だけどな。
- 258 名前：nobodyさん mailto:sage [2009/01/30(金) 18:19:42 ID:???]
- っていうか議論に問題だらけの端末の話を持ってくるのは暴論じゃないか？
携帯サイト対応ってそれだけで一仕事だよ。
- 259 名前：nobodyさん mailto:sage [2009/01/31(土) 01:06:04 ID:???]
- SSL対応議論、参考になります！(ｷﾘｯ)
この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな〜＞＜
- 260 名前：nobodyさん mailto:sage [2009/01/31(土) 02:01:11 ID:???]
- 誰も十分に理解できていないから、
はっきりとした答えが出せないんだろうな。
- 261 名前：nobodyさん mailto:sage [2009/01/31(土) 02:27:29 ID:???]
- 土日を利用して勉強してみましょう
継続を使ったWEBアプリ
www.thinkit.co.jp/article/74/1/
Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
www.kahua.org/
セッションも良いけど継続もね☆
- 262 名前：nobodyさん mailto:sage [2009/01/31(土) 04:23:52 ID:???]
- クッキーはサイズの制限があるから結局セッションを使うとして、
そのセッションをどうやって実現しているかだ。
セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）
問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。
もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。
そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。
- 263 名前：nobodyさん mailto:sage [2009/01/31(土) 07:40:31 ID:???]
- >>262
おまいさんの理解が浅いということだけはわかった。
何も書かないと単なる煽りと思われるので一つだけ例示すると、
> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。
それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。
情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。
- 264 名前：nobodyさん mailto:sage [2009/01/31(土) 11:43:58 ID:???]
- >セキュアな情報を表示するためのトークン
それって一般にはセッションIDって呼ぶと思うの。
- 265 名前：nobodyさん mailto:sage [2009/01/31(土) 11:53:41 ID:???]
- いいえ
- 266 名前：nobodyさん mailto:sage [2009/01/31(土) 12:16:29 ID:???]
- おせっかいなオレが例を出したるわ。
・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす
すくなくとも$uniqをセッションIDとは言わない。
- 267 名前：nobodyさん mailto:sage [2009/01/31(土) 12:29:26 ID:???]
- >>266
で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。
おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。
- 268 名前：nobodyさん mailto:sage [2009/01/31(土) 12:48:08 ID:???]
- なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
- 269 名前：nobodyさん mailto:sage [2009/01/31(土) 12:55:21 ID:???]
- そんなに欲しかったら開発リクエストすればいいんじゃない？
投票が集まればサクッと作るでしょ。
- 270 名前：nobodyさん mailto:sage [2009/01/31(土) 13:09:29 ID:???]
- >>268
>>266の処理を一行で書かれたら絶対に読みたくない。
- 271 名前：nobodyさん mailto:sage [2009/01/31(土) 13:31:24 ID:???]
- >>268が冗長なだけ
- 272 名前：nobodyさん mailto:sage [2009/01/31(土) 13:32:03 ID:???]
- >>268じゃなくて、>>266
- 273 名前：nobodyさん mailto:sage [2009/01/31(土) 15:14:35 ID:???]
- >>262-272
マジで参考になります＾＾（もっとやれ的な意味で）
- 274 名前：nobodyさん mailto:sage [2009/01/31(土) 15:30:40 ID:???]
- フレームワークを勘違いしたひとが沸いて荒らしてくれたおかげでスレの進みが半端ネェ！
たまにこういうことがあるから面白い
- 275 名前：nobodyさん mailto:sage [2009/01/31(土) 15:51:36 ID:???]
- >>274
フレームワークの話題も振れずかといって実装についての話もできないのに
レスするのって寂しくならないか？
- 276 名前：nobodyさん mailto:sage [2009/01/31(土) 15:51:43 ID:???]
- >>266
そこら辺の処理をちゃんと説明している本って無い？
- 277 名前：nobodyさん mailto:sage [2009/01/31(土) 15:55:18 ID:???]
- >>268
> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。
ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。
- 278 名前：nobodyさん mailto:sage [2009/01/31(土) 16:03:23 ID:???]
- 汎用的ではない。
インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。
- 279 名前：nobodyさん mailto:sage [2009/01/31(土) 16:04:02 ID:???]
- >>277
それはフレームワークのよいところを語りたかったわけ？
|
 |
