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

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

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）

次ページ