【PHP】フレームワークについて語るスレ12【総合】

【PHP】フレームワー� ..

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だけの悩みじゃないんですよね～＞＜

441:nobodyさん
09/02/01 18:01:34
URLﾘﾝｸ(gihyo.jp)
現時点でステートフルな特性を持つフレームワークは少数派です。
それでも，筆者はステートフルな特性がWebアプリケーション開発において重要な価値があると考えています。
そして，Piece Frameworkはまだまだ進化の過程にあります。
アプリケーション開発の中心をより本質的な部分にシフトさせるべく，Piece Frameworkの開発は続きます。
Piece Frameworkの今後の発展にご期待ください。

ここまで読んで頂いた皆様に感謝いたします。
ありがとうございました。

442:nobodyさん
09/02/01 18:03:26
土日の勉強タイム終わり
ピース試す時間なかったorz

443:nobodyさん
09/02/01 18:10:30
オツカレ。
あとはブログにでも書いてくれ

444:nobodyさん
09/02/02 00:32:10
そうだよな
ステートレスなHTTPプロトコルを、フレームワークがステートフルにしてくれれば誰がWEBアプリを作ってもセキュアになる

445:nobodyさん
09/02/02 01:58:28
しかし自演し放題のスレだとくだらない煽り合い始まると
一部の馬鹿がオナニー覚えた猿みたいに自演連投し出して始末に終えないなｗ

446:nobodyさん
09/02/02 02:10:06
>>445
自覚しろよ。

447:nobodyさん
09/02/02 03:52:14
それセッション変数で（ｒｙ

ステートフルに作らないといけない処理は、webサービスのごく一部だしなぁ。
そのためにフレームワークいっこ覚える気にはならん。
大体そういう場所ってセキュリティ的にも大事な場所だから、曖昧な理解で他所のコード使うわけにもいかんし。

448:nobodyさん
09/02/02 07:12:40
>>>444
ステートフルになったら、誰が作ってもセキュアになるってセンス、ありえねぇ

449:nobodyさん
09/02/02 10:36:18
誰が作ってもセキュア…これはデジタル土方の間で流行る予感（・∀・）
フレームワークで無理ならもっと下のレイヤーで改善したら確実ですよね？
＝HTTP/HTTPSに代わる新しいセキュアなプロトコルを作ればいいんじゃないか？
でも、面倒くさし金にならんから誰もやらんか…俺はやる気以前の問題として知識がないから無理ｗ

450:nobodyさん
09/02/02 10:44:14
IDSに依存する開発者とか、バカすぎるだろ。あれと一緒。

451:nobodyさん
09/02/02 10:46:29
PCの場合、ユーザーを特定する方法って複雑そうですね＾＾
携帯電話は、端末IDを使えばユーザーの特定が安全＆楽でしょうか？

452:nobodyさん
09/02/02 11:01:12
>>451
携帯の端末IDって設定で許可していないと取れなかったような気がするが、
今はどうなってるの？

453:nobodyさん
09/02/02 13:51:06 xbZu7ZNv
ところで、ステートフルとスレートレスの違いって何？
PieceFrameworkの利点って何？教えてえらい人。

>>452
機種によって違うけど、アクセスするたびに許可を求めてくる物がほとんどだと思う。

454:nobodyさん
09/02/02 14:27:46
>>453

> ステートフルとスレートレスの違いって何？
ｽﾚﾘﾝｸ(php板)

> PieceFrameworkの利点って何？
URLﾘﾝｸ(piece-framework.com)

自分でもう少し掘り下げてから質問したらどうよ

455:nobodyさん
09/02/02 15:00:08
URLﾘﾝｸ(www.ruby-lang.org)

Ruby1.9安定版が出ていよいよPHP脂肪カウントダウン開始ｗｗｗ

456:nobodyさん
09/02/02 15:04:12
>>453
クッキーやIPアドレスに比べ、より直接的に個人特定・追跡できそうな情報なんだが、
前提にしているサイトって多いのかな？あんまり騒ぎにならないな
これって、その機体の契約の間ずっと不変なんでしょ？

457:nobodyさん
09/02/02 15:08:42
騒ぎになってるよ

458:nobodyさん
09/02/02 15:48:00
>>455
奇数バージョンは実験的なバージョンだよ
Linuxのカーネルと同じ

459:nobodyさん
09/02/02 16:08:03
待て、Rubyはどうかしらんが、Linuxカーネルに
今は偶数か奇数かで安定版と開発版の区別はないぞ。

Rubyも偶数奇数でわかれてたっけ?
そのへんは、おおらかにやってそうなふいんきだけど...

460:nobodyさん
09/02/02 17:14:57
URLﾘﾝｸ(blade.nagaokaut.ac.jp)

461:nobodyさん
09/02/02 17:22:35
なぜ本家リファレンスマニュアルを参照しない。

URLﾘﾝｸ(www.ruby-lang.org)

> Ruby のバージョンは、 major.minor.teeny という形式です
>
> version 1.8 までは、minor が奇数のバージョンは開発版、 minor
> が偶数のバージョンは安定版です。1.9.0 以降は、 teeny が 0
> のバージョンが開発版となる予定です。

なので1.9.1は安定版でよかろう。つかwww.ruby-lang.orgにそう書いてある。
しかし、それが本当に安定しているかどうかは別の問題だが。

462:nobodyさん
09/02/02 17:31:17
Rubyは文法が涙目だから駄目だろ
elsifだけは勘弁してくれよ

463:nobodyさん
09/02/02 18:12:53
>>462
じゃぁPerlと（略）とTT.pmの組み合わせにしなさい。

464:nobodyさん
09/02/02 18:24:05
>>462
そのキーワードの何がそんなに気に入らないのかわからん。
PHPのarray_**は気に入らんが、それだけで文法が駄目とか思わんし。

465:nobodyさん
09/02/02 18:28:15
elsifとかelifとか慣れの問題だろ。柔軟に適応できないやつはマに向いてないぞ。
あれこれ難癖つけて1つの言語にこだわって結局自滅するんだ。

466:nobodyさん
09/02/02 19:08:34
禿堂

467:nobodyさん
09/02/02 19:14:01
インターネットって危険がイッパイなんですね！＞＜
大事な用件は直接会って話そう！

468:nobodyさん
09/02/02 19:58:48
}
else
if () {
}

って書けなくて気持ち悪いからだろ
CやJava書いてる奴はそういう奴多い

次ページ