【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/
0175nobodyさん
2009/01/28(水) 15:17:58ID:???あと金持ち属性もあるか。
PHPERは差別はされてるかもしれないけど、虐殺はされてないし、
病院ごとテロリストをぶっとばすのもしてないぞ、なにより金持ちでもないし。
...いや、この先IT不況が来たら大量に首を切られて虐殺されるかも...
0176nobodyさん
2009/01/28(水) 15:47:25ID:???顧客の多くはPHP指定してくる。今のところ予想は外れたまま。
ええ、結局PHP書いてますよ。
0180nobodyさん
2009/01/29(木) 01:00:41ID:???ASP.NET系も同じく糞ゲイツ派企業の鉄板
PHPはなんだかんだでライトユーザーシェアはなくならない
---かべ---
PerlはもうすでにWebProgのCOBOL
Rubyは永遠に下火
そのた：話題に上らないほどにマイナー
>>176
PHPがだめぽってのはすごく理解できるが、
そこで何ゆえPerlなんかを選んでしまった理由を聞いてみたいｗ
0181nobodyさん
2009/01/29(木) 01:21:22ID:???軽量言語如きで信者論争とか、アホらしいっつうかアホそのものだ。
0182nobodyさん
2009/01/29(木) 01:35:52ID:???昔、簡単な物ならPerlで書けたけど、今はうpロダでさえ作れないかも。
PHPしか書けないWeb屋が居てもいいよねw
0183nobodyさん
2009/01/29(木) 01:41:58ID:???0184nobodyさん
2009/01/29(木) 01:51:42ID:???0185nobodyさん
2009/01/29(木) 18:23:40ID:???フレームワークのSSL対応ってどうなっているのでしょうか？
単純にページをhttps://以下に置けばSSL対応になるとかいうのではありません。
http://以下の特定のページに着たらhttps://以下にリダイレクトするというものでもありません。
私が聞きたいのは、SSLページと非SSLページにまたがったアクションで
情報がどのようにセキュアに扱われているかということです。
具体的に言えば、たとえばAmazonなど、非SSLページでカートに入れて、そこからSSLページにとんで
住所などの個人情報とカートの情報を結びつけて会計処理を行えます。
また逆に個人情報を入れてからカートに追加と言う処理もあります。
SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
こういう部分をフレームワークは解決してくれているのでしょうか？
解決してくれているとしたら、どういった設計になっているのでしょうか？
0186nobodyさん
2009/01/29(木) 18:26:56ID:???0187nobodyさん
2009/01/29(木) 18:31:21ID:???0188nobodyさん
2009/01/29(木) 18:42:10ID:???私が知りたいのは、フレームワークで
この問題をどう解決しているのか？
または解決していないのか？
ということです。
0189nobodyさん
2009/01/29(木) 20:08:05ID:???0190nobodyさん
2009/01/29(木) 20:15:44ID:???PHPはアンセキュアな糞フレームワークばかり
secure属性もしらなそうだな。
0191nobodyさん
2009/01/29(木) 20:45:27ID:???PHPにフレームワーク1つしかないと思ってるんだろうか
0192nobodyさん
2009/01/29(木) 20:52:01ID:???気にしないでやってください。
なぜなら、フレームワークに依存するレベルの話じゃない。
フレームワークを使ってどう実装するかという設計の問題です。
0193nobodyさん
2009/01/29(木) 21:12:16ID:???ttp://www.yiiframework.com/doc/guide/topics.security
0195nobodyさん
2009/01/29(木) 23:22:59ID:???俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。
>>193で端的に答えられているが、それ以外はわざとか限界か知らんが
ことごとくピントはずれでいい感じだなｗ
で、そのYiiのようなクッキーValidationは他のフレームワークにもあったような。
0196195
2009/01/29(木) 23:33:39ID:???場合には意味ないね。
考えられるシンプルな対策で、非セキュアなページではセッションを使わない、もしくは
セキュアページと共有しないってのは正味ありえないか
0197nobodyさん
2009/01/29(木) 23:48:44ID:???セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
その上で、承認後はセッションIDを毎ページ切り替えるってのが普通。
非セキュアなゾーンでセッションキーを盗んでも、匿名の個人情報が見れるだけで
実害はほとんどない。
これはフレームワーク層じゃなくて、ビジネスロジック層で実装するもんだよ。
0198nobodyさん
2009/01/30(金) 00:47:54ID:???0199nobodyさん
2009/01/30(金) 00:56:28ID:???0200nobodyさん
2009/01/30(金) 02:29:11ID:???0201nobodyさん
2009/01/30(金) 03:47:52ID:???PythonやらRubyやらPerlがphpと比べてどうのとか、
ぜんぜん関係なかったし。
0202nobodyさん
2009/01/30(金) 08:04:53ID:???>セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
これがわからん。どうやって確認するの？
例えばユーザでログインした後、トップページからお問い合わせフォーム（もしくはその確認画面）に進んだだけで
パスワード入力を求められるようなサイトは現実的かな？
Amazonみたいに、重要な操作の前にいちいちパスワード入力を求めるっていう感じかな。
それとも、セッションに頼らない確認方法があるんだろうか。
流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
0203nobodyさん
2009/01/30(金) 08:27:30ID:???アマゾンのように、長いセッションを維持するサイトでは、重要な操作の前に、
必ずパスワードを確認させて、セキュアなセッションは短くしている。
Yahooでもクッキーを数種類使いつつ、クラムというフォーム追跡を埋め込んで、
通常ログイン状態とセキュアログイン状態を識別、追跡している。
だから、パスワードの再確認を求められるケースとそうじゃないケースがある。
そういうギミックを持ってないところは、ショップなどのように金銭が絡むところは
まるっとHTTPSで実装する。
> 流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
それはどういうレイヤーで話をしてるの？
プロトコルの欠陥？ネットワーク盗聴？ブラウザーのバグ？
0205nobodyさん
2009/01/30(金) 10:08:00ID:???クッキーが盗まれる、っていう現象で想定のメインは「ネットワーク盗聴」じゃね？
他にもあるのか俺は知らんが。
例えばXSSで盗まれるのであればSSLなんて関係ないわけだし
>>204
毎回セッションIDを変えるってので兼用できてそうな気がするから、併用して
冗長にしてチェック、かな？
どのみちタイムアウトの設定次第の様な気がする。
0206nobodyさん
2009/01/30(金) 10:33:33ID:???ネットワーク盗聴ならSSL下では問題ないって前提でいいわけだよな。
(SSL下でも解読できるとか行っちまったら元もこもない）
SSL下でsecure属性をつけたクッキーを出すのが普通なんで、
復路の盗聴はないし、ワンタイムトークンを使う限り
タイムアウトはセキュアセッションと同等でいいよな。
あんまりにも普通なこと過ぎて書くのが恥ずかしくなってきたわ。
0207nobodyさん
2009/01/30(金) 10:39:58ID:???> だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
そういう場合に、どっちの方式をとるかは設計の問題だね。
だけどフレームワークの意味をもう一度思い出してほしい。
汎用的で複雑な処理を簡単に実装できることだ。
重要な操作の前に確認したいのなら、
プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。
0208nobodyさん
2009/01/30(金) 10:43:17ID:???> 匿名の個人情報が見れるだけで実害はほとんどない。
これは笑う所かいな？ｗ
個人情報＝本名・住所等
匿名の本名・住所等が見れるだけで実害はほとんどない。
匿名になってないじゃないか〜い。
0209nobodyさん
2009/01/30(金) 10:46:19ID:???AmazonやYahooでいつ別ウインドウが出るってんだ
その手のサイトでログイン後に別ウインドウとかアホ設計だろうに
0210nobodyさん
2009/01/30(金) 10:49:28ID:???別ウインドウってのは人間が出すんだよ。
ネットワークが遅いから、過去の履歴の詳細をいくつも別ウインドウで開くとか
（一つのウインドウの内容を見ている間に、他のページの読み込みが終わっている）
0211nobodyさん
2009/01/30(金) 10:51:55ID:???もしかしてそこが笑うところ？
> 個人情報＝本名・住所等
そんな決めつけでよくやってられるな。
たとえば、性別とか好みとかカートの中身とか、クリック動向とか
個人を特定できないが個人に関係する情報も個人情報だろが
0213nobodyさん
2009/01/30(金) 10:55:22ID:???連続でリロードすると問題になる。
サーバーでは値が変わっているが、
クライアントでは新しい値を受け取っていないなど。
0214nobodyさん
2009/01/30(金) 10:55:54ID:???> だけどフレームワークの意味をもう一度思い出してほしい。
> 汎用的で複雑な処理を簡単に実装できることだ。
セキュアセッションは汎用的でも複雑でもないだろ。
関数一発挟むだけなのに、それをプロパティで設定しろってか。
0216nobodyさん
2009/01/30(金) 10:57:52ID:???必ず認証が必要だというが、
Amazonはそうなっていない。
これを実現できるフレームワークは皆無ってことでおｋ？
0217nobodyさん
2009/01/30(金) 11:00:03ID:???だが、Amazonは別ウインドウを出しても、連続リロードしても問題ない。
これを実現できるフレームワークは皆無ってことでおｋ？
0219nobodyさん
2009/01/30(金) 11:04:46ID:???それは、ブラウザ起動して初めてログインした場合だろ。
一度ログインしていれば、非セキュアページから
セキュアページに入るときにパスワードは要求されない。
一度注文履歴を見たあとで、トップに戻れ。
トップから、もう一度注文履歴を見る間にパスワードを聞かれるか？
0220nobodyさん
2009/01/30(金) 11:12:49ID:???> 関数一発挟むだけなのに、それをプロパティで設定しろってか。
関数一発挟むだけじゃないな。
Windowsプログラミングじゃあるまいし。
パスワード入力ダイアログを出して終わりじゃないんだよ。
認証が必要になった場合に、他のページに飛ばさないといけない。
そこから戻らないといけない。
一回目（認証前）と戻ったときの二回目（認証後）で違う処理をしないといけない。
必ずパスワードを出すというわりに、認証後はパスワードを出さないという風に矛盾している。
0221nobodyさん
2009/01/30(金) 11:23:06ID:???> あと、毎回セッションIDを変える方法は、
> 別ウインドウを出したとき問題になる。
ただ単に、どっちかのセッションが使えなくなるだけじゃない？
問題なし
0222nobodyさん
2009/01/30(金) 11:24:24ID:???それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください
>>220
よーくわかった。(ry
0224nobodyさん
2009/01/30(金) 11:39:10ID:???PHPフレームワークスレでこんな機能が全て実現できるフレームワークは
PHPにないよね！って言われた所でなんなんだっていう
ちなみにPerlでもJavaでもASPでもそんなフレームワークはない
その辺は自分で実装する
0225nobodyさん
2009/01/30(金) 12:33:45ID:???>だけどフレームワークの意味をもう一度思い出してほしい。
>
>汎用的で複雑な処理を簡単に実装できることだ。
>重要な操作の前に確認したいのなら、
>プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
>
>YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
>作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
これがフレームワークが提供すべき汎用的な機能かと言うとどうだろうね？
0226225
2009/01/30(金) 12:35:02ID:???「Webアプリケーションフレームワークが」提供すべきかどうか、ね。
0227nobodyさん
2009/01/30(金) 12:46:45ID:???そこにバグがあったらそれ使ってるシステムみんな死亡じゃん
クリティカルな部分は独自に実装するからバグがあってもなんとななるわけで
0228nobodyさん
2009/01/30(金) 13:17:58ID:???んなこといったら、プレースホルダ使いたい、使わせたい為だけにPEAR::DB使ってた人間とか涙目だろ。
実際そういった判断は、凡PGに任せるより遙かにセキュアだったと思うがな
フレームワーク（というか基底ライブラリ）の有用性の一面を完全否定っすか。
0229nobodyさん
2009/01/30(金) 13:34:34ID:???問題はバグがどうたらじゃないよ
設計や計画にはちゃんとした理解が必要だが、コーディングが難しかったり
面倒だったりするわけじゃないからFWに任せる内容じゃないってことだよ。
コーディングの助けっていう意味程度なら、どのFWにもセキュアセッション
を扱う機能や、ワンタイムトークンを自動でハンドリングするフォーム要素とか
一通りのものは揃ってる。
が、ページ遷移設計まで自動化してほしいとは思わないけどな。
PieceFrameworkあたりなら、その辺はすでに実装済みかもしれんけど。
0230nobodyさん
2009/01/30(金) 13:36:33ID:???ああいうのはFWで吸収しない方がいい
0231nobodyさん
2009/01/30(金) 13:38:02ID:???きちんと実装されるかどうかじゃなくて、フレームワークの場合は
そういうバグがありましたって公開されちゃうから、フレームワーク使ってるのバレると
悪用されるってことじゃないの？
独自実装ならクソみたいな実装でも中はどうなってるかアタックするまで解らんのだし
0232nobodyさん
2009/01/30(金) 13:43:38ID:???言ってみれば各フレームワークも、それぞれの独自実装の固まりだからな
ある程度のライブラリくらい共用して欲しいような気もする今日この頃。
APIも統一されるし。
0233nobodyさん
2009/01/30(金) 13:53:53ID:???0235nobodyさん
2009/01/30(金) 14:24:52ID:???PHPって複数のセッションを同時に利用することってできるの？
それができるかできないかで、ものすごく話が変わってくるような。
・・・できないんだろうな。$_SESSION だもんな・・・
0236nobodyさん
2009/01/30(金) 14:32:51ID:???微妙にスレチだぞ＞くだすれ行けって感じだが・・・
無理やりFWレイヤーの話に持ってくると、Zend_Sessionではセッションの配列で
ネームスペース的な扱いをして、使い分けている。
でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
分割して持てるか？って話をしたいわけだよな？
PHPが受け入れるセッションID自体は一つ。それは正しい。
解は二つ。
クッキーと独自のバックエンドを使って、自前でセッション機構を作る。
セッションを理解してれば、簡単。
ちなみにYahoo!はPHPでこの方式を採用してる。
もう一つは、セッションそのものは永続化しておいて、セッションネームスペース内
に侵入を許す際に、そのネームスペースに対する適切なアクセスかどうかを個別のクッキーで検証する。
ZFで実装してるやつはたぶんこれがFA
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:???たまにこういうことがあるから面白い
■ このスレッドは過去ログ倉庫に格納されています