【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/
0136nobodyさん
2009/01/20(火) 20:29:13ID:???今時perlなんて類人猿しか使ってねーし
0137nobodyさん
2009/01/20(火) 22:54:13ID:???0138nobodyさん
2009/01/21(水) 00:00:34ID:???http://trac.agavi.org/ticket/480
0139nobodyさん
2009/01/21(水) 00:07:16ID:???0140nobodyさん
2009/01/21(水) 03:12:08ID:???サブの言語というか、ちょっとしたツールなら、Perlで十分だし、海外じゃPythonもあるわけで。
日本でRuby使うって、Railsを使うって言うのとイコールだと思うけど、当初はともかく、今となっては特別圧倒的に優位なウェブフレームワークじゃないし。
0141nobodyさん
2009/01/21(水) 03:25:00ID:???ニッチ言語でもないし
0142nobodyさん
2009/01/21(水) 07:20:17ID:???0143nobodyさん
2009/01/21(水) 08:54:04ID:???俺はあれでRoRって使えねーって思ったんだが。
0144nobodyさん
2009/01/21(水) 10:38:16ID:???0145nobodyさん
2009/01/21(水) 11:00:58ID:???出来る人間なら習得コストは同じだよ。何でもすぐ覚える。勝手に覚える。
知らない間にPerlとかに手を出してる。
PHP手取り足取り教えてやっと使い物になるような人材は嫌だなあ。
0146nobodyさん
2009/01/21(水) 11:03:52ID:???コストの問題でしょ
0147nobodyさん
2009/01/21(水) 11:16:40ID:???教材は何でもいいよ。ダメなら切るだけ。だからコストは一緒。
出来る人間がPHP覚えるのもPerl覚えるのも大差ない。
0148nobodyさん
2009/01/21(水) 11:27:19ID:???能力にばらつきがあるのが世の常でしょ
0149nobodyさん
2009/01/21(水) 11:30:39ID:???まあその辺は会社によって違うかもな。
PHPは教材としてイニシャルコストは安いと思う。
どの言語も結局は同じくらいのコストがかかるんだがな。
0150nobodyさん
2009/01/21(水) 12:27:49ID:???そう簡単に切ったり雇ったりできるか！
言語を教材なんて言ってる時点で仕事じゃない
コスト考えるなら即戦力。即戦力を考えたら普及している言語が有利に決まってるだろ。
今話題の派遣とかが会社にとって効率がいい
0151nobodyさん
2009/01/21(水) 13:08:07ID:???プログラマ堅気を見抜けるエスパーが社に一人いると便利だよ。
0152nobodyさん
2009/01/21(水) 13:38:39ID:???特に新卒とか
0153nobodyさん
2009/01/22(木) 03:26:59ID:???まさか日本人が作った言語だから日本人に解りやすいとでも思ったのか
0154nobodyさん
2009/01/22(木) 03:33:43ID:???ねじ込んでしまえば、人材という商品にはなれちゃうからな。
とりえずphpかJavaできますと言って、嘘にならなければ戦力。
今となっては、というお話だったとさとしか言えんがｗ
0155nobodyさん
2009/01/22(木) 04:44:46ID:???どれだけ大人数で時間書けてやったかがリーダーの実績みたいなｗ
だからコンサルファームはとにかくスキル関係なく人を入れたがる
0156nobodyさん
2009/01/22(木) 04:53:28ID:???ギリギリ成功といえる状態で、案件を終わらせるのが、
優れたリーダーってことか。
とても楽しくなさそうだ。
0157nobodyさん
2009/01/22(木) 05:37:45ID:???運用は儲からないんです
0158nobodyさん
2009/01/23(金) 02:44:44ID:???そんなもんか。
0159nobodyさん
2009/01/23(金) 08:09:25ID:???0160nobodyさん
2009/01/27(火) 00:00:53ID:???0162nobodyさん
2009/01/28(水) 00:04:30ID:???DBアクセスするならPDOとかもPear側で準備しとかないとならん
あと結構依存するライブラリたくさんある
フレームワークの意味あんのか
0163nobodyさん
2009/01/28(水) 00:05:19ID:???0164nobodyさん
2009/01/28(水) 00:12:52ID:???0165nobodyさん
2009/01/28(水) 00:26:31ID:???PDOがPearじゃなくて"とか"をPearで用意する必要があるものもあるって事ね
CakeとかZendとかPearフリーじゃん
それの対比でYiiは違うよと
0166nobodyさん
2009/01/28(水) 00:52:28ID:???0167nobodyさん
2009/01/28(水) 00:55:30ID:???0168nobodyさん
2009/01/28(水) 01:01:34ID:VWeywu5Ymemcacheは必須じゃないでしょ？
逆にCakeでもZendでもキャッシュのバックエンドにmemcacheを使うなら
サーバ側で用意するのは一緒。
> あと結構依存するライブラリたくさんある
例えば？
> フレームワークの意味あんのか
依存するライブラリの多寡とフレームワークの意味は関係ない概念だと思います。
0169nobodyさん
2009/01/28(水) 07:10:16ID:???0170nobodyさん
2009/01/28(水) 08:17:44ID:???ActiveRecordをシンプルに使えてちょっといい感じだけどな ＞ Yii
ただ、拡張をどうすればいいのかちょっとまだよくわからん
0171nobodyさん
2009/01/28(水) 08:19:43ID:???0172nobodyさん
2009/01/28(水) 11:10:45ID:???どっちもどっちなのかもしれないけど、ほめられたことじゃないな
Zendはそんなイスラエルの会社
PHP以外でWEBアプリを作ったことがない俺
はぁ〜、PHPでプログラミングしていると軽く鬱になる（＝これはイスラエルとは関係ないかもしれんｗｗｗ）
plugger(Perl)、Google App Engine(Python)でもやってみるかな？
0173nobodyさん
2009/01/28(水) 11:22:29ID:???0174nobodyさん
2009/01/28(水) 12:50:21ID:???そう考えたら色々納得いくぜ！
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
■ このスレッドは過去ログ倉庫に格納されています