【PHP】フレームワークについて語るスレ12【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/12/23(火) 00:36:15ID:???●国外産●
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
http://pc11.2ch.net/test/read.cgi/php/1219581817/
0237nobodyさん
2009/01/30(金) 14:42:03ID:???いや
これがCakePHPだから、セキュリティ情報として全世界にこういうバグありますよって公開されちゃうわけよ。
その情報を見てクラッカーが仕掛けてくる可能性が高い。
もし仮に自分で全て実装したものに同じバグがあったとしても、よっぽどしっかりクラックされない限り、誰にも知られることはない。
0238nobodyさん
2009/01/30(金) 14:47:27ID:???> でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
> 分割して持てるか？って話をしたいわけだよな？
ですです。それができれば、盗聴（非SSL）でセッションハイジャックされたとしても
その中には非セキュア用の情報しかないし、セキュア用のセッション（ログイン状態）等と
簡単に切り分けできるなーと。
ただ、他の言語の実装をみても、「セッション」ってもの自体の考え方が、どうやらサーバ-
クライアントで1対1っぽい？
＞解は二つ。
もう一つ、セッションはあくまでsecureで利用して、非セキュアな情報はみんなCookieに
放り込めばいいじゃない！ってふと思いついた。
最低4KB×20(50？)個なら、とりあえず普通に使えそうとか。
0239nobodyさん
2009/01/30(金) 14:54:52ID:???セキュリティソフトのせいで動きませんみたいなサイトになるぞ
0240nobodyさん
2009/01/30(金) 15:02:01ID:???根拠は？
0243nobodyさん
2009/01/30(金) 15:15:10ID:???0244nobodyさん
2009/01/30(金) 15:18:00ID:???0245nobodyさん
2009/01/30(金) 15:32:12ID:???共有SSLに対応しているフレームワークってある？
http://www.aaa.com/
https://www.rental-server.com/~aaa.com/
こうなっているときに、ドメイン名違うし、パス違うしで
セッション保てないわで、困るんだよね。
0246nobodyさん
2009/01/30(金) 15:33:30ID:???むしろブラクラに飛ばしてやれ
0247nobodyさん
2009/01/30(金) 15:34:14ID:???それじゃ携帯サイト対応できねーじゃん
0248nobodyさん
2009/01/30(金) 15:39:41ID:???クッキー切っている場合（携帯対応）のセッションで
cookieにsecure属性をつけた場合の動作と同じことを
ちゃんとやっているのか確証を得たいが見つからない。
0249nobodyさん
2009/01/30(金) 15:48:16ID:???0250nobodyさん
2009/01/30(金) 15:54:21ID:???非対応にしてるサイトってあんまないけどな。
結局Cookie使わなくてもセッションは維持できる。
0251nobodyさん
2009/01/30(金) 16:09:01ID:???携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。
PerlならMobaSifがあるけどなぁ。
0252nobodyさん
2009/01/30(金) 16:17:17ID:???>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう
クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか
0253nobodyさん
2009/01/30(金) 16:23:31ID:???IDはアクセス毎に変える
0256nobodyさん
2009/01/30(金) 17:04:49ID:???0257nobodyさん
2009/01/30(金) 17:05:43ID:???0258nobodyさん
2009/01/30(金) 18:19:42ID:???携帯サイト対応ってそれだけで一仕事だよ。
0259nobodyさん
2009/01/31(土) 01:06:04ID:???この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな〜＞＜
0260nobodyさん
2009/01/31(土) 02:01:11ID:???はっきりとした答えが出せないんだろうな。
0261nobodyさん
2009/01/31(土) 02:27:29ID:???継続を使ったWEBアプリ
http://www.thinkit.co.jp/article/74/1/
Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
http://www.kahua.org/
セッションも良いけど継続もね☆
0262nobodyさん
2009/01/31(土) 04:23:52ID:???そのセッションをどうやって実現しているかだ。
セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）
問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。
もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。
そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。
0263nobodyさん
2009/01/31(土) 07:40:31ID:???おまいさんの理解が浅いということだけはわかった。
何も書かないと単なる煽りと思われるので一つだけ例示すると、
> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。
それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。
情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。
0264nobodyさん
2009/01/31(土) 11:43:58ID:???それって一般にはセッションIDって呼ぶと思うの。
0265nobodyさん
2009/01/31(土) 11:53:41ID:???0266nobodyさん
2009/01/31(土) 12:16:29ID:???・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす
すくなくとも$uniqをセッションIDとは言わない。
0267nobodyさん
2009/01/31(土) 12:29:26ID:???で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。
おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。
0268nobodyさん
2009/01/31(土) 12:48:08ID:???0269nobodyさん
2009/01/31(土) 12:55:21ID:???投票が集まればサクッと作るでしょ。
0274nobodyさん
2009/01/31(土) 15:30:40ID:???たまにこういうことがあるから面白い
0277nobodyさん
2009/01/31(土) 15:55:18ID:???> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。
ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。
0278nobodyさん
2009/01/31(土) 16:03:23ID:???インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。
0281nobodyさん
2009/01/31(土) 16:45:58ID:???ヒントやるから実装は自分でやれな。
SSL_Login_Class
セキュアにするべきページの一覧や正規表現を設定配列に入れておく。
全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
セキュアページにhttpでアクセスしていたら、httpsにリダイレクト
セキュアトークンを持っていなければ、ログインページにリダイレクト
ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）
セキュアトークンのサーバー側のデータは、セッションでも独自のファイルやデータベースにも格納可能。
ハッシュはsha1でもそれ以外でも選択可能。
以上のことをやってくれるクラス。
使い方は簡単。CakePHP風に言えば共通のコントローラAppControllerの
componentsに上記のクラスを入れるだけ。これとセキュアページのリストさえあれば
具体的な実装を書かなくてすむ。
0282nobodyさん
2009/01/31(土) 16:52:07ID:???日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
0284nobodyさん
2009/01/31(土) 17:13:02ID:???>>266に書いてあるのは、セキュアなサイトを作る時のHelloWorld
実サイトでは、Yahooにしろamazonでも楽天でも>>266とは別のロジック。
そういうロジックを設定でインジェクションできないなら汎用的とは言わない。
0285nobodyさん
2009/01/31(土) 17:15:21ID:???>>281のはロジックの一つだよ。
別のロジックを使いたければ、別のロジックを実装したクラスを
AppControllerのcomponentsに設定すればいいだけ。
これで汎用的になりましたね（笑）
0286nobodyさん
2009/01/31(土) 17:18:05ID:???0287nobodyさん
2009/01/31(土) 17:20:51ID:???0288nobodyさん
2009/01/31(土) 17:22:06ID:???本当に十分なのか？ FWが持っている認証クラスが
このようなロジックになっているのか？
>>266のロジックなのか？ それともYahoo、Amazon、楽天のロジックのなのか？
それが、そもそもの>>185,188の質問だろうが。
> フレームワークのSSL対応ってどうなっているのでしょうか？
それで答えは？
0289nobodyさん
2009/01/31(土) 17:24:30ID:???結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
ロジックを実装したクラスを設定するわけだろ。
それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
>> フレームワークのSSL対応ってどうなっているのでしょうか？
> それで答えは？
対応する必要なし。
0290nobodyさん
2009/01/31(土) 17:26:44ID:???> それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
そのロジックをお前は毎回作るのか？
そのロジックは使いまわし出来るだろ？
それを汎用的という。
0292nobodyさん
2009/01/31(土) 17:28:05ID:???考え方がおかしいね。 >>281のクラスを使ってサービスを実装するんじゃない。
なにかのサービスを実装したとき、>>281のクラスを利用する。
考え方が逆だよ。
0294nobodyさん
2009/01/31(土) 17:29:28ID:???元はといえば、お前さんの書いたクラスのサンプルが汎用的じゃないわけだろ。
ロジックはサイトの管理ポリシーによって違うでしょ。
それをカバーできるようは汎用的な設計を示してから言ってくれ。
0297nobodyさん
2009/01/31(土) 17:32:13ID:???お前はロジックという言葉の使い方がおかしい。
管理ポリシーは違っても、それを実装するロジック（数パターンある）は同じ。
ロジックと管理ポリシーは違うもの。
0299nobodyさん
2009/01/31(土) 17:38:04ID:???あのなぁ。お前、コンクリートと汎用的とは別の考え方だよ。
GUIの例で言えば分かるだろ。
テキストボックスはコンクリートクラスであるが、
汎用的に使われるパーツだ。
抽象クラスと汎用的つ使えるクラスをごっちゃにするなよ。
0301nobodyさん
2009/01/31(土) 17:42:09ID:???0302nobodyさん
2009/01/31(土) 17:42:45ID:???いや常識（笑）
汎用的なパーツは、一つのパーツを複数のサイトで使える物。
それ以外の意味なんて無いだろｗ
まさか今まで抽象クラスの話をしていたのか。驚きだｗ
0303nobodyさん
2009/01/31(土) 17:48:13ID:???この質問をしたのは正しかった。 ↓
> 282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???
> それのどこが汎用的なんだよ。個別実装べったりじゃん。
> 日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
>
> 283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???
> >>282
> お前にとって汎用的とはどういうことを指す言葉なんだ？
>
> 例を出して説明したまえ。
この質問の時点で抽象クラスのことって言ってくれれば話は早かったんだが。
ちゃんと質問に答えてくれていれば
この時点で、君の汎用的ってのは抽象クラスのことね（笑）で終わっていた。
0304nobodyさん
2009/01/31(土) 17:53:26ID:???> フレームワークのSSL対応ってどうなっているのでしょうか？
0305nobodyさん
2009/01/31(土) 17:53:36ID:???>>303 熱いねぇ
>>280は汎用的なクラスと書いてるなぁ。
>>281は個別実装でも別サイトで利用できたら汎用的なんだってさ。
汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
少なくともコンクリートのことじゃないと思うが、まぁ個人的な見解だからいいや。
それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
> こういう部分をフレームワークは解決してくれているのでしょうか？
> 解決してくれているとしたら、どういった設計になっているのでしょうか？
さすが、こういうレベルの人の頭の中は面白い。
0307nobodyさん
2009/01/31(土) 17:55:39ID:???> 少なくともコンクリートのことじゃないと思うが
それは無いｗ
0308nobodyさん
2009/01/31(土) 17:57:54ID:???> それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
別に、分かりやすく言い換えただけで
汎用的なクラスという言い方でもいいが？
0309nobodyさん
2009/01/31(土) 17:59:46ID:???こんないい加減な言葉で喧嘩するなｗ みっともない。
0310nobodyさん
2009/01/31(土) 18:02:05ID:???> フレームワークのSSL対応ってどうなっているのでしょうか？
0311nobodyさん
2009/01/31(土) 18:06:32ID:???> いや常識（笑）
> 汎用的なクラスは、一つのクラスを複数のサイトで使える物。
> それ以外の意味なんて無いだろｗ
先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？
0312nobodyさん
2009/01/31(土) 18:07:49ID:???複数のサイトで使えないクラス。
それがビジネスロジックを記述したクラス
0313nobodyさん
2009/01/31(土) 18:39:23ID:???>>302の定義でも汎用的ではないってことで落ち着きそうですね
0314nobodyさん
2009/01/31(土) 19:12:22ID:???0315nobodyさん
2009/01/31(土) 20:17:12ID:???そうか？
手法に致命的な欠陥がない限り多分そのまま普通に使えるし、使ったなりのシステムになると思うんだが。
ただ単に、>>313(とか>>282？)がそのやり方を使いたくないだけではないかとちょっと思った。
0316nobodyさん
2009/01/31(土) 20:31:55ID:???0317nobodyさん
2009/01/31(土) 20:46:34ID:???リダイレクトがちょっと引っかかるがそこは適当な処理に読み替えるとして、
致命的な欠陥があるなら指摘してみたらいいじゃない。正直煽りうざい
0318nobodyさん
2009/01/31(土) 21:02:59ID:???煽り？どこが。
0319nobodyさん
2009/01/31(土) 21:03:44ID:???0320nobodyさん
2009/01/31(土) 21:05:32ID:???0321nobodyさん
2009/01/31(土) 21:06:31ID:???まあ、好みの問題はあるだろうが。
俺なら設定依存じゃなくてコントローラから明示的に呼び出す方式にするかな。
フレームワークにもよるだろうし、どっちの方法も一長一短だけど。
0322nobodyさん
2009/01/31(土) 21:06:54ID:???どういう理由で売り上げが落ちるんだよｗ
0324nobodyさん
2009/01/31(土) 21:08:19ID:???0326nobodyさん
2009/01/31(土) 21:10:24ID:???0331nobodyさん
2009/01/31(土) 21:15:55ID:???0332nobodyさん
2009/01/31(土) 21:18:24ID:???いっているやつがいるかと思えば、話がすすんでみれば
結局、いろんなことを考えないといけないってことになってしまったな。
だからフレームワークに入れておいて簡単に使えるようにするべきだというのに。
0333nobodyさん
2009/01/31(土) 21:24:59ID:???「汎用的なカレー調理器具を考案しました」って言ってる奴に
「それじゃボルシチには使えないから汎用的じゃねえよ」
「うちは蕎麦屋だから関係ねえよ」って言ってるようなもんだな。
0334nobodyさん
2009/01/31(土) 21:25:37ID:???> 全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
> セキュアページにhttpでアクセスしていたら、httpsにリダイレクト
ここと、
> セキュアトークンを持っていなければ、ログインページにリダイレクト
> ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
> ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）
これは別の処理
で、どちらも実は元の流れの、セキュアセッションと非セキュアセッションの持ち方について、
直接は関係ないじゃないかｗ
どう発展させるつもりだったんだろうと気にはなるが
0336nobodyさん
2009/01/31(土) 21:31:24ID:???挙句の果てに、
「それカレー調理器具じゃねーか。そんなの汎用的とはいえない。
いろんな調理器具をはめ込める規格を作れ。」
といっているやつまでいるから手に負えないｗ
■ このスレッドは過去ログ倉庫に格納されています