08/12/23 00:36:15
PHPのフレームワークに関する話題用のスレッド
●国外産●
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)
Yii Framework ←New!! (Dec 03, 2008)
URLﾘﾝｸ(www.yiiframework.com)
●国産
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)
●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
ｽﾚﾘﾝｸ(php板)
2:nobodyさん
08/12/23 00:36:35
●過去スレ一覧
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ10【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ9【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ8【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)
3:nobodyさん
08/12/23 04:20:21
おつ
4:nobodyさん
08/12/23 15:47:46
guessworkのPHP5用ってﾏﾀﾞｰ?
5:nobodyさん
08/12/23 19:49:58
2ちゃんだとcakeのスレが一番伸びてるみたいだが、
実際はどうなん？
6:nobodyさん
08/12/23 20:11:14
Cakeの対象にしてるユーザーが2chねらーと一致してるってことだろうな。
おれは、Bakerじゃないけど
7:nobodyさん
08/12/24 02:40:46
関連しそうなスレ
【PHP】フレームワーク CakePHP 5ホール目【v1.2】
ｽﾚﾘﾝｸ(php板)
【PHP】 Smarty 隔離スレ 【テンプレート】
ｽﾚﾘﾝｸ(php板)
[PHP][フレームワーク]CodeIgniterスレ
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークMapleに舌鼓
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワーク Akelos
ｽﾚﾘﾝｸ(php板)
【PHP】Ethna part.2【国産フレームワーク】
ｽﾚﾘﾝｸ(php板)
2ch有志がPHPフレームワークを作るスレ
ｽﾚﾘﾝｸ(php板)
PHP総合雑談スレ
ｽﾚﾘﾝｸ(php板)
8:nobodyさん
08/12/24 08:08:43
>>7 に追加。
ZendFramework Part2
ｽﾚﾘﾝｸ(php板)
Vs.Phpのv2.5ぐらいからZFの簡単なスケルトンコードを吐くようになってる。
けど、もうちょっと便利にならんかなぁ。ZS for Eclipseの方がいいかな?
9:nobodyさん
08/12/24 10:41:53
補足thx phpでソートしたて拾ったから見落としてた
10:nobodyさん
08/12/24 11:32:06
フランチョスとsymfony
ｽﾚﾘﾝｸ(php板)
symfony忘れんな。うじ虫。
11:nobodyさん
08/12/24 12:16:54
なんか言葉の感覚が違うんだろうな。
>>10は日本語が不自由ですか？
12:nobodyさん
08/12/24 17:13:04
>>8
両方とも有料だけどなんでこうフリーでZFに完全対応してくれるフレームワークって無いのかね
13:nobodyさん
08/12/25 02:33:24
>>12
完全対応してくれる"IDE"の間違いじゃね?。
PDTなんかにさらにFWごとにカスタマイズ出来るプラグイン追加って出来たらいいのだろうけど。
俺は今のところZFしか使ってないけど、IDEの対応も普及に貢献すると思うんだが、他のFWはどぉなんだろう。
14:nobodyさん
08/12/25 03:17:52
すまん頭が血迷ってた
どんな環境でZF使ってる？
15:nobodyさん
08/12/25 04:04:54
>>14
開発環境かな? 運用環境じゃないよね。
ZFを使うときはVs.Phpにしている。2.4止まりのアシアルはやる気なさそげなので、
英語版を試用してみたが、英語版で十分だな。そろそろ2.6が正式リリースしそうなので
そうなったら移行するつもり。円高で新規でも1ﾏｿ切ってるしなーw。
俺々FWのﾌﾞﾂはPDT使ってた。今でもメンテで使ってる。ZS4Eに手を出せないのは、
そのうちPDTでもZFをサポートし出すんじゃないかと思ってみたり。
16:nobodyさん
08/12/25 13:43:50
>>15
VS.Phpの使い心地ってどんな感じ?
よかったら詳しいレポ頼む。
17:nobodyさん
08/12/25 23:33:30
>>16
そこまで書くとｽﾚ違いになちゃうな。
以前はIDEｽﾚがあったけど。
PDTと比べると一長一短。デバッガなど全体的には軽快に動く。
C#なんかと比べると、やっぱりもどかしい。
2.6で補完範囲が改善されそうなので期待している。
好みもあるだろうから、30日間試用してみるのが一番いいと思うよ。
18:nobodyさん
08/12/25 23:44:29
ｽﾚ違いﾈﾀ続きでｽﾏｿ。
日本語版も含めてなんか出てきた。
URLﾘﾝｸ(www.jcxsoftware.com)
ただ、リンク先の証明書が無効だと火狐で警告が出ます。
19:nobodyさん
08/12/25 23:51:17
>>18
WEBプログラム言語用のIDEの配布？に、何このずさんな証明書使い回し
ってかそれでなんでSSL掛けてるのか意味不明。
20:nobodyさん
08/12/26 09:54:44
ってかリンク切れしとるんだけど・・・SSLのせい？
21:nobodyさん
08/12/27 01:31:19
フレームワークまったく使ったことないけどなんなん？
使うとどんな感じなん？
22:nobodyさん
08/12/27 01:55:26
>>21
なんか下半身がもぞもぞします
23:nobodyさん
08/12/27 12:41:38
>>21
なんやろねー
24:nobodyさん
08/12/29 15:26:56
fooというディレクトリがおかしいので、一回削除してsvnからリポジトリを持って来たいのですが
リポジトリの部分だけを持ってくるコマンドラインがわかりません。単純な質問だと思いますが
どうしてもわからず、ご教授のほどお願いいたします。
25:nobodyさん
08/12/29 15:37:33
誤爆しました。すみません。
26:nobodyさん
08/12/29 20:34:55
PHP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆？
27:nobodyさん
08/12/29 20:36:32
HP → Zend → イスラエル → パレスチナ → 爆撃 → 誤爆→PHP脂肪ｗｗｗ
28:nobodyさん
09/01/01 09:20:32
新年あけましておめでとう→PHP脂肪ｗｗｗ
29:nobodyさん
09/01/01 13:10:51
guesswork for PHP5をお年玉にお願いします
30:nobodyさん
09/01/02 01:48:51
>>26
まあ徴兵制だろうね。
終戦前に成人した世代と戦後世代の日本人を見比べれば一目瞭然。
31:nobodyさん
09/01/02 12:39:17
今年一番来るフレームワークはどれだ?
2009 PHPフレームワークダービー
出走場受付中
32:nobodyさん
09/01/02 12:44:31
>>31
>出走場受付中
出走馬ではないの？
33:nobodyさん
09/01/03 18:39:59
>>32
2chでそんな細かいこと言ってると嫌われちゃうぞー
34:nobodyさん
09/01/06 14:44:09
サーバサイド(PHP)とクライアントサイド(JavaScript)の両方でバリデーションをしたいと思うのですが、
同じコードをPHPとJavascriptの両方で書くのはちょっと面倒です。
なんかうまい方法はありませんか。あるいはそのようなフレームワークやライブラリがあれば紹介してください。
お願いします。
35:nobodyさん
09/01/06 17:59:40
そんなつごうのいいのはない
36:nobodyさん
09/01/06 18:25:39
>>32
うひー、ほんとだ(汗
typoご容赦。
んでみんなは今後どのFW使っていくの?
俺はもうZendでいいかと思い始めてる・・・
>>34
jQueryのajaxformプラグインを使ってサーバにリクエストを投げて、
コールバックでエラー表示処理。
37:nobodyさん
09/01/06 19:22:42
そんなことする価値あるの？
38:nobodyさん
09/01/06 19:36:39
クライアントサイドはユーザに負担掛けないリアルタイムな入力チェック
サーバサイドはhiddenの値が改ざんされたときの保険
って感じじゃないの
まぁ値をhidden渡しじゃなくてセッションに突っ込めばクライアント側だけでいい気もするけど
39:nobodyさん
09/01/06 19:38:50
JavaScriptオフの環境への対応でもある
40:nobodyさん
09/01/06 19:47:32
このサイトはInternetExplorer6.0でのみ確認しています
ってエラーメッセージ出せばよくね？
41:nobodyさん
09/01/06 19:53:28
>>36のやり方だと、結局レスポンス待ちだから画面遷移しないってだけであんまり、ねえ。
まあありっちゃありか。
やるとするなら、最初からエラーチェックのJavaScriptを吐き出すか読み込んでおくような形に
するほうがまだスマートな気もするけど。
そういうライブラリあるのかどうかは知らないけど、XMLか何かで、鯖・クラ共用するものは作れそう
>>38
んで、そのセッションに突っ込むデータはどこから飛んでくるんだｗ
>>39の言うとおり、クライアント側のみの検証はあり得ない
処理するデータが無検証の可能性があるってのは、DBに突っ込む時のみならず後々いろいろまずい、はず。
JavaScriptの検証をスルーしてPOSTデータが飛んでこないっていう保証があるんならいいけど。
42:nobodyさん
09/01/06 20:10:38
ネタレスなんだけどさ、
JSでチェックするスクリプトを書く
そのチェックスクリプトをインクルードしてバリデートして返すページを作っておく。
サーバー上のチェックはそのページにCURLでPOSTして結果を取得する。
これなら、バリデーターはJSだけで済む。
43:nobodyさん
09/01/06 20:21:09
>>42
それ、JavaScript動くの？JSのエンジンはどこにあるんだろう・・・
44:nobodyさん
09/01/06 20:24:31
昔ここで見た
サーバサイドもJavaScriptで書いちゃえばいいんだよ！
ってネタレスを思い出した。
その時に聞いたJavaScriptインタプリタなんだったかな？
45:nobodyさん
09/01/06 20:27:27
あ、そか。JSのエンジンが必要だった。逆に、それがあればCURLは関係ないなｗ
サーバーサイドJavaScriptを使うしかないか。
46:nobodyさん
09/01/06 20:30:15
rinoとか
47:nobodyさん
09/01/06 20:36:03
SpiderMonkeyのPHPバインディングとか、サーバサイドJavaScriptの選択肢もいくつかあるよ
48:nobodyさん
09/01/06 21:48:54
俺ならバリデーション規則だけJSONで書いて、それを適用する関数をJavaScriptとPHPで別箇に実装するに留める。
バリデーションルールのデータフォーマット設計が面倒だが、Kwalifyとかを丸パクリかな。
49:nobodyさん
09/01/06 21:58:01
YiiのJPフォーラムに投稿があってうれしい
50:nobodyさん
09/01/06 22:25:49
最近サーバサイドJSも現実的な選択肢になってきたみたいね
故にPHP脂肪ｗｗｗ
51:nobodyさん
09/01/06 23:00:54
>>41
そうなんです、できれば>>36の方法じゃなくて、クライアントサイドでできるチェックはクライアントサイドだけで完結させたいです。
>そういうライブラリあるのかどうかは知らないけど、XMLか何かで、鯖・クラ共用するものは作れそう
残念、ご存じないですか。需要はあると思うんですけど、思ったほど作られてないようですね。
Railsでも探したんですけど、やっぱりないみたいです。
>>48
>俺ならバリデーション規則だけJSONで書いて、それを適用する関数をJavaScriptとPHPで別箇に実装するに留める。
あーつまり、JSONで書かれた規則をPHPで読み込んで、フォーム入力がそれに従っているかどうかをチェックするという感じですか。
そして同じことをJavaScriptでもやると。なるほど。頭いいですね。
>バリデーションルールのデータフォーマット設計が面倒だが、Kwalifyとかを丸パクリかな。
Kwalifyって何ですか？
52:48
09/01/06 23:36:43
>51
バリデーションを行なうライブラリ。配列やJSON、YAMLなどのバリデーションを行なう。RubyとかPerlしかないが。
まあ、こんなデータフォーマットだとそれなりに漏れなく表現できるよってだけの意味。単なるサンプルに過ぎない。
自分でバリデーションルール用のJSONのフォーマット考えられるなら忘れておｋ。
（まあ、データフォーマットとかいちいち考えず、正規表現をJSONに格納しておけば十分っちゃ十分なのだが…）
53:36
09/01/07 00:37:15
>>39
そう、Progressive Enhancementというやつです。
>>47
Jaxerというのもある。
54:nobodyさん
09/01/07 00:57:38
VBでクライアントアプリケーション作ってサーバサイドアプリと通信しなよ
55:nobodyさん
09/01/07 08:08:02
>>34
今は亡きｗ HTML_QuickFormに、一応JavaScriptコードの自動出力機能がついてたなあ
56:nobodyさん
09/01/07 10:01:31
DBｸｴﾘｰ必要なﾊﾞﾘﾃﾞｰｼｮﾝもある
57:nobodyさん
09/01/07 22:34:19
それ、バリデーションって言うか？
58:nobodyさん
09/01/07 23:01:29
IDの重複チェックや郵便番号の存在チェックとかだろ
59:nobodyさん
09/01/08 10:31:01
それは普通にAjaxでやればいいわけで
60:nobodyさん
09/01/08 10:39:22
Ajaxっていったって、DB内のIDと重複するかチェックするなら(ry
61:nobodyさん
09/01/08 11:31:26
>>59
まさか郵便番号何十万件もJSの配列につっこんどくつもりか
62:nobodyさん
09/01/08 11:32:22
クライアントレベルでは簡易的なチェックでいいんだから問題なし
63:nobodyさん
09/01/08 11:40:10
> 簡易的なチェックでいいんだから問題なし
へぇ。そうなんですか。メモっとこ。
64:nobodyさん
09/01/08 12:08:22
ん？ なんでAjaxでJSの配列？
65:nobodyさん
09/01/08 12:44:42
AjaxからDBにクエリ投げて検証した結果のIDをhiddenなりtextなりに突っ込んでPOSTし
POST先のサーバコードでまたDBにクエリ投げて検証してってやるわけですね
まあPOSTする前、画面遷移せずにエラー警告文が出せるというのが利点か。
66:nobodyさん
09/01/08 15:02:15
なんなのこの低ﾚﾍﾞﾙｗ
67:nobodyさん
09/01/08 15:51:12
>>64
DBアクセスしないで何処からデータ持ってくるんだ
68:nobodyさん
09/01/08 16:23:15
DBアクセスとJSの配列になんの関係が？
69:nobodyさん
09/01/08 16:51:55
なんなのこの超低ﾚﾍﾞﾙｗ
70:nobodyさん
09/01/08 19:17:03
>>68
71:nobodyさん
09/01/08 21:05:54
Ajax万能説かｗ
72:nobodyさん
09/01/08 21:47:23
隙を見せないように要点を得ない短文ばかりで話すらかみ合ってない
73:nobodyさん
09/01/09 04:32:42
>要点を得ない
74:マジレス希望
09/01/09 12:19:55
皆さん、JavaScriptはどうやって勉強されましたか？
・オススメの勉強方法
・オススメの解説書
・オススメのサイト
があれば是非ご紹介ください。m(__)m
75:nobodyさん
09/01/09 13:04:59
ぐぐる
76:nobodyさん
09/01/09 13:27:38
>>74
一撃必殺
77:nobodyさん
09/01/09 19:17:31
>>74
スレチだろ、よそで聞いたほうがまともな答えが返ってくると思うぞ。
78:nobodyさん
09/01/11 12:53:52
ストリームベースのフレームワーク
URLﾘﾝｸ(lll-framework.hikosha.jp)
なんだこれ
79:nobodyさん
09/01/12 00:02:56
>>78
「解凍して、public_html/にアクセスするだけで、すぐに使えます！」
解凍したファイルをドキュメントルート以下に置いてpublic_html/にアクセスすると
Fatal error: LLL_Template::require()とでて真っ白の画面になった。
PieceFrameworkを思い出したよ。
ﾎﾟｨ(ﾟ△ﾟ)ﾉ⌒ ﾟ凵
80:nobodyさん
09/01/12 11:46:05
>>79
すまない。orz
不具合を修正しました。
URLﾘﾝｸ(lll-framework.hikosha.jp)
81:nobodyさん
09/01/12 22:55:46
>>75-77
ありがとうございます。
一撃必殺JavaScript～お気に入りに保存しました。
JavaScriptは中途半端な理解で十分に使いこなせていなかったので、PHPフレームワークの次はJavaScriptの習得を目指します＾＾
82:nobodyさん
09/01/12 23:03:14
>>80
2chで釣りとか
作者必死だな・・・
83:nobodyさん
09/01/12 23:12:01
>>78
知らないフレームワークがまだあったか。
とりあえず捕捉した。
84:nobodyさん
09/01/13 00:52:46
>>78
ネタが増えるのはいいことだけど・・・
ざっくりサイトだけ読んでみて
> PHP4,PHP5両方で動作する事。
またか。
サイトにしろFWにしろ、これから新しくものを作るんならいい加減、PHP4を切り捨てた方が
すっきりといいものができるように思うのはおれが怠惰すぎるのだろうかね
85:nobodyさん
09/01/13 01:01:58
今まではレンタル鯖に入ってるバージョンの都合ってのもあったけど
去年でPHP4もサポート終わったんじゃなかったっけ
86:nobodyさん
09/01/13 01:26:26
試してみることもないからどっちでもいいよ
87:nobodyさん
09/01/13 02:22:51
php4はさっさと切ってほしいな。
メソッドにアクセス修飾子がないといらいらする。
88:nobodyさん
09/01/14 00:02:14
そんな事どうでもいいけどな
89:nobodyさん
09/01/14 02:16:40
アクセス修飾子があるスクリプト言語の方が少ない
90:nobodyさん
09/01/14 02:30:44
>>89
PerlにもRubyにもありますが
91:nobodyさん
09/01/14 02:34:16
少ないね
92:nobodyさん
09/01/14 02:35:52
protectedがあるスクリプトは少ない
93:nobodyさん
09/01/14 05:57:49
protectedがないとtemplate methodが分かりにくいよな
その点で他のLLは糞
94:nobodyさん
09/01/14 10:09:53
どうしようもないばかだな
95:nobodyさん
09/01/14 15:21:39
>>94
自分への嘆きかｗ
96:nobodyさん
09/01/14 21:39:54
Pythonのように
「全部public、ただし先頭にアンダーバーがついてたらよいこのみんなは呼ばないようにしようね」
というのもそれはそれでいいと思うけどな。
どうせprivateとprotectedとpublicで命名規則を変える事が多いわけだし。
97:nobodyさん
09/01/14 21:47:37
本末転倒だな
98:nobodyさん
09/01/16 16:43:30
URLﾘﾝｸ(jibun.atmarkit.co.jp)
林氏：Javaを勉強した後、RubyやPerl、Pythonの文法が面白くて眺めてました。
↓
参考材料にもならないPHPは脂肪(＞＜)ｗｗｗ
99:nobodyさん
09/01/16 18:21:10
文法が面白くてPHP使ってるんじゃないしな
CやJavaと殆ど同じようなもんだし
100:nobodyさん
09/01/16 18:26:35
Perlの文法の何が面白いのかわからん
101:nobodyさん
09/01/16 18:27:40
＞CやJavaと殆ど同じようなもんだし
おいおい、お前らのレベルってこのくらいなの？
102:nobodyさん
09/01/16 18:38:04
大きく間違ってはいないと思うけど？
つーか、そこにツッコミ入れる奴って…３年ROMってｒ（ｒｙ
103:nobodyさん
09/01/16 18:58:53
CとJavaとPHPは意図的に似せて作ってるからな
その上で林さんって人はそれと全く文法が違う
Ruby、Perl、Pythonを面白がったってだけだろ
104:nobodyさん
09/01/16 19:10:15
$とか.とかはPerl由来だったり、C系のポピュラーな言語に似せてあるよね。
（Perl由来の部分は単にPersonal Home Page Tools時代の名残かもしれないけど）
105:nobodyさん
09/01/16 19:10:48
ＰＨＰはウェブありきで作られた言語だから面白みを問われたらちょっとな・・
Ｃ言語の有名サイトにこんなものがある
URLﾘﾝｸ(www.kojima-cci.or.jp)
106:nobodyさん
09/01/16 19:25:15
Perlはelsifみたいなどうでもいい省略さえなければもっと使いやすいのに
逆に打ち間違うわ
107:nobodyさん
09/01/16 19:27:33
そしてその不評な省略形式を丸々真似てしまったRuby
108:nobodyさん
09/01/16 20:43:49
elsifだとどんなメリットがあるんだ？
109:nobodyさん
09/01/16 23:54:23
else if
elsif
やったぁ！2文字もタイプ量が減るぞ！！
110:nobodyさん
09/01/16 23:55:15
最初に触ったのがPerlだったせいで、
いまでもときどき elsif と elseif と else if がごっちゃになって困るｗ
111:nobodyさん
09/01/17 00:12:33
シェルも触るとelifまで候補に入ってさらにカオスw
112:nobodyさん
09/01/17 00:29:45
うわあああ
113:nobodyさん
09/01/19 01:23:11
rubyやpythonも嫌いじゃないがタイプヒンティングがないのはどうにかならんのか
引数リスト見ても何投げたらいいから分からなくてまいっちんぐ
114:nobodyさん
09/01/19 09:58:52
つコメント
115:nobodyさん
09/01/19 12:07:45
>>113
vimになかったか？
116:nobodyさん
09/01/19 22:45:12
何だかんだ言って一番馬鹿にされてるPHPが最強言語だよね(´・ω・`)
117:nobodyさん
09/01/19 22:51:44
ラズベリー賞しかり、イグノーベル賞しかり。
118:nobodyさん
09/01/20 10:49:51
>>116
Webで便利なだけでしょ。Web以外はPerl使ってるよ。最近PHPにも懲りてWebもPerlも使い出した。
Catalystマンセー
119:nobodyさん
09/01/20 11:49:35
>>118
Catalystもそうだけど、CPAN万歳になるのが初動でのネックだと感じてる。
導入だけ、って考えるならPHPのフレームワークのほうがよほど楽。
結局は目的次第じゃないかと。
120:nobodyさん
09/01/20 12:00:08
>>119
そう。PHPはWeb以外では殆ど使い物にならないから、
最強言語だよねとか言われると困る。
ちなみにこのネタは宗教論争を呼ぶので早めに切り上げたい。
121:nobodyさん
09/01/20 12:23:13
PHPはWebでしか使えないというけど別に使えるんだけどな普通のスクリプトとしても
122:nobodyさん
09/01/20 12:26:00
使えないとは言ってないよ。使わないけど。
123:nobodyさん
09/01/20 12:26:09
ちょっとしたスクリプトもPHPで作ってる
普段使ってるから作りやすくて楽
124:nobodyさん
09/01/20 12:58:05
*nixの管理ツールなどでPHPで作られたものなんて見たことない。
使われているのはPerl、Python、Rubyのどれかだろ。
125:nobodyさん
09/01/20 13:08:13
PHPはmod_php以外だとはっきり言って魅力ないからな
126:nobodyさん
09/01/20 13:15:22
>>124
たまにＰＨＰ自作ツール見かけて「ぷっ」と思う。
なんかそんなイメージ。
127:nobodyさん
09/01/20 13:17:21
>>124
shを忘れないで下さい。
128:nobodyさん
09/01/20 13:22:10
cronで回しているウェブ用データ整理はCLI
自作ライブラリ使い回せるし
129:nobodyさん
09/01/20 13:31:39
>>128
他人がいじれない確率が高いのがネックだな。
130:nobodyさん
09/01/20 13:37:08
>>128
それはWEBアプリの一部ではないのだろうか。
まあ一般論だとしても、これは実は結構大きいんだけどね。
WEBでPHPを使ってるんなら、CPANとかいちいち使い方調べるのは効率悪いとも思う。
でも、それをやっとくと比較的汎用的なスキルにはなってそうな気もするから迷う。
（自作ライブラリが陳腐化した時とか、そもそも違う環境で作業しなきゃいけないとか）
結局 得意な言語が１～２個あり、その他も好き嫌いしないで使えるってのが理想では
あるんだけど。
131:nobodyさん
09/01/20 14:53:10
>>124
監視しない方ですか
132:nobodyさん
09/01/20 15:09:20
>>124
RubyはないだろJK
いや少しはあるかもしれんが、
基本はPerlかPython。
133:nobodyさん
09/01/20 15:15:18
おれの基本はbash
134:nobodyさん
09/01/20 15:52:58
OSやM/W自体の監視と、そこで動くアプリケーションの監視を混同してないか？
前者ならPerlが多いと思うし、後者でDBも監視するなら
そのアプリケーションで使ってるライブラリ使ってDBアクセスしたほうがいいだろうし。
135:nobodyさん
09/01/20 19:57:05
>>132
言っちゃダメーｗｗｗｗ
本人はPerlかPythonに並ぶメジャー言語だって思ってんだからｗｗｗ
136:nobodyさん
09/01/20 20:29:13
は？puppetなんかはrubyで書かれてますが何か
今時perlなんて類人猿しか使ってねーし
137:nobodyさん
09/01/20 22:54:13
このスレでそんなこと言ってもねぇ
138:nobodyさん
09/01/21 00:00:34
Agaviの次のリリースではコマンドラインからの呼び出しがサポートされるよ。
URLﾘﾝｸ(trac.agavi.org)
139:nobodyさん
09/01/21 00:07:16
agavi静かに進んでたんだなｗ
140:nobodyさん
09/01/21 03:12:08
実際、Rubyは厳しいんじゃないかな。ウェブ系のスクリプト言語でPHPの優位は今後も変わらないでしょう。
サブの言語というか、ちょっとしたツールなら、Perlで十分だし、海外じゃPythonもあるわけで。
日本でRuby使うって、Railsを使うって言うのとイコールだと思うけど、当初はともかく、今となっては特別圧倒的に優位なウェブフレームワークじゃないし。
141:nobodyさん
09/01/21 03:25:00
Rubyは立ち位置が微妙だよな
ニッチ言語でもないし
142:nobodyさん
09/01/21 07:20:17
なんというか利点がないんだよな。Ruby使う
143:nobodyさん
09/01/21 08:54:04
Ruby/RoRのModelで関連テーブルが扱えないのは治ったのか？
俺はあれでRoRって使えねーって思ったんだが。
144:nobodyさん
09/01/21 10:38:16
企業からすれば、習得のためのコストは少ないほうが良いに決まっている。
145:nobodyさん
09/01/21 11:00:58
>>144
出来る人間なら習得コストは同じだよ。何でもすぐ覚える。勝手に覚える。
知らない間にPerlとかに手を出してる。
PHP手取り足取り教えてやっと使い物になるような人材は嫌だなあ。
146:nobodyさん
09/01/21 11:03:52
嫌とか嫌じゃないかの問題じゃなく、
コストの問題でしょ
147:nobodyさん
09/01/21 11:16:40
>>146
教材は何でもいいよ。ダメなら切るだけ。だからコストは一緒。
出来る人間がPHP覚えるのもPerl覚えるのも大差ない。
148:nobodyさん
09/01/21 11:27:19
出来る人間だけ揃えられる企業ならともかく、
能力にばらつきがあるのが世の常でしょ
149:nobodyさん
09/01/21 11:30:39
>>148
まあその辺は会社によって違うかもな。
PHPは教材としてイニシャルコストは安いと思う。
どの言語も結局は同じくらいのコストがかかるんだがな。
150:nobodyさん
09/01/21 12:27:49
求人するのタダじゃないんだぞ。
そう簡単に切ったり雇ったりできるか！
言語を教材なんて言ってる時点で仕事じゃない
コスト考えるなら即戦力。即戦力を考えたら普及している言語が有利に決まってるだろ。
今話題の派遣とかが会社にとって効率がいい
151:nobodyさん
09/01/21 13:08:07
雇って育ててるのは相当余裕がある会社ということか。
プログラマ堅気を見抜けるエスパーが社に一人いると便利だよ。
152:nobodyさん
09/01/21 13:38:39
即戦力なんてほとんどいない
特に新卒とか
153:nobodyさん
09/01/22 03:26:59
Rubyの習得コストが低いって嘘はどっから出てきたんだ
まさか日本人が作った言語だから日本人に解りやすいとでも思ったのか
154:nobodyさん
09/01/22 03:33:43
まぁ、派遣メインの場合、本当は戦力じゃないPGを、
ねじ込んでしまえば、人材という商品にはなれちゃうからな。
とりえずphpかJavaできますと言って、嘘にならなければ戦力。
今となっては、というお話だったとさとしか言えんがｗ
155:nobodyさん
09/01/22 04:44:46
金融なんかは人月稼いでなんぼみたいな所あるからね
どれだけ大人数で時間書けてやったかがリーダーの実績みたいなｗ
だからコンサルファームはとにかくスキル関係なく人を入れたがる
156:nobodyさん
09/01/22 04:53:28
問題化しないギリギリまで長期化させて、
ギリギリ成功といえる状態で、案件を終わらせるのが、
優れたリーダーってことか。
とても楽しくなさそうだ。
157:nobodyさん
09/01/22 05:37:45
客が怒る寸前まで常駐させて貰うのがキモです
運用は儲からないんです
158:nobodyさん
09/01/23 02:44:44
フレームワークスレでも土方さん多いのな。
そんなもんか。
159:nobodyさん
09/01/23 08:09:25
お前はアホか
160:nobodyさん
09/01/27 00:00:53
Yiiいいじゃん
161:nobodyさん
09/01/27 23:42:06
>>160
そうなの？
162:nobodyさん
09/01/28 00:04:30
サーバ側でmemcacheとか用意しないとならんけどな
DBアクセスするならPDOとかもPear側で準備しとかないとならん
あと結構依存するライブラリたくさんある
フレームワークの意味あんのか
163:nobodyさん
09/01/28 00:05:19
ZendFW使ってるけど、他の使ってない俺から見ればこれで十分な気ｶﾞｽ
164:nobodyさん
09/01/28 00:12:52
PDOをPear側で準備・・・？
165:nobodyさん
09/01/28 00:26:31
ああごめん
PDOがPearじゃなくて"とか"をPearで用意する必要があるものもあるって事ね
CakeとかZendとかPearフリーじゃん
それの対比でYiiは違うよと
166:nobodyさん
09/01/28 00:52:28
PDOとかをPearで準備・・・？
167:nobodyさん
09/01/28 00:55:30
ZendFWでのDB接続は基本PDOだけど・・・
168:nobodyさん
09/01/28 01:01:34 VWeywu5Y
>>162
memcacheは必須じゃないでしょ？
逆にCakeでもZendでもキャッシュのバックエンドにmemcacheを使うなら
サーバ側で用意するのは一緒。
> あと結構依存するライブラリたくさんある
例えば？
> フレームワークの意味あんのか
依存するライブラリの多寡とフレームワークの意味は関係ない概念だと思います。
169:nobodyさん
09/01/28 07:10:16
信者ｗ
170:nobodyさん
09/01/28 08:17:44
>>162はmemcacheって言いたかっただけじゃないかと
ActiveRecordをシンプルに使えてちょっといい感じだけどな ＞ Yii
ただ、拡張をどうすればいいのかちょっとまだよくわからん
171:nobodyさん
09/01/28 08:19:43
ペドなんか使うなよ
172:nobodyさん
09/01/28 11:10:45
最近、イスラエルがたくさん人を殺しているというニュース
どっちもどっちなのかもしれないけど、ほめられたことじゃないな
Zendはそんなイスラエルの会社
PHP以外でWEBアプリを作ったことがない俺
はぁ～、PHPでプログラミングしていると軽く鬱になる（＝これはイスラエルとは関係ないかもしれんｗｗｗ）
plugger(Perl)、Google App Engine(Python)でもやってみるかな？
173:nobodyさん
09/01/28 11:22:29
なんだよその上っ面だけの意見は
174:nobodyさん
09/01/28 12:50:21
PHPER=ユダヤ人
そう考えたら色々納得いくぜ！
175:nobodyさん
09/01/28 15:17:58
イスラエルで納得っていうと差別されたり、虐殺されたり、病院爆撃したりっていうこと?
あと金持ち属性もあるか。
PHPERは差別はされてるかもしれないけど、虐殺はされてないし、
病院ごとテロリストをぶっとばすのもしてないぞ、なにより金持ちでもないし。
...いや、この先IT不況が来たら大量に首を切られて虐殺されるかも...
176:nobodyさん
09/01/28 15:47:25
PHPはもうダメポと思った俺は開発をPerlに切り替えたのだが、
顧客の多くはPHP指定してくる。今のところ予想は外れたまま。
ええ、結局PHP書いてますよ。
177:nobodyさん
09/01/28 22:52:50
>>172
そこまで考えるんならさぁ。
欧米由来の言語って一切つかえなくね？
178:nobodyさん
09/01/28 23:53:34
>>176
なんで思ったの？
179:nobodyさん
09/01/29 00:07:10
>>168
Yii使いならメモとかドキュメントとかその他なんでもいいから晒してくれ
180:nobodyさん
09/01/29 01:00:41
Javaの企業需要はまだなくならない
ASP.NET系も同じく糞ゲイツ派企業の鉄板
PHPはなんだかんだでライトユーザーシェアはなくならない
---かべ---
PerlはもうすでにWebProgのCOBOL
Rubyは永遠に下火
そのた：話題に上らないほどにマイナー
>>176
PHPがだめぽってのはすごく理解できるが、
そこで何ゆえPerlなんかを選んでしまった理由を聞いてみたいｗ
181:nobodyさん
09/01/29 01:21:22
つうか、web屋ならPerl、PHP、Rubyあたりは一通り理解できて然るべきだろ。
軽量言語如きで信者論争とか、アホらしいっつうかアホそのものだ。
182:nobodyさん
09/01/29 01:35:52
理解できるのと実際組めるのとは別物だよなぁ。
昔、簡単な物ならPerlで書けたけど、今はうpロダでさえ作れないかも。
PHPしか書けないWeb屋が居てもいいよねw
183:nobodyさん
09/01/29 01:41:58
そりゃ理解できるし組めるが、できることなら糞言語は使いたくないんだ。
184:nobodyさん
09/01/29 01:51:42
組めないってことは理解できてないんだろ
185:nobodyさん
09/01/29 18:23:40
調べてみたけどいまいち情報が無いので聞かせてください。
フレームワークのSSL対応ってどうなっているのでしょうか？
単純にページをhttps://以下に置けばSSL対応になるとかいうのではありません。
http://以下の特定のページに着たらhttps://以下にリダイレクトするというものでもありません。
私が聞きたいのは、SSLページと非SSLページにまたがったアクションで
情報がどのようにセキュアに扱われているかということです。
具体的に言えば、たとえばAmazonなど、非SSLページでカートに入れて、そこからSSLページにとんで
住所などの個人情報とカートの情報を結びつけて会計処理を行えます。
また逆に個人情報を入れてからカートに追加と言う処理もあります。
SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
こういう部分をフレームワークは解決してくれているのでしょうか？
解決してくれているとしたら、どういった設計になっているのでしょうか？
186:nobodyさん
09/01/29 18:26:56
そこまで気にするならセッションIDなんてアクセス毎に変えればいいじゃん
187:nobodyさん
09/01/29 18:31:21
というかセッションIDを取れたからってどうなるというのか
188:nobodyさん
09/01/29 18:42:10
あらためて、明確にしておきます。
私が知りたいのは、フレームワークで
この問題をどう解決しているのか？
または解決していないのか？
ということです。
189:nobodyさん
09/01/29 20:08:05
百聞は一見にしかず、実際に見てみるのが早かろう
190:nobodyさん
09/01/29 20:15:44
所詮PHPプログラマ的なやりとりでワロタｗ
PHPはアンセキュアな糞フレームワークばかり
secure属性もしらなそうだな。
191:nobodyさん
09/01/29 20:45:27
フレームワークでって言われても何のフレームワークの話なのか
PHPにフレームワーク1つしかないと思ってるんだろうか
192:nobodyさん
09/01/29 20:52:01
セキュアなシステムを組んだ経験が浅い子の戯言です。
気にしないでやってください。
なぜなら、フレームワークに依存するレベルの話じゃない。
フレームワークを使ってどう実装するかという設計の問題です。
193:nobodyさん
09/01/29 21:12:16
Yiiはこんな感じ
URLﾘﾝｸ(www.yiiframework.com)
194:nobodyさん
09/01/29 22:59:54
>>185,188
195:nobodyさん
09/01/29 23:22:59
>>194
俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。
>>193で端的に答えられているが、それ以外はわざとか限界か知らんが
ことごとくピントはずれでいい感じだなｗ
で、そのYiiのようなクッキーValidationは他のフレームワークにもあったような。
196:195
09/01/29 23:33:39
って書いたが、これはCookieの改竄はチェックできてもそもそものセッションキーを盗まれた
場合には意味ないね。
考えられるシンプルな対策で、非セキュアなページではセッションを使わない、もしくは
セキュアページと共有しないってのは正味ありえないか
197:nobodyさん
09/01/29 23:48:44
非セキュアなページと、セキュアなページを同一セッションで結ぶのはユーザーの利便性の問題。
セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
その上で、承認後はセッションIDを毎ページ切り替えるってのが普通。
非セキュアなゾーンでセッションキーを盗んでも、匿名の個人情報が見れるだけで
実害はほとんどない。
これはフレームワーク層じゃなくて、ビジネスロジック層で実装するもんだよ。
198:nobodyさん
09/01/30 00:47:54
だからアクセス毎にセッションID変えればええやん
199:nobodyさん
09/01/30 00:56:28
YOU全部HTTPSでやっちゃいなよ
200:nobodyさん
09/01/30 02:29:11
俺には結構まっとうかつこのスレにふさわしい質問だと思うんだが。 （ｷﾘｯ
201:nobodyさん
09/01/30 03:47:52
煽ってるとこすまんが、同意するよ。
PythonやらRubyやらPerlがphpと比べてどうのとか、
ぜんぜん関係なかったし。
202:nobodyさん
09/01/30 08:04:53
>>197
>セキュアなページに入ってきたら、必ず一度はそのユーザーの有効性を確認するように実装するのが当然。
これがわからん。どうやって確認するの？
例えばユーザでログインした後、トップページからお問い合わせフォーム（もしくはその確認画面）に進んだだけで
パスワード入力を求められるようなサイトは現実的かな？
Amazonみたいに、重要な操作の前にいちいちパスワード入力を求めるっていう感じかな。
それとも、セッションに頼らない確認方法があるんだろうか。
流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
203:nobodyさん
09/01/30 08:27:30
だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
アマゾンのように、長いセッションを維持するサイトでは、重要な操作の前に、
必ずパスワードを確認させて、セキュアなセッションは短くしている。
Yahooでもクッキーを数種類使いつつ、クラムというフォーム追跡を埋め込んで、
通常ログイン状態とセキュアログイン状態を識別、追跡している。
だから、パスワードの再確認を求められるケースとそうじゃないケースがある。
そういうギミックを持ってないところは、ショップなどのように金銭が絡むところは
まるっとHTTPSで実装する。
> 流行の一時トークンも、ぶっちゃけクッキーやらPOSTだったら一緒に盗まれるんじゃないの。
それはどういうレイヤーで話をしてるの？
プロトコルの欠陥？ネットワーク盗聴？ブラウザーのバグ？
204:nobodyさん
09/01/30 08:44:58
>>202
盗まれても良いための「ワンタイム」トークンじゃないの？
205:nobodyさん
09/01/30 10:08:00
>>203
クッキーが盗まれる、っていう現象で想定のメインは「ネットワーク盗聴」じゃね？
他にもあるのか俺は知らんが。
例えばXSSで盗まれるのであればSSLなんて関係ないわけだし
>>204
毎回セッションIDを変えるってので兼用できてそうな気がするから、併用して
冗長にしてチェック、かな？
どのみちタイムアウトの設定次第の様な気がする。
206:nobodyさん
09/01/30 10:33:33
>>205
ネットワーク盗聴ならSSL下では問題ないって前提でいいわけだよな。
(SSL下でも解読できるとか行っちまったら元もこもない）
SSL下でsecure属性をつけたクッキーを出すのが普通なんで、
復路の盗聴はないし、ワンタイムトークンを使う限り
タイムアウトはセキュアセッションと同等でいいよな。
あんまりにも普通なこと過ぎて書くのが恥ずかしくなってきたわ。
207:nobodyさん
09/01/30 10:39:58
>>203
> だから、個別のサービス思想に絡んだ設計の問題なわけでそ。
そういう場合に、どっちの方式をとるかは設計の問題だね。
だけどフレームワークの意味をもう一度思い出してほしい。
汎用的で複雑な処理を簡単に実装できることだ。
重要な操作の前に確認したいのなら、
プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。
208:nobodyさん
09/01/30 10:43:17
>>197
> 匿名の個人情報が見れるだけで実害はほとんどない。
これは笑う所かいな？ｗ
個人情報＝本名・住所等
匿名の本名・住所等が見れるだけで実害はほとんどない。
匿名になってないじゃないか～い。
209:nobodyさん
09/01/30 10:46:19
>別ウインドウを出したとき問題になる。
AmazonやYahooでいつ別ウインドウが出るってんだ
その手のサイトでログイン後に別ウインドウとかアホ設計だろうに
210:nobodyさん
09/01/30 10:49:28
>>209
別ウインドウってのは人間が出すんだよ。
ネットワークが遅いから、過去の履歴の詳細をいくつも別ウインドウで開くとか
（一つのウインドウの内容を見ている間に、他のページの読み込みが終わっている）
211:nobodyさん
09/01/30 10:51:55
>>208
もしかしてそこが笑うところ？
> 個人情報＝本名・住所等
そんな決めつけでよくやってられるな。
たとえば、性別とか好みとかカートの中身とか、クリック動向とか
個人を特定できないが個人に関係する情報も個人情報だろが
212:nobodyさん
09/01/30 10:52:36
>>207
あと、毎回セッションIDを変える方法は、
別ウインドウを出したとき問題になる。
ない。
213:nobodyさん
09/01/30 10:55:22
毎回セッションIDを変える方法は
連続でリロードすると問題になる。
サーバーでは値が変わっているが、
クライアントでは新しい値を受け取っていないなど。
214:nobodyさん
09/01/30 10:55:54
>>207
> だけどフレームワークの意味をもう一度思い出してほしい。
> 汎用的で複雑な処理を簡単に実装できることだ。
セキュアセッションは汎用的でも複雑でもないだろ。
関数一発挟むだけなのに、それをプロパティで設定しろってか。
215:nobodyさん
09/01/30 10:57:40
>>213
あほ？
別ウインドウを出したり、連続リロードで動作しちゃいけないのがセキュアゾーン
216:nobodyさん
09/01/30 10:57:52
セキュアページに入る前に
必ず認証が必要だというが、
Amazonはそうなっていない。
これを実現できるフレームワークは皆無ってことでおｋ？
217:nobodyさん
09/01/30 11:00:03
>>215
だが、Amazonは別ウインドウを出しても、連続リロードしても問題ない。
これを実現できるフレームワークは皆無ってことでおｋ？
218:nobodyさん
09/01/30 11:01:38
>>216
アマゾンはそうなってるよ。
すでにセキュアトークンを持ってれば別
フレームワーク乞食乙
219:nobodyさん
09/01/30 11:04:46
>>218
それは、ブラウザ起動して初めてログインした場合だろ。
一度ログインしていれば、非セキュアページから
セキュアページに入るときにパスワードは要求されない。
一度注文履歴を見たあとで、トップに戻れ。
トップから、もう一度注文履歴を見る間にパスワードを聞かれるか？
220:nobodyさん
09/01/30 11:12:49
>>214
> 関数一発挟むだけなのに、それをプロパティで設定しろってか。
関数一発挟むだけじゃないな。
Windowsプログラミングじゃあるまいし。
パスワード入力ダイアログを出して終わりじゃないんだよ。
認証が必要になった場合に、他のページに飛ばさないといけない。
そこから戻らないといけない。
一回目（認証前）と戻ったときの二回目（認証後）で違う処理をしないといけない。
必ずパスワードを出すというわりに、認証後はパスワードを出さないという風に矛盾している。
221:nobodyさん
09/01/30 11:23:06
>>207
> あと、毎回セッションIDを変える方法は、
> 別ウインドウを出したとき問題になる。
ただ単に、どっちかのセッションが使えなくなるだけじゃない？
問題なし
222:nobodyさん
09/01/30 11:24:24
>>219
それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください
>>220
よーくわかった。(ry
223:nobodyさん
09/01/30 11:25:39
>>219
> すでにセキュアトークンを持ってれば別
ってちゃんと書いてるだろ。
224:nobodyさん
09/01/30 11:39:10
そもそもAmazonはJavaで独自実装だから
PHPフレームワークスレでこんな機能が全て実現できるフレームワークは
PHPにないよね！って言われた所でなんなんだっていう
ちなみにPerlでもJavaでもASPでもそんなフレームワークはない
その辺は自分で実装する
225:nobodyさん
09/01/30 12:33:45
>>207
>だけどフレームワークの意味をもう一度思い出してほしい。
>
>汎用的で複雑な処理を簡単に実装できることだ。
>重要な操作の前に確認したいのなら、
>プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
>
>YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
>作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
これがフレームワークが提供すべき汎用的な機能かと言うとどうだろうね？
226:225
09/01/30 12:35:02
追記：
「Webアプリケーションフレームワークが」提供すべきかどうか、ね。
227:nobodyさん
09/01/30 12:46:45
重大なセキュリティに絡む部分をオープンなフレームワークで吸収したら
そこにバグがあったらそれ使ってるシステムみんな死亡じゃん
クリティカルな部分は独自に実装するからバグがあってもなんとななるわけで
228:nobodyさん
09/01/30 13:17:58
>>227
んなこといったら、プレースホルダ使いたい、使わせたい為だけにPEAR::DB使ってた人間とか涙目だろ。
実際そういった判断は、凡PGに任せるより遙かにセキュアだったと思うがな
フレームワーク（というか基底ライブラリ）の有用性の一面を完全否定っすか。
229:nobodyさん
09/01/30 13:34:34
>>227
問題はバグがどうたらじゃないよ
設計や計画にはちゃんとした理解が必要だが、コーディングが難しかったり
面倒だったりするわけじゃないからFWに任せる内容じゃないってことだよ。
コーディングの助けっていう意味程度なら、どのFWにもセキュアセッション
を扱う機能や、ワンタイムトークンを自動でハンドリングするフォーム要素とか
一通りのものは揃ってる。
が、ページ遷移設計まで自動化してほしいとは思わないけどな。
PieceFrameworkあたりなら、その辺はすでに実装済みかもしれんけど。
230:nobodyさん
09/01/30 13:36:33
CakePHPは実際AuthComponentで誰でもログインできるってバグ出して死亡したけどなｗ
ああいうのはFWで吸収しない方がいい
231:nobodyさん
09/01/30 13:38:02
>>229
きちんと実装されるかどうかじゃなくて、フレームワークの場合は
そういうバグがありましたって公開されちゃうから、フレームワーク使ってるのバレると
悪用されるってことじゃないの？
独自実装ならクソみたいな実装でも中はどうなってるかアタックするまで解らんのだし
232:nobodyさん
09/01/30 13:43:38
>>230
言ってみれば各フレームワークも、それぞれの独自実装の固まりだからな
ある程度のライブラリくらい共用して欲しいような気もする今日この頃。
APIも統一されるし。
233:nobodyさん
09/01/30 13:53:53
cookieのsecure属性を理解してないヤツが混じってる予感。
234:nobodyさん
09/01/30 13:57:42
>>230
それは、バグがあるのがわるいだけだろｗ
235:nobodyさん
09/01/30 14:24:52
ごっつい根本的な質問で恐縮ですが
PHPって複数のセッションを同時に利用することってできるの？
それができるかできないかで、ものすごく話が変わってくるような。
・・・できないんだろうな。$_SESSION だもんな・・・
236:nobodyさん
09/01/30 14:32:51
>>235
微妙にスレチだぞ＞くだすれ行けって感じだが・・・
無理やりFWレイヤーの話に持ってくると、Zend_Sessionではセッションの配列で
ネームスペース的な扱いをして、使い分けている。
でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
分割して持てるか？って話をしたいわけだよな？
PHPが受け入れるセッションID自体は一つ。それは正しい。
解は二つ。
クッキーと独自のバックエンドを使って、自前でセッション機構を作る。
セッションを理解してれば、簡単。
ちなみにYahoo!はPHPでこの方式を採用してる。
もう一つは、セッションそのものは永続化しておいて、セッションネームスペース内
に侵入を許す際に、そのネームスペースに対する適切なアクセスかどうかを個別のクッキーで検証する。
ZFで実装してるやつはたぶんこれがFA
237:nobodyさん
09/01/30 14:42:03
>>234
いや
これがCakePHPだから、セキュリティ情報として全世界にこういうバグありますよって公開されちゃうわけよ。
その情報を見てクラッカーが仕掛けてくる可能性が高い。
もし仮に自分で全て実装したものに同じバグがあったとしても、よっぽどしっかりクラックされない限り、誰にも知られることはない。
238:nobodyさん
09/01/30 14:47:27
>>236
> でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
> 分割して持てるか？って話をしたいわけだよな？
ですです。それができれば、盗聴（非SSL）でセッションハイジャックされたとしても
その中には非セキュア用の情報しかないし、セキュア用のセッション（ログイン状態）等と
簡単に切り分けできるなーと。
ただ、他の言語の実装をみても、「セッション」ってもの自体の考え方が、どうやらサーバ-
クライアントで1対1っぽい？
＞解は二つ。
もう一つ、セッションはあくまでsecureで利用して、非セキュアな情報はみんなCookieに
放り込めばいいじゃない！ってふと思いついた。
最低4KB×20(50？)個なら、とりあえず普通に使えそうとか。
239:nobodyさん
09/01/30 14:54:52
Cookie切ってる奴多いのに通用するのかそれ
セキュリティソフトのせいで動きませんみたいなサイトになるぞ
240:nobodyさん
09/01/30 15:02:01
Cookie切ってる奴多い？
根拠は？
241:nobodyさん
09/01/30 15:09:40
>>239
もしかしてセッションIDをフォームに手で埋めるのが標準？
まじでか
242:nobodyさん
09/01/30 15:14:39
>>239
Cookie切ったら普通にセッション動かないけど？
243:nobodyさん
09/01/30 15:15:10
みなさ～ん、そろそろスレチですよっと。
244:nobodyさん
09/01/30 15:18:00
ほかの言語の話になってるよりましだし、いいんじゃないの？
245:nobodyさん
09/01/30 15:32:12
SSLの話題が出ているので便乗質問。
共有SSLに対応しているフレームワークってある？
URLﾘﾝｸ(www.aaa.com)
URLﾘﾝｸ(www.rental-server.com)
こうなっているときに、ドメイン名違うし、パス違うしで
セッション保てないわで、困るんだよね。
246:nobodyさん
09/01/30 15:33:30
クッキー切ってるような変人相手にする必要なし
むしろブラクラに飛ばしてやれ
247:nobodyさん
09/01/30 15:34:14
Cookie切ってセッション動かないとかどんなクソ実装だよ
それじゃ携帯サイト対応できねーじゃん
248:nobodyさん
09/01/30 15:39:41
うーん。セキュリティ周りをちゃんと説明しているサイトが見つからない。
クッキー切っている場合（携帯対応）のセッションで
cookieにsecure属性をつけた場合の動作と同じことを
ちゃんとやっているのか確証を得たいが見つからない。
249:nobodyさん
09/01/30 15:48:16
Cookieが普通で携帯が異常なだけだろ。
250:nobodyさん
09/01/30 15:54:21
DoCoMoの携帯がクッキー非対応で異常だからってことで、
非対応にしてるサイトってあんまないけどな。
結局Cookie使わなくてもセッションは維持できる。
251:nobodyさん
09/01/30 16:09:01
>>247
携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。
PerlならMobaSifがあるけどなぁ。
252:nobodyさん
09/01/30 16:17:17
>>245
>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう
クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか
253:nobodyさん
09/01/30 16:23:31
URLにセッションID差し込んでCookie使わない実装にするのなんて普通だろ
IDはアクセス毎に変える
254:nobodyさん
09/01/30 16:30:00
>>253
これを言い出すと、もうセッションIDのクッキーをsecureにする意味もないな
255:nobodyさん
09/01/30 16:40:23
>>253
PHPの$_SESSION自体そういう仕様になってなかったか？
256:nobodyさん
09/01/30 17:04:49
use_trans_sid
257:nobodyさん
09/01/30 17:05:43
まぁ、URLに差し込むだけじゃ携帯全機種対応は無理だけどな。
258:nobodyさん
09/01/30 18:19:42
っていうか議論に問題だらけの端末の話を持ってくるのは暴論じゃないか？
携帯サイト対応ってそれだけで一仕事だよ。
259:nobodyさん
09/01/31 01:06:04
SSL対応議論、参考になります！(ｷﾘｯ)
この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな～＞＜
260:nobodyさん
09/01/31 02:01:11
誰も十分に理解できていないから、
はっきりとした答えが出せないんだろうな。
261:nobodyさん
09/01/31 02:27:29
土日を利用して勉強してみましょう
継続を使ったWEBアプリ
URLﾘﾝｸ(www.thinkit.co.jp)
Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
URLﾘﾝｸ(www.kahua.org)
セッションも良いけど継続もね☆
262:nobodyさん
09/01/31 04:23:52
クッキーはサイズの制限があるから結局セッションを使うとして、
そのセッションをどうやって実現しているかだ。
セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）
問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。
もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。
そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。
263:nobodyさん
09/01/31 07:40:31
>>262
おまいさんの理解が浅いということだけはわかった。
何も書かないと単なる煽りと思われるので一つだけ例示すると、
> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。
それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。
情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。
264:nobodyさん
09/01/31 11:43:58
>セキュアな情報を表示するためのトークン
それって一般にはセッションIDって呼ぶと思うの。
265:nobodyさん
09/01/31 11:53:41
いいえ
266:nobodyさん
09/01/31 12:16:29
おせっかいなオレが例を出したるわ。
・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす
すくなくとも$uniqをセッションIDとは言わない。
267:nobodyさん
09/01/31 12:29:26
>>266
で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。
おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。
268:nobodyさん
09/01/31 12:48:08
なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
269:nobodyさん
09/01/31 12:55:21
そんなに欲しかったら開発リクエストすればいいんじゃない？
投票が集まればサクッと作るでしょ。
270:nobodyさん
09/01/31 13:09:29
>>268
>>266の処理を一行で書かれたら絶対に読みたくない。
271:nobodyさん
09/01/31 13:31:24
>>268が冗長なだけ
272:nobodyさん
09/01/31 13:32:03
>>268じゃなくて、>>266
273:nobodyさん
09/01/31 15:14:35
>>262-272
マジで参考になります＾＾（もっとやれ的な意味で）
274:nobodyさん
09/01/31 15:30:40
フレームワークを勘違いしたひとが沸いて荒らしてくれたおかげでスレの進みが半端ネェ！
たまにこういうことがあるから面白い
275:nobodyさん
09/01/31 15:51:36
>>274
フレームワークの話題も振れずかといって実装についての話もできないのに
レスするのって寂しくならないか？
276:nobodyさん
09/01/31 15:51:43
>>266
そこら辺の処理をちゃんと説明している本って無い？
277:nobodyさん
09/01/31 15:55:18
>>268
> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。
ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。
278:nobodyさん
09/01/31 16:03:23
汎用的ではない。
インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。
279:nobodyさん
09/01/31 16:04:02
>>277
それはフレームワークのよいところを語りたかったわけ？
280:nobodyさん
09/01/31 16:10:55
>>277
それが汎用的な処理だっていうんなら、汎用的なクラスを書いてここに貼ってくれ
みんな喜ぶ。
281:nobodyさん
09/01/31 16:45:58
>>280
ヒントやるから実装は自分でやれな。
SSL_Login_Class
セキュアにするべきページの一覧や正規表現を設定配列に入れておく。
全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
セキュアページにhttpでアクセスしていたら、httpsにリダイレクト
セキュアトークンを持っていなければ、ログインページにリダイレクト
ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）
セキュアトークンのサーバー側のデータは、セッションでも独自のファイルやデータベースにも格納可能。
ハッシュはsha1でもそれ以外でも選択可能。
以上のことをやってくれるクラス。
使い方は簡単。CakePHP風に言えば共通のコントローラAppControllerの
componentsに上記のクラスを入れるだけ。これとセキュアページのリストさえあれば
具体的な実装を書かなくてすむ。
282:nobodyさん
09/01/31 16:52:07
それのどこが汎用的なんだよ。個別実装べったりじゃん。
日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
283:nobodyさん
09/01/31 17:04:17
>>282
お前にとって汎用的とはどういうことを指す言葉なんだ？
例を出して説明したまえ。
284:nobodyさん
09/01/31 17:13:02
セキュアにするためのロジックだよ。
>>266に書いてあるのは、セキュアなサイトを作る時のHelloWorld
実サイトでは、Yahooにしろamazonでも楽天でも>>266とは別のロジック。
そういうロジックを設定でインジェクションできないなら汎用的とは言わない。
285:nobodyさん
09/01/31 17:15:21
>>284
>>281のはロジックの一つだよ。
別のロジックを使いたければ、別のロジックを実装したクラスを
AppControllerのcomponentsに設定すればいいだけ。
これで汎用的になりましたね（笑）
286:nobodyさん
09/01/31 17:18:05
あほか、だったら、FWが持ってる認証クラスで十分やんけ
287:nobodyさん
09/01/31 17:20:51
んだ。
288:nobodyさん
09/01/31 17:22:06
>>286
本当に十分なのか？ FWが持っている認証クラスが
このようなロジックになっているのか？
>>266のロジックなのか？ それともYahoo、Amazon、楽天のロジックのなのか？
それが、そもそもの>>185,188の質問だろうが。
> フレームワークのSSL対応ってどうなっているのでしょうか？
それで答えは？
289:nobodyさん
09/01/31 17:24:30
>>288
結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
ロジックを実装したクラスを設定するわけだろ。
それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
>> フレームワークのSSL対応ってどうなっているのでしょうか？
> それで答えは？
対応する必要なし。
290:nobodyさん
09/01/31 17:26:44
>>289
> それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
そのロジックをお前は毎回作るのか？
そのロジックは使いまわし出来るだろ？
それを汎用的という。
291:nobodyさん
09/01/31 17:27:35
>>285
> >>281のはロジックの一つだよ。
うは、コンクリートじゃんおもいっきり
292:nobodyさん
09/01/31 17:28:05
> 結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
考え方がおかしいね。 >>281のクラスを使ってサービスを実装するんじゃない。
なにかのサービスを実装したとき、>>281のクラスを利用する。
考え方が逆だよ。
293:nobodyさん
09/01/31 17:28:45
>>291
コンクリートだねぇ。だからなに？
294:nobodyさん
09/01/31 17:29:28
>>290
元はといえば、お前さんの書いたクラスのサンプルが汎用的じゃないわけだろ。
ロジックはサイトの管理ポリシーによって違うでしょ。
それをカバーできるようは汎用的な設計を示してから言ってくれ。
295:nobodyさん
09/01/31 17:30:02
>>293
汎用的じゃないって、告白ありがとう
296:nobodyさん
09/01/31 17:31:17
>>292
>>281のクラスじゃ実装できないサービスがてんこ盛りなんですが
297:nobodyさん
09/01/31 17:32:13
>>294
お前はロジックという言葉の使い方がおかしい。
管理ポリシーは違っても、それを実装するロジック（数パターンある）は同じ。
ロジックと管理ポリシーは違うもの。
298:nobodyさん
09/01/31 17:35:29
>>297
まぁ、そういうことだろうな。
数パターンしか思いつかないレベルならいいや。おまえさんすごいよ。
299:nobodyさん
09/01/31 17:38:04
>>295
あのなぁ。お前、コンクリートと汎用的とは別の考え方だよ。
GUIの例で言えば分かるだろ。
テキストボックスはコンクリートクラスであるが、
汎用的に使われるパーツだ。
抽象クラスと汎用的つ使えるクラスをごっちゃにするなよ。
300:nobodyさん
09/01/31 17:40:29
>>299
君の汎用的ってのは、１つのロジックを複数のサイトで使えるってことね。了解
301:nobodyさん
09/01/31 17:42:09
ちょっと、みなさん、クールダウンしません？発散しすぎ
302:nobodyさん
09/01/31 17:42:45
>>300
いや常識（笑）
汎用的なパーツは、一つのパーツを複数のサイトで使える物。
それ以外の意味なんて無いだろｗ
まさか今まで抽象クラスの話をしていたのか。驚きだｗ
303:nobodyさん
09/01/31 17:48:13
やっぱおかしいと思ったんだよ。なんかずれてるって。
この質問をしたのは正しかった。 ↓
> 282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???
> それのどこが汎用的なんだよ。個別実装べったりじゃん。
> 日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
>
> 283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???
> >>282
> お前にとって汎用的とはどういうことを指す言葉なんだ？
>
> 例を出して説明したまえ。
この質問の時点で抽象クラスのことって言ってくれれば話は早かったんだが。
ちゃんと質問に答えてくれていれば
この時点で、君の汎用的ってのは抽象クラスのことね（笑）で終わっていた。
304:nobodyさん
09/01/31 17:53:26
クールダウンして>>185,188の質問に戻ろうか？ｗ
> フレームワークのSSL対応ってどうなっているのでしょうか？
305:nobodyさん
09/01/31 17:53:36
>>302
>>303 熱いねぇ
>>280は汎用的なクラスと書いてるなぁ。
>>281は個別実装でも別サイトで利用できたら汎用的なんだってさ。
汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
少なくともコンクリートのことじゃないと思うが、まぁ個人的な見解だからいいや。
それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
> こういう部分をフレームワークは解決してくれているのでしょうか？
> 解決してくれているとしたら、どういった設計になっているのでしょうか？
さすが、こういうレベルの人の頭の中は面白い。
306:nobodyさん
09/01/31 17:55:15
>>303
>>284でFAだが？
307:nobodyさん
09/01/31 17:55:39
> 汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
> 少なくともコンクリートのことじゃないと思うが
それは無いｗ
308:nobodyさん
09/01/31 17:57:54
>>305
> それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
別に、分かりやすく言い換えただけで
汎用的なクラスという言い方でもいいが？
309:nobodyさん
09/01/31 17:59:46
以 下 、「 汎 用 的 」 禁 止。
こんないい加減な言葉で喧嘩するなｗ みっともない。
310:nobodyさん
09/01/31 18:02:05
クールダウンして>>185,188の質問に戻ろうか？ｗ
> フレームワークのSSL対応ってどうなっているのでしょうか？
311:nobodyさん
09/01/31 18:06:32
>>302
> いや常識（笑）
> 汎用的なクラスは、一つのクラスを複数のサイトで使える物。
> それ以外の意味なんて無いだろｗ
先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？
312:nobodyさん
09/01/31 18:07:49
> 先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？
複数のサイトで使えないクラス。
それがビジネスロジックを記述したクラス
313:nobodyさん
09/01/31 18:39:23
じゃ、>>281のロジックはどこのサイトでも使いようがないので、
>>302の定義でも汎用的ではないってことで落ち着きそうですね
314:nobodyさん
09/01/31 19:12:22
基幹業務系の処理なんて再利用できるほうが珍しいｗ
315:nobodyさん
09/01/31 20:17:12
>>313
そうか？
手法に致命的な欠陥がない限り多分そのまま普通に使えるし、使ったなりのシステムになると思うんだが。
ただ単に、>>313(とか>>282？)がそのやり方を使いたくないだけではないかとちょっと思った。
316:nobodyさん
09/01/31 20:31:55
え、欠陥見えない？
317:nobodyさん
09/01/31 20:46:34
>>316
リダイレクトがちょっと引っかかるがそこは適当な処理に読み替えるとして、
致命的な欠陥があるなら指摘してみたらいいじゃない。正直煽りうざい
318:nobodyさん
09/01/31 21:02:59
致命的とは思わん、が、ショップじゃ使えないな。売り上げが落ちる。
煽り？どこが。
319:nobodyさん
09/01/31 21:03:44
だから、使えないというのなら、その理由を指摘してみたらいいじゃない。
320:nobodyさん
09/01/31 21:05:32
売上が落ちるから、でわからんの？
321:nobodyさん
09/01/31 21:06:31
2段階ログインはありがちな処理だし、使いまわせないとは思わないな。
まあ、好みの問題はあるだろうが。
俺なら設定依存じゃなくてコントローラから明示的に呼び出す方式にするかな。
フレームワークにもよるだろうし、どっちの方法も一長一短だけど。
322:nobodyさん
09/01/31 21:06:54
分かるわけ無いだろｗ
どういう理由で売り上げが落ちるんだよｗ
323:nobodyさん
09/01/31 21:07:36
>>318
最初からそう書けば誰も煽りとは思わんよ
ああ、なんか違う話をしてる人がいるなーって思うだけでｗ
324:nobodyさん
09/01/31 21:08:19
インフラと絡むが、セッション固定攻撃は可能だし
325:nobodyさん
09/01/31 21:08:37
>>323
自演？
326:nobodyさん
09/01/31 21:10:24
2段階もなにも、ログインを強要してる段階で売上減だな
327:nobodyさん
09/01/31 21:10:39
>>324
じゃあ改良してセッション固定攻撃を防ぐようなコードにすれば
問題ないって話？
328:nobodyさん
09/01/31 21:12:42
>>326
えっ？ それだけの話？
それならログインを強要するかしないかの
オプションをつければ解決する話じゃない。
329:nobodyさん
09/01/31 21:13:06
>>327
自分のサイトは防ぐようにしてますが何か？
今は、>>281のクラス？の問題だろ
330:nobodyさん
09/01/31 21:13:38
>>328
ログインを強要しないで、>>281はセキュアにできるのかね？
331:nobodyさん
09/01/31 21:15:55
ログインしなくてもセキュアに処理できなきゃ、この手のスクリプトは無意味だよな。
332:nobodyさん
09/01/31 21:18:24
上のほうでは、一行でできるからフレームワークに入れるほどでもないと
いっているやつがいるかと思えば、話がすすんでみれば
結局、いろんなことを考えないといけないってことになってしまったな。
だからフレームワークに入れておいて簡単に使えるようにするべきだというのに。
333:nobodyさん
09/01/31 21:24:59
ワラタ。
「汎用的なカレー調理器具を考案しました」って言ってる奴に
「それじゃボルシチには使えないから汎用的じゃねえよ」
「うちは蕎麦屋だから関係ねえよ」って言ってるようなもんだな。
334:nobodyさん
09/01/31 21:25:37
>>281 がまあミスリーディングというか
> 全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
> セキュアページにhttpでアクセスしていたら、httpsにリダイレクト
ここと、
> セキュアトークンを持っていなければ、ログインページにリダイレクト
> ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
> ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）
これは別の処理
で、どちらも実は元の流れの、セキュアセッションと非セキュアセッションの持ち方について、
直接は関係ないじゃないかｗ
どう発展させるつもりだったんだろうと気にはなるが
335:nobodyさん
09/01/31 21:28:00
>>330
ようは、ゲスト会員の話をしているんだろ？
あんなの新規会員をその場で作成するのと同じことだよ。
336:nobodyさん
09/01/31 21:31:24
>>333
挙句の果てに、
「それカレー調理器具じゃねーか。そんなの汎用的とはいえない。
いろんな調理器具をはめ込める規格を作れ。」
といっているやつまでいるから手に負えないｗ
337:nobodyさん
09/01/31 21:33:17
汎用的な調理器具は鍋だろ
338:nobodyさん
09/01/31 21:34:26
中華鍋だな
339:nobodyさん
09/01/31 21:36:42
>>335
すばらしく重いサイトができそうですね
340:nobodyさん
09/01/31 21:37:11
>>337-338
コンクリートクラスはだめだって誰かが言ってたｗ
341:nobodyさん
09/01/31 21:38:09
>>339
それの解決策を君は思いつけたかな？
342:nobodyさん
09/01/31 21:38:55
それはコンクリート批判の方が当りだと思うぞ
343:nobodyさん
09/01/31 21:39:20
>>341
普通に実装してますが何か？
344:nobodyさん
09/01/31 21:40:03
じゃあ問題ないじゃんｗ
345:nobodyさん
09/01/31 21:40:36
おれにとっちゃ問題ない。
しかし、>>281は使えないよって話
346:nobodyさん
09/01/31 21:41:25
じゃあ使えるようになおせばいいだけの話。
文句はいらない。改善したコードを示せ。
347:nobodyさん
09/01/31 21:41:57
ぶｗ
348:nobodyさん
09/01/31 21:42:10
なくなｗ
349:nobodyさん
09/01/31 21:43:24
結局具体的な理由をちゃんと説明できないから
煽りだっていわれるんだよね。自業自得。
350:nobodyさん
09/01/31 21:44:50
>>185があぁいう質問の仕方じゃなくて素直に質問してたら書いたかもな。
351:nobodyさん
09/01/31 21:45:21
どうせ書いてないくせにｗ
352:nobodyさん
09/01/31 21:46:39
いいや書いてたね
353:nobodyさん
09/01/31 21:47:05
うそだなｗ
354:nobodyさん
09/01/31 21:47:22
まじ書いてたって。
355:nobodyさん
09/01/31 21:47:50
証拠は？
356:nobodyさん
09/01/31 21:48:28
>>185にしても>>262にしても単なる教えて君だよな。
ロジックを知っててフレームワークでの解決状況を聞きたいんならまだしも。
ロジックを知らない奴がフレームワークに依存しようってのがみえみえ
ちなみに、>>266を書いたのは俺。
おまいさんは、>>281でそれをぱくっただけ。
まだ、煽って情報引き出そうってか。
つらの皮厚いのう
357:nobodyさん
09/01/31 21:49:08
いいから証拠は
358:nobodyさん
09/01/31 21:50:05
357 ：nobodyさん：2009/01/31(土) 21:49:08 ID:???
いいから証拠は
359:nobodyさん
09/01/31 21:50:14
> ちなみに、>>266を書いたのは俺。
つまり、そもそも>>266に問題があるということか。
360:nobodyさん
09/01/31 21:50:46
スレ読み直してみろよ。答え含んでるから
361:nobodyさん
09/01/31 21:51:05
自分で読み返してそこの部分を引用しろ。
362:nobodyさん
09/01/31 21:52:14
>>359
そうだよ。そういうサイトもありだが、それは一例にすぎない。
つまり、セキュアサイトの扱いはビジネスロジックそのものなんだよ。
セキュアサイトの扱いが数パターンって誰かが書いてたが、
数パターンなんてもんじゃない。それを知ってかいてるかどうかの違い
363:nobodyさん
09/01/31 21:52:18
スレ伸びすぎワロタ
364:nobodyさん
09/01/31 21:52:54
>>361
断る
365:nobodyさん
09/01/31 21:53:13
>>362
つまり、ありなんだろ？
366:nobodyさん
09/01/31 21:53:34
>>364
それ俺のせりふｗ
367:nobodyさん
09/01/31 21:53:43
>>365
ありだ。しかし、極めて限定的なサイトの特殊ロジック
368:nobodyさん
09/01/31 21:54:18
極めて限定的なサイトの特殊ロジックだが ありだ。
このように書いてくれんか？ｗ
369:nobodyさん
09/01/31 21:55:19
汎用的なクラスを求められて、特殊ロジックを埋め込む奴に言われたないわ
370:nobodyさん
09/01/31 21:55:26
じゃあ、一般的なロジックを披露してほしいものだね。
それがビジネスロジックであろうがぜんぜんかまわないから。
371:nobodyさん
09/01/31 21:56:45
断る
教えてほしいなら態度をわきまえんとな。
いまさら、取り返しはつかんが
372:nobodyさん
09/01/31 21:57:07
結局いえないｗ
373:nobodyさん
09/01/31 21:57:30
>>371
ごめんなさい謝りますから教えてください。
374:nobodyさん
09/01/31 22:01:21
> じゃあ、一般的なロジックを披露してほしいものだね。
もう一回説明しとく。
だれでもハッピーな一般的なロジックなんてものはない。
ビジネスロジックそのものだから。
375:nobodyさん
09/01/31 22:01:47
だから、ビジネスロジックでかまわないって書いたろｗ
376:nobodyさん
09/01/31 22:04:24
たとえば、Yahoo!
複数のクッキーとフォームへの埋め込みを利用し、非ログインのユーザーであっても、
その経過を追跡できるように組んである。
ちなみに、PHPのソースではなく、Apache用のモジュールを独自開発して関数一つで使えるようになっている。
377:nobodyさん
09/01/31 22:05:54
これをYAHOOパターンと名づけよう。
378:nobodyさん
09/01/31 22:07:36
このYAHOOパターンは使いまわしできるものか？
それともYAHOOでしか使えないものなのか？
379:nobodyさん
09/01/31 22:07:41
＞PHPのソースではなく、Apache用のモジュールを独自開発して関数一つで使えるようになっている
これがYahooのフレームワークですね
380:nobodyさん
09/01/31 22:08:52
なんだ。結局Yahooのフレームワークに組み込まれているのかよ。
ぜんぜんビジネスロジックじゃないじゃん。
381:nobodyさん
09/01/31 22:09:02
フレームワークとは呼ばん
Yahooでしか使えん
382:nobodyさん
09/01/31 22:09:37
> Yahooでしか使えん
なんで？
383:nobodyさん
09/01/31 22:10:03
ヤフーのユーザー認証インフラとべったりくっついてるから
384:nobodyさん
09/01/31 22:10:05
>>381
>>378
385:nobodyさん
09/01/31 22:11:03
>>383
じゃあ、ユーザー認証インフラごと、ほかで使いまわしできないのか？
386:nobodyさん
09/01/31 22:12:01
その屁理屈が言いたいだけなら、スルーさせてもらう。
387:nobodyさん
09/01/31 22:12:21
屁理屈と感じるのはなぜ？
388:nobodyさん
09/01/31 22:13:33
インフラはPHPじゃない。スレチ
389:nobodyさん
09/01/31 22:14:45
フレームワークかどうかの話にPHPが関係あるのか？
390:nobodyさん
09/01/31 22:15:04
スレタイ
391:nobodyさん
09/01/31 22:15:27
>>376 は、Yahooのシステムの詳細はもしかすると知っていても、抽象化という概念はあんまり
知らないのかもしれない
PHPで再現不可、その為現実的には流用は困難、そういう回答ならわからんでも無いんだが。
真偽はともかくとして
392:nobodyさん
09/01/31 22:16:03
>>390
それこそ屁理屈だな。じゃあ最初っからPHPで実装されていないフレームワークの例を持ってくるなっつーの。
393:nobodyさん
09/01/31 22:16:36
フレームワークの例なんて要求されてないだろ
394:nobodyさん
09/01/31 22:17:41
>>393
ええと、Yahooパターンがビジネスロジックか、
それとも他で使い回しができるものかって話でしたっけ？
395:nobodyさん
09/01/31 22:18:39
373 ：nobodyさん：2009/01/31(土) 21:57:30 ID:???
>>371
ごめんなさい謝りますから教えてください。
374 ：nobodyさん：2009/01/31(土) 22:01:21 ID:???
> じゃあ、一般的なロジックを披露してほしいものだね。
もう一回説明しとく。
だれでもハッピーな一般的なロジックなんてものはない。
ビジネスロジックそのものだから。
396:nobodyさん
09/01/31 22:18:59
だから、ビジネスロジックでいいから説明しろってｗ
397:nobodyさん
09/01/31 22:19:29
各会社で実装が異なるのが当然、その例を示したまで
398:nobodyさん
09/01/31 22:19:58
各会社で・・・ってじゃあ、会社内では使いまわししているってことかよｗ
399:nobodyさん
09/01/31 22:20:08
>>396
>>376
400:nobodyさん
09/01/31 22:20:28
>>395
＞ビジネスロジックそのものだから。
一応言っておくと、その意見も別にここでまだそれほどの同意を得ている訳ではないし、
あんたも論証していない。ただ単に主張しているだけ。
401:nobodyさん
09/01/31 22:21:21
>>399
それは具体的な話じゃない。セッションにクッキーを利用しているとかいう程度の簡単な概略。
402:nobodyさん
09/01/31 22:21:56
やっぱり、こういうレベルの人は煽りのクオリティも(ry
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
> こういう部分をフレームワークは解決してくれているのでしょうか？
> 解決してくれているとしたら、どういった設計になっているのでしょうか？
403:nobodyさん
09/01/31 22:22:50
なぁ。結局会社内では使い回ししている
フレームワークなんだろ？
いい加減認めろよ。
404:nobodyさん
09/01/31 22:24:13
関数ひとつで一連の処理ができるようになっている以上
フレームワーク以外の何者でもないと思うんだがねぇ。
405:nobodyさん
09/01/31 22:24:21
Yahooではそれをフレームワークとは呼んでない。
それでも、おまえさんがフレームワークだと呼びたいなら呼べよ。
406:nobodyさん
09/01/31 22:25:37
フレームワークじゃなくてビジネスロジックとでも呼んでいるのか？
関数一行なのにビジネスロジック？
407:nobodyさん
09/01/31 22:27:01
関数と呼んでいる
関数でビジネスロジックを実現してますが？
408:nobodyさん
09/01/31 22:27:41
で、そういう関数の集まりをライブラリと呼んでいる。
フレームワークとは呼ばない
409:nobodyさん
09/01/31 22:28:08
>>407
だからそれは他のサイト、システムには＊絶対に＊使い回せないのかと聞かれてるんじゃないか。
どんだけループしたいんだｗｗｗ
410:nobodyさん
09/01/31 22:28:24
>>407
Apacheのモジュールとして実装された
関数の中身をビジネスロジックと呼んでいるのか？
411:nobodyさん
09/01/31 22:29:43
>>408
ライブラリって普通使いませるものだよね？
ビジネスロジックとは呼ばないよね？
412:nobodyさん
09/01/31 22:29:54
>>409
「絶対に」ってのが屁理屈だと言っている。
現実的には無理だ。
>>410
関数でビジネスロジックを実装している。
413:nobodyさん
09/01/31 22:31:11
> 関数でビジネスロジックを実装している。
どっちの意味だ？
(Apacheモジュールとして実装された）関数を使ってビジネスロジックを実装しているのか
それとも関数の中身がビジネスロジックなのか。
414:nobodyさん
09/01/31 22:32:03
>>411
ライブラリにビジネスロジックを実装することはある。
415:nobodyさん
09/01/31 22:32:13
チャットすんなよ
ゆとり共
416:nobodyさん
09/01/31 22:32:50
>>414
そんな可能性の話すんなよ。屁理屈じゃねーかｗ
この場合はどうなのかって話だ。
417:nobodyさん
09/01/31 22:33:36
>>416
可能性じゃない。Yahooの場合はそうしているという話
おまえさん、壊れてきたね
418:nobodyさん
09/01/31 22:33:40
>>415
誰が困るってわけでもねーだろｗ
419:nobodyさん
09/01/31 22:34:48
>>417
つまり、Yahooの場合は、会社内で
ビジネスロジックであるライブラリを
使い回ししているということでいいんだよな？
420:nobodyさん
09/01/31 22:35:03
>>415
すまん、ちょっとおもしろかったんで。もうやめるわ。飽きたし。
そこの
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
のひと、
さぁ、勝利宣言どうぞ！
↓↓
421:nobodyさん
09/01/31 22:35:41
断る
422:nobodyさん
09/01/31 22:38:04
使い回しできるってことは、Yahooにとっては
一般的なロジックってことになるんだけどね。
いろいろいっている事が矛盾しだしてるｗ
423:nobodyさん
09/01/31 22:40:33
フレームワークじゃなくてライブラリだというが、
最近のフレームワークにはライブラリ相当のものが含まれているのが普通。
424:nobodyさん
09/01/31 22:42:02
やっと頭がおかしいやつが消えたか？
425:nobodyさん
09/01/31 22:43:38
おれは元の質問者ではないが、改めて。
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
至極単純に実装した場合、これは真だと思うんだが、どうなんでしょう。
また、これを避けるために例えば>>236の様な対策が施され、実装されているのは、（割合的に）
一般的なんでしょうかね。
（そうだとすると、自分の（会社の）作っているシステムがかなり後進的ry）
426:nobodyさん
09/01/31 22:58:58
ライブラリとフレームワークの違いは、「フレームワークとは何か？」って論争になりそうで触れたくねーけどな。
大雑把に言えば、SmartyとかPEARみたいに、特定の機能を提供するのがライブラリで、
アプリケーション全体の構造（MVC構造とか）を提供するのがフレームワーク。
フレームワークには複数のライブラリが含まれる事が多いけどな。
テンプレートライブラリとか、O/RマッパーみたいなDB中間層とか。
二重ログインを提供するだけならば、それは単なるライブラリ。
フレームワークの一部として組み込むと便利そうだ、というだけでな。
427:nobodyさん
09/01/31 23:00:50
>>426
餌をやらないでください
428:nobodyさん
09/01/31 23:05:05
>>426
んなもん、Yahooパターンか、それ以外かを
入れ替え可能な仕組みになっていれば
その程度でフレームワークになる。
そのフレームワークに沿ったつくりの
Yahooパターンクラスはなんになるんだろうな？
フレームワーク？ プラグイン？
429:426
09/02/01 00:54:30
>428
前半は意味が不明なので読み飛ばす。
そいつが存在しないとフレームワークが動かないならば、フレームワークの一部。
存在しなくとも動くならプラグイン。
430:nobodyさん
09/02/01 00:58:57
正確にはフレームワーク標準のプラグイン
431:nobodyさん
09/02/01 00:59:12
継続ベースのPiece Frameworkなら、HTTPとHTTPSのスキーム切替えは簡単なんじゃないでしょうか？
URLﾘﾝｸ(trac.piece-framework.com)
フローIDによって別のフローに接続するビュースキーム
例えば、フローID /foo のフローにクエリ変数bar, bazをともなって接続するには下記のようにする。
flow:///foo.php?bar=baz&baz=qux
SSLで接続したい場合は、下記のようにする。
flows:///foo.php?bar=baz&baz=qux
たったこれだけでSSLにパッと切り替わるんですよね？
432:nobodyさん
09/02/01 01:04:47
URLﾘﾝｸ(trac.piece-framework.com)
Piece_Flowによって、実行中のフローの状態はHTTPリクエストをまたがって保持され、フローの状態遷移の順序は完全にコントロールされます。
このことは状態の保持を前提としてプログラムを書くことを可能にします。
さらに、Piece_Flowは不正リクエストやCSRF攻撃、セッション固定化攻撃から自動的にアプリケーションを保護します。
Piece Frameworkは使うときにやたらと設定ファイルをガシガシ書かなきゃいけないみたいだったので使おうと思ってなかったんですけど、
そういう仕込み作業って、Javaのフレームワークを使っている人にとっては、そんなに苦行じゃないですか？
433:nobodyさん
09/02/01 11:34:03
>>431-432
なんか面白そうだけど、Piece使ったことないや
ドキュメントだけでも読んでみようと思ったが・・・無いじゃないかｗ
聞き慣れない概念や用語をがしがし取り込むのはいいけど、その説明をしないでは
多分理解しにくいしちょっと手が出せない感じ
ソース頑張って読んだらわかってくるのかもしれないけど。
Piece_Flowの最後のstableが去年の夏で、半年間もドキュメント整備しないとか
どうなんだろう。
実際に使ってる人ほとんどいないんじゃなかろうか。
434:nobodyさん
09/02/01 16:33:19
>>433
Piece_Flowは単体でも使えるように設計されているけど、
普通はPiece_Unityを使うから存在を意識することはほとんどないよ。
フロー定義はPiece_IDEを使って作ると楽。
435:nobodyさん
09/02/01 17:11:42
一時期、PHPプロ（アシアル）さんが押してたみたいですが、最近あまり話題を聞かない…
ドキュメントの誤字脱字チェックぐらいなら協力できると思います！！！
ピースの中の人、頑張ってください＾＾
URLﾘﾝｸ(trac.piece-framework.com)
Piece Frameworkドキュメント
URLﾘﾝｸ(gihyo.jp)
連載 Piece Frameworkによるブログアプリケーションの作成
URLﾘﾝｸ(www.amazon.co.jp)
Piece Frameworkで作る対話的なアプリケーション
436:nobodyさん
09/02/01 17:14:39
_,,..r'''""~~`''ｰ-.､
,,.r,:-‐'''"""~~`ヽ､:;:;:＼
r"r ゝ､:;:ヽ
r‐-､ ,...,, |;;;;| ,,.-‐-:､ ヾ;:;ゝ
:i! i! |: : i! ヾ| r'"~~` :;: ::;",,-‐‐- `r'^!
! i!. | ;| l| ''"~~ ､ i' |
i! ヽ | | | ,.:'" ､ヽ､ !,ﾉ イェ～イ
ゝ `-! :| i! .:;: '~~ｰ~~'" ﾞヾ : : ::| ピースの中の人、
r'"~`ヾ、 i! i! ,,-ｪェI二エﾌﾌ : : :::ﾉ~|` 頑張ってください＾＾
,.ゝ､ r'""`ヽ､i! `:､ ー - '" :: : :／ ,/
!､ `ヽ､ー､ ヽ‐''"`ヾ､.....,,,,＿,,,,.-‐'",..-'"
| ＼ i:" ） | ~`'''ー----''"~
ヽ `'" ノ
437:nobodyさん
09/02/01 17:26:04
今連載記事飛ばし読み中
ピースフローは、ZFと組み合わせて使えるらしい。
URLﾘﾝｸ(gihyo.jp)
Piece_Flowは汎用のフレームワークであり，他のフレームワークと容易に統合することが可能です
Zend Frameworkと統合したRevulo_Controller_Dispatcher_Flowがあります。
URLﾘﾝｸ(www.revulo.com)
Piece_Flow を Zend Framework に組み込み、 Piece Framework と同様のステートフルなプログラミングができるようにします。
,.,.,.,.,.,.,.,.,__
,,;f::::::::::::::::::::::ヽ
i::/'￣￣￣ヾi::l
|::| ／ ＼,|::|
|r-（ ・ );（ ・ )-|
( ヽ :::(__)..:: } ＜・・・で、SSLは簡単になるの？
,＿＿__／ヽ -==- /
r'"ヽ t､ ヽ＿＿_/
/ ､､i ヽ＿＿,,/
/ ヽﾉ j , j |ヽ
|⌒`'､__ / / /r |
{ ￣''ｰ-､,,_,ﾍ＾ |
ゝ-,,,＿＿＿＿_）--､j
/ ＼__ /
438:nobodyさん
09/02/01 17:32:07
HTTPとHTTPSのスキーム切替えの対応方法を
>>1のテンプレFWのユーザーの皆様がご紹介ください！！！
トップバッターはシンフォニーでお願いします＞＜
↓↓↓
439:nobodyさん
09/02/01 17:47:35
ピース連載記事、チラ見でYAMLの嵐…
頭が痛くなりそうだけど、IDEを使えばサクサク書けるのでしょうか？>>434
URLﾘﾝｸ(gihyo.jp)
Piece_IDEのフローデザイナーはGUIベースのフロー定義を可能にします。
フローデザイナーを使うと複雑なフローでも混乱することなく開発を進められると思います。
URLﾘﾝｸ(trac.piece-framework.com)
Piece_IDEは、Eclipse上に構築されたPiece Frameworkの統合開発環境です。
440:nobodyさん
09/02/01 17:59:41
Gauche＋Kahuaで、ステートフルなWebアプリ作成を練習してみると、Piece Frameworkの利便性が分かるでしょうか？
URLﾘﾝｸ(www.thinkit.co.jp)
ｽﾚﾘﾝｸ(tech板)
URLﾘﾝｸ(txqz.net)
httpプロトコルはステートレス。
COOKIEとかGETパラメータとかPOSTパラメータとか他のヘッダとかを使って擬似的にステートフルにできている。
ステートレスだけで処理しようとすると問題が起こる。
[入力]→[確認]→[完了]と画面が推移するとき、ユーザが入力した情報をhiddenパラメータなどでクライアントに返してしまうと、確認の前と完了の前とで2回データチェックする必要が出てくる。
HTTPプロトコルがステートレスなのにアプリがステートフルを要求している。
いまさらHTTPプロトコルは変えようがない。
そこのギャップをフレームワークがうまく解決してくれる。
HTTPの仕組みの上でWEBアプリを作るのは、PHPだけの悩みじゃないんですよね～＞＜