- 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/
- 129 名前：nobodyさん mailto:sage [2009/01/20(火) 13:31:39 ID:???]
- >>128
他人がいじれない確率が高いのがネックだな。
- 130 名前：nobodyさん mailto:sage [2009/01/20(火) 13:37:08 ID:???]
- >>128
それはWEBアプリの一部ではないのだろうか。
まあ一般論だとしても、これは実は結構大きいんだけどね。
WEBでPHPを使ってるんなら、CPANとかいちいち使い方調べるのは効率悪いとも思う。
でも、それをやっとくと比較的汎用的なスキルにはなってそうな気もするから迷う。
（自作ライブラリが陳腐化した時とか、そもそも違う環境で作業しなきゃいけないとか）
結局 得意な言語が１〜２個あり、その他も好き嫌いしないで使えるってのが理想では
あるんだけど。
- 131 名前：nobodyさん mailto:sage [2009/01/20(火) 14:53:10 ID:???]
- >>124
監視しない方ですか
- 132 名前：nobodyさん mailto:sage [2009/01/20(火) 15:09:20 ID:???]
- >>124
RubyはないだろJK
いや少しはあるかもしれんが、
基本はPerlかPython。
- 133 名前：nobodyさん mailto:sage [2009/01/20(火) 15:15:18 ID:???]
- おれの基本はbash
- 134 名前：nobodyさん mailto:sage [2009/01/20(火) 15:52:58 ID:???]
- OSやM/W自体の監視と、そこで動くアプリケーションの監視を混同してないか？
前者ならPerlが多いと思うし、後者でDBも監視するなら
そのアプリケーションで使ってるライブラリ使ってDBアクセスしたほうがいいだろうし。
- 135 名前：nobodyさん mailto:sage [2009/01/20(火) 19:57:05 ID:???]
- >>132
言っちゃダメーｗｗｗｗ
本人はPerlかPythonに並ぶメジャー言語だって思ってんだからｗｗｗ
- 136 名前：nobodyさん mailto:sage [2009/01/20(火) 20:29:13 ID:???]
- は？puppetなんかはrubyで書かれてますが何か
今時perlなんて類人猿しか使ってねーし
- 137 名前：nobodyさん mailto:sage [2009/01/20(火) 22:54:13 ID:???]
- このスレでそんなこと言ってもねぇ
- 138 名前：nobodyさん mailto:sage [2009/01/21(水) 00:00:34 ID:???]
- Agaviの次のリリースではコマンドラインからの呼び出しがサポートされるよ。
trac.agavi.org/ticket/480
- 139 名前：nobodyさん mailto:sage [2009/01/21(水) 00:07:16 ID:???]
- agavi静かに進んでたんだなｗ
- 140 名前：nobodyさん mailto:sage [2009/01/21(水) 03:12:08 ID:???]
- 実際、Rubyは厳しいんじゃないかな。ウェブ系のスクリプト言語でPHPの優位は今後も変わらないでしょう。
サブの言語というか、ちょっとしたツールなら、Perlで十分だし、海外じゃPythonもあるわけで。
日本でRuby使うって、Railsを使うって言うのとイコールだと思うけど、当初はともかく、今となっては特別圧倒的に優位なウェブフレームワークじゃないし。
- 141 名前：nobodyさん mailto:sage [2009/01/21(水) 03:25:00 ID:???]
- Rubyは立ち位置が微妙だよな
ニッチ言語でもないし
- 142 名前：nobodyさん mailto:sage [2009/01/21(水) 07:20:17 ID:???]
- なんというか利点がないんだよな。Ruby使う
- 143 名前：nobodyさん mailto:sage [2009/01/21(水) 08:54:04 ID:???]
- Ruby/RoRのModelで関連テーブルが扱えないのは治ったのか？
俺はあれでRoRって使えねーって思ったんだが。
- 144 名前：nobodyさん mailto:sage [2009/01/21(水) 10:38:16 ID:???]
- 企業からすれば、習得のためのコストは少ないほうが良いに決まっている。
- 145 名前：nobodyさん mailto:sage [2009/01/21(水) 11:00:58 ID:???]
- >>144
出来る人間なら習得コストは同じだよ。何でもすぐ覚える。勝手に覚える。
知らない間にPerlとかに手を出してる。
PHP手取り足取り教えてやっと使い物になるような人材は嫌だなあ。
- 146 名前：nobodyさん mailto:sage [2009/01/21(水) 11:03:52 ID:???]
- 嫌とか嫌じゃないかの問題じゃなく、
コストの問題でしょ
- 147 名前：nobodyさん mailto:sage [2009/01/21(水) 11:16:40 ID:???]
- >>146
教材は何でもいいよ。ダメなら切るだけ。だからコストは一緒。
出来る人間がPHP覚えるのもPerl覚えるのも大差ない。
- 148 名前：nobodyさん mailto:sage [2009/01/21(水) 11:27:19 ID:???]
- 出来る人間だけ揃えられる企業ならともかく、
能力にばらつきがあるのが世の常でしょ
- 149 名前：nobodyさん mailto:sage [2009/01/21(水) 11:30:39 ID:???]
- >>148
まあその辺は会社によって違うかもな。
PHPは教材としてイニシャルコストは安いと思う。
どの言語も結局は同じくらいのコストがかかるんだがな。
- 150 名前：nobodyさん mailto:sage [2009/01/21(水) 12:27:49 ID:???]
- 求人するのタダじゃないんだぞ。
そう簡単に切ったり雇ったりできるか！
言語を教材なんて言ってる時点で仕事じゃない
コスト考えるなら即戦力。即戦力を考えたら普及している言語が有利に決まってるだろ。
今話題の派遣とかが会社にとって効率がいい
- 151 名前：nobodyさん mailto:sage [2009/01/21(水) 13:08:07 ID:???]
- 雇って育ててるのは相当余裕がある会社ということか。
プログラマ堅気を見抜けるエスパーが社に一人いると便利だよ。
- 152 名前：nobodyさん mailto:sage [2009/01/21(水) 13:38:39 ID:???]
- 即戦力なんてほとんどいない
特に新卒とか
- 153 名前：nobodyさん mailto:sage [2009/01/22(木) 03:26:59 ID:???]
- Rubyの習得コストが低いって嘘はどっから出てきたんだ
まさか日本人が作った言語だから日本人に解りやすいとでも思ったのか
- 154 名前：nobodyさん mailto:sage [2009/01/22(木) 03:33:43 ID:???]
- まぁ、派遣メインの場合、本当は戦力じゃないPGを、
ねじ込んでしまえば、人材という商品にはなれちゃうからな。
とりえずphpかJavaできますと言って、嘘にならなければ戦力。
今となっては、というお話だったとさとしか言えんがｗ
- 155 名前：nobodyさん mailto:sage [2009/01/22(木) 04:44:46 ID:???]
- 金融なんかは人月稼いでなんぼみたいな所あるからね
どれだけ大人数で時間書けてやったかがリーダーの実績みたいなｗ
だからコンサルファームはとにかくスキル関係なく人を入れたがる
- 156 名前：nobodyさん mailto:sage [2009/01/22(木) 04:53:28 ID:???]
- 問題化しないギリギリまで長期化させて、
ギリギリ成功といえる状態で、案件を終わらせるのが、
優れたリーダーってことか。
とても楽しくなさそうだ。
- 157 名前：nobodyさん mailto:sage [2009/01/22(木) 05:37:45 ID:???]
- 客が怒る寸前まで常駐させて貰うのがキモです
運用は儲からないんです
- 158 名前：nobodyさん mailto:sage [2009/01/23(金) 02:44:44 ID:???]
- フレームワークスレでも土方さん多いのな。
そんなもんか。
- 159 名前：nobodyさん mailto:sage [2009/01/23(金) 08:09:25 ID:???]
- お前はアホか
- 160 名前：nobodyさん mailto:sage [2009/01/27(火) 00:00:53 ID:???]
- Yiiいいじゃん
- 161 名前：nobodyさん mailto:sage [2009/01/27(火) 23:42:06 ID:???]
- >>160
そうなの？
- 162 名前：nobodyさん mailto:sage [2009/01/28(水) 00:04:30 ID:???]
- サーバ側でmemcacheとか用意しないとならんけどな
DBアクセスするならPDOとかもPear側で準備しとかないとならん
あと結構依存するライブラリたくさんある
フレームワークの意味あんのか
- 163 名前：nobodyさん mailto:sage [2009/01/28(水) 00:05:19 ID:???]
- ZendFW使ってるけど、他の使ってない俺から見ればこれで十分な気ｶﾞｽ
- 164 名前：nobodyさん mailto:sage [2009/01/28(水) 00:12:52 ID:???]
- PDOをPear側で準備・・・？
- 165 名前：nobodyさん mailto:sage [2009/01/28(水) 00:26:31 ID:???]
- ああごめん
PDOがPearじゃなくて"とか"をPearで用意する必要があるものもあるって事ね
CakeとかZendとかPearフリーじゃん
それの対比でYiiは違うよと
- 166 名前：nobodyさん mailto:sage [2009/01/28(水) 00:52:28 ID:???]
- PDOとかをPearで準備・・・？
- 167 名前：nobodyさん mailto:sage [2009/01/28(水) 00:55:30 ID:???]
- ZendFWでのDB接続は基本PDOだけど・・・
- 168 名前：nobodyさん [2009/01/28(水) 01:01:34 ID:VWeywu5Y]
- >>162
memcacheは必須じゃないでしょ？
逆にCakeでもZendでもキャッシュのバックエンドにmemcacheを使うなら
サーバ側で用意するのは一緒。
> あと結構依存するライブラリたくさんある
例えば？
> フレームワークの意味あんのか
依存するライブラリの多寡とフレームワークの意味は関係ない概念だと思います。
- 169 名前：nobodyさん mailto:sage [2009/01/28(水) 07:10:16 ID:???]
- 信者ｗ
- 170 名前：nobodyさん mailto:sage [2009/01/28(水) 08:17:44 ID:???]
- >>162はmemcacheって言いたかっただけじゃないかと
ActiveRecordをシンプルに使えてちょっといい感じだけどな ＞ Yii
ただ、拡張をどうすればいいのかちょっとまだよくわからん
- 171 名前：nobodyさん mailto:sage [2009/01/28(水) 08:19:43 ID:???]
- ペドなんか使うなよ
- 172 名前：nobodyさん mailto:sage [2009/01/28(水) 11:10:45 ID:???]
- 最近、イスラエルがたくさん人を殺しているというニュース
どっちもどっちなのかもしれないけど、ほめられたことじゃないな
Zendはそんなイスラエルの会社
PHP以外でWEBアプリを作ったことがない俺
はぁ〜、PHPでプログラミングしていると軽く鬱になる（＝これはイスラエルとは関係ないかもしれんｗｗｗ）
plugger(Perl)、Google App Engine(Python)でもやってみるかな？
- 173 名前：nobodyさん mailto:sage [2009/01/28(水) 11:22:29 ID:???]
- なんだよその上っ面だけの意見は
- 174 名前：nobodyさん mailto:sage [2009/01/28(水) 12:50:21 ID:???]
- PHPER=ユダヤ人
そう考えたら色々納得いくぜ！
- 175 名前：nobodyさん mailto:sage [2009/01/28(水) 15:17:58 ID:???]
- イスラエルで納得っていうと差別されたり、虐殺されたり、病院爆撃したりっていうこと?
あと金持ち属性もあるか。
PHPERは差別はされてるかもしれないけど、虐殺はされてないし、
病院ごとテロリストをぶっとばすのもしてないぞ、なにより金持ちでもないし。
...いや、この先IT不況が来たら大量に首を切られて虐殺されるかも...
- 176 名前：nobodyさん mailto:sage [2009/01/28(水) 15:47:25 ID:???]
- PHPはもうダメポと思った俺は開発をPerlに切り替えたのだが、
顧客の多くはPHP指定してくる。今のところ予想は外れたまま。
ええ、結局PHP書いてますよ。
- 177 名前：nobodyさん mailto:sage [2009/01/28(水) 22:52:50 ID:???]
- >>172
そこまで考えるんならさぁ。
欧米由来の言語って一切つかえなくね？
- 178 名前：nobodyさん mailto:sage [2009/01/28(水) 23:53:34 ID:???]
- >>176
なんで思ったの？
- 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あたりなら、その辺はすでに実装済みかもしれんけど。
|
 |
