- 1 名前：nobodyさん mailto:sage [2008/12/23(火) 00:36:15 ID:???]
- PHPのフレームワークに関する話題用のスレッド
●国外産●
symfony
ttp://www.symfony-project.com/
code igniter
ttp://codeigniter.com/
Zend Framework
ttp://framework.zend.com/manual/ja/index.html
CakePHP
ttp://www.cakephp.org/
Yii Framework ←New!! (Dec 03, 2008)
ttp://www.yiiframework.com/
●国産
ちいたん
ttp://php.cheetan.net/
Ethna
ttp://ethna.jp/
guesswork
ttp://classic.guesswork.jp/
maple
ttp://kunit.jp/maple/
●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
pc11.2ch.net/test/read.cgi/php/1219581817/
- 221 名前：nobodyさん mailto:sage [2009/01/30(金) 11:23:06 ID:???]
- >>207
> あと、毎回セッションIDを変える方法は、
> 別ウインドウを出したとき問題になる。
ただ単に、どっちかのセッションが使えなくなるだけじゃない？
問題なし
- 222 名前：nobodyさん mailto:sage [2009/01/30(金) 11:24:24 ID:???]
- >>219
それで何が不満なの？
なにかセキュリティ上の問題があるなら指摘してください
>>220
よーくわかった。(ry
- 223 名前：nobodyさん mailto:sage [2009/01/30(金) 11:25:39 ID:???]
- >>219
> すでにセキュアトークンを持ってれば別
ってちゃんと書いてるだろ。
- 224 名前：nobodyさん mailto:sage [2009/01/30(金) 11:39:10 ID:???]
- そもそもAmazonはJavaで独自実装だから
PHPフレームワークスレでこんな機能が全て実現できるフレームワークは
PHPにないよね！って言われた所でなんなんだっていう
ちなみにPerlでもJavaでもASPでもそんなフレームワークはない
その辺は自分で実装する
- 225 名前：nobodyさん mailto:sage [2009/01/30(金) 12:33:45 ID:???]
- >>207
>だけどフレームワークの意味をもう一度思い出してほしい。
>
>汎用的で複雑な処理を簡単に実装できることだ。
>重要な操作の前に確認したいのなら、
>プロパティ一つ程度の簡単なコードですむようにしてくれるものだろう？
>
>YAHOOのパスワードの再確認を求められるケースとそうじゃないケースを
>作る為のサポート機能。それこそフレームワークが提供するべきものだろう？
これがフレームワークが提供すべき汎用的な機能かと言うとどうだろうね？
- 226 名前：225 mailto:sage [2009/01/30(金) 12:35:02 ID:???]
- 追記：
「Webアプリケーションフレームワークが」提供すべきかどうか、ね。
- 227 名前：nobodyさん mailto:sage [2009/01/30(金) 12:46:45 ID:???]
- 重大なセキュリティに絡む部分をオープンなフレームワークで吸収したら
そこにバグがあったらそれ使ってるシステムみんな死亡じゃん
クリティカルな部分は独自に実装するからバグがあってもなんとななるわけで
- 228 名前：nobodyさん mailto:sage [2009/01/30(金) 13:17:58 ID:???]
- >>227
んなこといったら、プレースホルダ使いたい、使わせたい為だけにPEAR::DB使ってた人間とか涙目だろ。
実際そういった判断は、凡PGに任せるより遙かにセキュアだったと思うがな
フレームワーク（というか基底ライブラリ）の有用性の一面を完全否定っすか。
- 229 名前：nobodyさん mailto:sage [2009/01/30(金) 13:34:34 ID:???]
- >>227
問題はバグがどうたらじゃないよ
設計や計画にはちゃんとした理解が必要だが、コーディングが難しかったり
面倒だったりするわけじゃないからFWに任せる内容じゃないってことだよ。
コーディングの助けっていう意味程度なら、どのFWにもセキュアセッション
を扱う機能や、ワンタイムトークンを自動でハンドリングするフォーム要素とか
一通りのものは揃ってる。
が、ページ遷移設計まで自動化してほしいとは思わないけどな。
PieceFrameworkあたりなら、その辺はすでに実装済みかもしれんけど。
- 230 名前：nobodyさん mailto:sage [2009/01/30(金) 13:36:33 ID:???]
- CakePHPは実際AuthComponentで誰でもログインできるってバグ出して死亡したけどなｗ
ああいうのはFWで吸収しない方がいい
- 231 名前：nobodyさん mailto:sage [2009/01/30(金) 13:38:02 ID:???]
- >>229
きちんと実装されるかどうかじゃなくて、フレームワークの場合は
そういうバグがありましたって公開されちゃうから、フレームワーク使ってるのバレると
悪用されるってことじゃないの？
独自実装ならクソみたいな実装でも中はどうなってるかアタックするまで解らんのだし
- 232 名前：nobodyさん mailto:sage [2009/01/30(金) 13:43:38 ID:???]
- >>230
言ってみれば各フレームワークも、それぞれの独自実装の固まりだからな
ある程度のライブラリくらい共用して欲しいような気もする今日この頃。
APIも統一されるし。
- 233 名前：nobodyさん mailto:sage [2009/01/30(金) 13:53:53 ID:???]
- cookieのsecure属性を理解してないヤツが混じってる予感。
- 234 名前：nobodyさん mailto:sage [2009/01/30(金) 13:57:42 ID:???]
- >>230
それは、バグがあるのがわるいだけだろｗ
- 235 名前：nobodyさん mailto:sage [2009/01/30(金) 14:24:52 ID:???]
- ごっつい根本的な質問で恐縮ですが
PHPって複数のセッションを同時に利用することってできるの？
それができるかできないかで、ものすごく話が変わってくるような。
・・・できないんだろうな。$_SESSION だもんな・・・
- 236 名前：nobodyさん mailto:sage [2009/01/30(金) 14:32:51 ID:???]
- >>235
微妙にスレチだぞ＞くだすれ行けって感じだが・・・
無理やりFWレイヤーの話に持ってくると、Zend_Sessionではセッションの配列で
ネームスペース的な扱いをして、使い分けている。
でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
分割して持てるか？って話をしたいわけだよな？
PHPが受け入れるセッションID自体は一つ。それは正しい。
解は二つ。
クッキーと独自のバックエンドを使って、自前でセッション機構を作る。
セッションを理解してれば、簡単。
ちなみにYahoo!はPHPでこの方式を採用してる。
もう一つは、セッションそのものは永続化しておいて、セッションネームスペース内
に侵入を許す際に、そのネームスペースに対する適切なアクセスかどうかを個別のクッキーで検証する。
ZFで実装してるやつはたぶんこれがFA
- 237 名前：nobodyさん mailto:sage [2009/01/30(金) 14:42:03 ID:???]
- >>234
いや
これがCakePHPだから、セキュリティ情報として全世界にこういうバグありますよって公開されちゃうわけよ。
その情報を見てクラッカーが仕掛けてくる可能性が高い。
もし仮に自分で全て実装したものに同じバグがあったとしても、よっぽどしっかりクラックされない限り、誰にも知られることはない。
- 238 名前：nobodyさん mailto:sage [2009/01/30(金) 14:47:27 ID:???]
- >>236
> でも、そういう意味じゃなくて、上の流れで、セキュアセッションと平文セッションを
> 分割して持てるか？って話をしたいわけだよな？
ですです。それができれば、盗聴（非SSL）でセッションハイジャックされたとしても
その中には非セキュア用の情報しかないし、セキュア用のセッション（ログイン状態）等と
簡単に切り分けできるなーと。
ただ、他の言語の実装をみても、「セッション」ってもの自体の考え方が、どうやらサーバ-
クライアントで1対1っぽい？
＞解は二つ。
もう一つ、セッションはあくまでsecureで利用して、非セキュアな情報はみんなCookieに
放り込めばいいじゃない！ってふと思いついた。
最低4KB×20(50？)個なら、とりあえず普通に使えそうとか。
- 239 名前：nobodyさん mailto:sage [2009/01/30(金) 14:54:52 ID:???]
- Cookie切ってる奴多いのに通用するのかそれ
セキュリティソフトのせいで動きませんみたいなサイトになるぞ
- 240 名前：nobodyさん mailto:sage [2009/01/30(金) 15:02:01 ID:???]
- Cookie切ってる奴多い？
根拠は？
- 241 名前：nobodyさん mailto:sage [2009/01/30(金) 15:09:40 ID:???]
- >>239
もしかしてセッションIDをフォームに手で埋めるのが標準？
まじでか
- 242 名前：nobodyさん mailto:sage [2009/01/30(金) 15:14:39 ID:???]
- >>239
Cookie切ったら普通にセッション動かないけど？
- 243 名前：nobodyさん mailto:sage [2009/01/30(金) 15:15:10 ID:???]
- みなさ〜ん、そろそろスレチですよっと。
- 244 名前：nobodyさん mailto:sage [2009/01/30(金) 15:18:00 ID:???]
- ほかの言語の話になってるよりましだし、いいんじゃないの？
- 245 名前：nobodyさん mailto:sage [2009/01/30(金) 15:32:12 ID:???]
- SSLの話題が出ているので便乗質問。
共有SSLに対応しているフレームワークってある？
www.aaa.com/
https://www.rental-server.com/~aaa.com/
こうなっているときに、ドメイン名違うし、パス違うしで
セッション保てないわで、困るんだよね。
- 246 名前：nobodyさん mailto:sage [2009/01/30(金) 15:33:30 ID:???]
- クッキー切ってるような変人相手にする必要なし
むしろブラクラに飛ばしてやれ
- 247 名前：nobodyさん mailto:sage [2009/01/30(金) 15:34:14 ID:???]
- Cookie切ってセッション動かないとかどんなクソ実装だよ
それじゃ携帯サイト対応できねーじゃん
- 248 名前：nobodyさん mailto:sage [2009/01/30(金) 15:39:41 ID:???]
- うーん。セキュリティ周りをちゃんと説明しているサイトが見つからない。
クッキー切っている場合（携帯対応）のセッションで
cookieにsecure属性をつけた場合の動作と同じことを
ちゃんとやっているのか確証を得たいが見つからない。
- 249 名前：nobodyさん mailto:sage [2009/01/30(金) 15:48:16 ID:???]
- Cookieが普通で携帯が異常なだけだろ。
- 250 名前：nobodyさん mailto:sage [2009/01/30(金) 15:54:21 ID:???]
- DoCoMoの携帯がクッキー非対応で異常だからってことで、
非対応にしてるサイトってあんまないけどな。
結局Cookie使わなくてもセッションは維持できる。
- 251 名前：nobodyさん mailto:sage [2009/01/30(金) 16:09:01 ID:???]
- >>247
携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。
PerlならMobaSifがあるけどなぁ。
- 252 名前：nobodyさん mailto:sage [2009/01/30(金) 16:17:17 ID:???]
- >>245
>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう
クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか
- 253 名前：nobodyさん mailto:sage [2009/01/30(金) 16:23:31 ID:???]
- URLにセッションID差し込んでCookie使わない実装にするのなんて普通だろ
IDはアクセス毎に変える
- 254 名前：nobodyさん mailto:sage [2009/01/30(金) 16:30:00 ID:???]
- >>253
これを言い出すと、もうセッションIDのクッキーをsecureにする意味もないな
- 255 名前：nobodyさん mailto:sage [2009/01/30(金) 16:40:23 ID:???]
- >>253
PHPの$_SESSION自体そういう仕様になってなかったか？
- 256 名前：nobodyさん mailto:sage [2009/01/30(金) 17:04:49 ID:???]
- use_trans_sid
- 257 名前：nobodyさん mailto:sage [2009/01/30(金) 17:05:43 ID:???]
- まぁ、URLに差し込むだけじゃ携帯全機種対応は無理だけどな。
- 258 名前：nobodyさん mailto:sage [2009/01/30(金) 18:19:42 ID:???]
- っていうか議論に問題だらけの端末の話を持ってくるのは暴論じゃないか？
携帯サイト対応ってそれだけで一仕事だよ。
- 259 名前：nobodyさん mailto:sage [2009/01/31(土) 01:06:04 ID:???]
- SSL対応議論、参考になります！(ｷﾘｯ)
この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな〜＞＜
- 260 名前：nobodyさん mailto:sage [2009/01/31(土) 02:01:11 ID:???]
- 誰も十分に理解できていないから、
はっきりとした答えが出せないんだろうな。
- 261 名前：nobodyさん mailto:sage [2009/01/31(土) 02:27:29 ID:???]
- 土日を利用して勉強してみましょう
継続を使ったWEBアプリ
www.thinkit.co.jp/article/74/1/
Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
www.kahua.org/
セッションも良いけど継続もね☆
- 262 名前：nobodyさん mailto:sage [2009/01/31(土) 04:23:52 ID:???]
- クッキーはサイズの制限があるから結局セッションを使うとして、
そのセッションをどうやって実現しているかだ。
セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）
問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。
もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。
そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。
- 263 名前：nobodyさん mailto:sage [2009/01/31(土) 07:40:31 ID:???]
- >>262
おまいさんの理解が浅いということだけはわかった。
何も書かないと単なる煽りと思われるので一つだけ例示すると、
> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。
それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。
情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。
- 264 名前：nobodyさん mailto:sage [2009/01/31(土) 11:43:58 ID:???]
- >セキュアな情報を表示するためのトークン
それって一般にはセッションIDって呼ぶと思うの。
- 265 名前：nobodyさん mailto:sage [2009/01/31(土) 11:53:41 ID:???]
- いいえ
- 266 名前：nobodyさん mailto:sage [2009/01/31(土) 12:16:29 ID:???]
- おせっかいなオレが例を出したるわ。
・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす
すくなくとも$uniqをセッションIDとは言わない。
- 267 名前：nobodyさん mailto:sage [2009/01/31(土) 12:29:26 ID:???]
- >>266
で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。
おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。
- 268 名前：nobodyさん mailto:sage [2009/01/31(土) 12:48:08 ID:???]
- なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
- 269 名前：nobodyさん mailto:sage [2009/01/31(土) 12:55:21 ID:???]
- そんなに欲しかったら開発リクエストすればいいんじゃない？
投票が集まればサクッと作るでしょ。
- 270 名前：nobodyさん mailto:sage [2009/01/31(土) 13:09:29 ID:???]
- >>268
>>266の処理を一行で書かれたら絶対に読みたくない。
- 271 名前：nobodyさん mailto:sage [2009/01/31(土) 13:31:24 ID:???]
- >>268が冗長なだけ
- 272 名前：nobodyさん mailto:sage [2009/01/31(土) 13:32:03 ID:???]
- >>268じゃなくて、>>266
- 273 名前：nobodyさん mailto:sage [2009/01/31(土) 15:14:35 ID:???]
- >>262-272
マジで参考になります＾＾（もっとやれ的な意味で）
- 274 名前：nobodyさん mailto:sage [2009/01/31(土) 15:30:40 ID:???]
- フレームワークを勘違いしたひとが沸いて荒らしてくれたおかげでスレの進みが半端ネェ！
たまにこういうことがあるから面白い
- 275 名前：nobodyさん mailto:sage [2009/01/31(土) 15:51:36 ID:???]
- >>274
フレームワークの話題も振れずかといって実装についての話もできないのに
レスするのって寂しくならないか？
- 276 名前：nobodyさん mailto:sage [2009/01/31(土) 15:51:43 ID:???]
- >>266
そこら辺の処理をちゃんと説明している本って無い？
- 277 名前：nobodyさん mailto:sage [2009/01/31(土) 15:55:18 ID:???]
- >>268
> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問
それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。
ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。
- 278 名前：nobodyさん mailto:sage [2009/01/31(土) 16:03:23 ID:???]
- 汎用的ではない。
インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。
- 279 名前：nobodyさん mailto:sage [2009/01/31(土) 16:04:02 ID:???]
- >>277
それはフレームワークのよいところを語りたかったわけ？
- 280 名前：nobodyさん mailto:sage [2009/01/31(土) 16:10:55 ID:???]
- >>277
それが汎用的な処理だっていうんなら、汎用的なクラスを書いてここに貼ってくれ
みんな喜ぶ。
- 281 名前：nobodyさん mailto:sage [2009/01/31(土) 16:45:58 ID:???]
- >>280
ヒントやるから実装は自分でやれな。
SSL_Login_Class
セキュアにするべきページの一覧や正規表現を設定配列に入れておく。
全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
セキュアページにhttpでアクセスしていたら、httpsにリダイレクト
セキュアトークンを持っていなければ、ログインページにリダイレクト
ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）
セキュアトークンのサーバー側のデータは、セッションでも独自のファイルやデータベースにも格納可能。
ハッシュはsha1でもそれ以外でも選択可能。
以上のことをやってくれるクラス。
使い方は簡単。CakePHP風に言えば共通のコントローラAppControllerの
componentsに上記のクラスを入れるだけ。これとセキュアページのリストさえあれば
具体的な実装を書かなくてすむ。
- 282 名前：nobodyさん mailto:sage [2009/01/31(土) 16:52:07 ID:???]
- それのどこが汎用的なんだよ。個別実装べったりじゃん。
日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
- 283 名前：nobodyさん mailto:sage [2009/01/31(土) 17:04:17 ID:???]
- >>282
お前にとって汎用的とはどういうことを指す言葉なんだ？
例を出して説明したまえ。
- 284 名前：nobodyさん mailto:sage [2009/01/31(土) 17:13:02 ID:???]
- セキュアにするためのロジックだよ。
>>266に書いてあるのは、セキュアなサイトを作る時のHelloWorld
実サイトでは、Yahooにしろamazonでも楽天でも>>266とは別のロジック。
そういうロジックを設定でインジェクションできないなら汎用的とは言わない。
- 285 名前：nobodyさん mailto:sage [2009/01/31(土) 17:15:21 ID:???]
- >>284
>>281のはロジックの一つだよ。
別のロジックを使いたければ、別のロジックを実装したクラスを
AppControllerのcomponentsに設定すればいいだけ。
これで汎用的になりましたね（笑）
- 286 名前：nobodyさん mailto:sage [2009/01/31(土) 17:18:05 ID:???]
- あほか、だったら、FWが持ってる認証クラスで十分やんけ
- 287 名前：nobodyさん mailto:sage [2009/01/31(土) 17:20:51 ID:???]
- んだ。
- 288 名前：nobodyさん mailto:sage [2009/01/31(土) 17:22:06 ID:???]
- >>286
本当に十分なのか？ FWが持っている認証クラスが
このようなロジックになっているのか？
>>266のロジックなのか？ それともYahoo、Amazon、楽天のロジックのなのか？
それが、そもそもの>>185,188の質問だろうが。
> フレームワークのSSL対応ってどうなっているのでしょうか？
それで答えは？
- 289 名前：nobodyさん mailto:sage [2009/01/31(土) 17:24:30 ID:???]
- >>288
結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
ロジックを実装したクラスを設定するわけだろ。
それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
>> フレームワークのSSL対応ってどうなっているのでしょうか？
> それで答えは？
対応する必要なし。
- 290 名前：nobodyさん mailto:sage [2009/01/31(土) 17:26:44 ID:???]
- >>289
> それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。
そのロジックをお前は毎回作るのか？
そのロジックは使いまわし出来るだろ？
それを汎用的という。
- 291 名前：nobodyさん mailto:sage [2009/01/31(土) 17:27:35 ID:???]
- >>285
> >>281のはロジックの一つだよ。
うは、コンクリートじゃんおもいっきり
- 292 名前：nobodyさん mailto:sage [2009/01/31(土) 17:28:05 ID:???]
- > 結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
考え方がおかしいね。 >>281のクラスを使ってサービスを実装するんじゃない。
なにかのサービスを実装したとき、>>281のクラスを利用する。
考え方が逆だよ。
- 293 名前：nobodyさん mailto:sage [2009/01/31(土) 17:28:45 ID:???]
- >>291
コンクリートだねぇ。だからなに？
- 294 名前：nobodyさん mailto:sage [2009/01/31(土) 17:29:28 ID:???]
- >>290
元はといえば、お前さんの書いたクラスのサンプルが汎用的じゃないわけだろ。
ロジックはサイトの管理ポリシーによって違うでしょ。
それをカバーできるようは汎用的な設計を示してから言ってくれ。
- 295 名前：nobodyさん mailto:sage [2009/01/31(土) 17:30:02 ID:???]
- >>293
汎用的じゃないって、告白ありがとう
- 296 名前：nobodyさん mailto:sage [2009/01/31(土) 17:31:17 ID:???]
- >>292
>>281のクラスじゃ実装できないサービスがてんこ盛りなんですが
- 297 名前：nobodyさん mailto:sage [2009/01/31(土) 17:32:13 ID:???]
- >>294
お前はロジックという言葉の使い方がおかしい。
管理ポリシーは違っても、それを実装するロジック（数パターンある）は同じ。
ロジックと管理ポリシーは違うもの。
- 298 名前：nobodyさん mailto:sage [2009/01/31(土) 17:35:29 ID:???]
- >>297
まぁ、そういうことだろうな。
数パターンしか思いつかないレベルならいいや。おまえさんすごいよ。
- 299 名前：nobodyさん mailto:sage [2009/01/31(土) 17:38:04 ID:???]
- >>295
あのなぁ。お前、コンクリートと汎用的とは別の考え方だよ。
GUIの例で言えば分かるだろ。
テキストボックスはコンクリートクラスであるが、
汎用的に使われるパーツだ。
抽象クラスと汎用的つ使えるクラスをごっちゃにするなよ。
- 300 名前：nobodyさん mailto:sage [2009/01/31(土) 17:40:29 ID:???]
- >>299
君の汎用的ってのは、１つのロジックを複数のサイトで使えるってことね。了解
- 301 名前：nobodyさん mailto:sage [2009/01/31(土) 17:42:09 ID:???]
- ちょっと、みなさん、クールダウンしません？発散しすぎ
- 302 名前：nobodyさん mailto:sage [2009/01/31(土) 17:42:45 ID:???]
- >>300
いや常識（笑）
汎用的なパーツは、一つのパーツを複数のサイトで使える物。
それ以外の意味なんて無いだろｗ
まさか今まで抽象クラスの話をしていたのか。驚きだｗ
- 303 名前：nobodyさん mailto:sage [2009/01/31(土) 17:48:13 ID:???]
- やっぱおかしいと思ったんだよ。なんかずれてるって。
この質問をしたのは正しかった。 ↓
> 282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???
> それのどこが汎用的なんだよ。個別実装べったりじゃん。
> 日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
>
> 283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???
> >>282
> お前にとって汎用的とはどういうことを指す言葉なんだ？
>
> 例を出して説明したまえ。
この質問の時点で抽象クラスのことって言ってくれれば話は早かったんだが。
ちゃんと質問に答えてくれていれば
この時点で、君の汎用的ってのは抽象クラスのことね（笑）で終わっていた。
- 304 名前：nobodyさん mailto:sage [2009/01/31(土) 17:53:26 ID:???]
- クールダウンして>>185,188の質問に戻ろうか？ｗ
> フレームワークのSSL対応ってどうなっているのでしょうか？
- 305 名前：nobodyさん mailto:sage [2009/01/31(土) 17:53:36 ID:???]
- >>302
>>303 熱いねぇ
>>280は汎用的なクラスと書いてるなぁ。
>>281は個別実装でも別サイトで利用できたら汎用的なんだってさ。
汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
少なくともコンクリートのことじゃないと思うが、まぁ個人的な見解だからいいや。
それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
> こういう部分をフレームワークは解決してくれているのでしょうか？
> 解決してくれているとしたら、どういった設計になっているのでしょうか？
さすが、こういうレベルの人の頭の中は面白い。
- 306 名前：nobodyさん mailto:sage [2009/01/31(土) 17:55:15 ID:???]
- >>303
>>284でFAだが？
- 307 名前：nobodyさん mailto:sage [2009/01/31(土) 17:55:39 ID:???]
- > 汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
> 少なくともコンクリートのことじゃないと思うが
それは無いｗ
- 308 名前：nobodyさん mailto:sage [2009/01/31(土) 17:57:54 ID:???]
- >>305
> それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。
別に、分かりやすく言い換えただけで
汎用的なクラスという言い方でもいいが？
- 309 名前：nobodyさん mailto:sage [2009/01/31(土) 17:59:46 ID:???]
- 以 下 、「 汎 用 的 」 禁 止。
こんないい加減な言葉で喧嘩するなｗ みっともない。
- 310 名前：nobodyさん mailto:sage [2009/01/31(土) 18:02:05 ID:???]
- クールダウンして>>185,188の質問に戻ろうか？ｗ
> フレームワークのSSL対応ってどうなっているのでしょうか？
- 311 名前：nobodyさん mailto:sage [2009/01/31(土) 18:06:32 ID:???]
- >>302
> いや常識（笑）
> 汎用的なクラスは、一つのクラスを複数のサイトで使える物。
> それ以外の意味なんて無いだろｗ
先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？
- 312 名前：nobodyさん mailto:sage [2009/01/31(土) 18:07:49 ID:???]
- > 先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？
複数のサイトで使えないクラス。
それがビジネスロジックを記述したクラス
- 313 名前：nobodyさん mailto:sage [2009/01/31(土) 18:39:23 ID:???]
- じゃ、>>281のロジックはどこのサイトでも使いようがないので、
>>302の定義でも汎用的ではないってことで落ち着きそうですね
- 314 名前：nobodyさん mailto:sage [2009/01/31(土) 19:12:22 ID:???]
- 基幹業務系の処理なんて再利用できるほうが珍しいｗ
- 315 名前：nobodyさん mailto:sage [2009/01/31(土) 20:17:12 ID:???]
- >>313
そうか？
手法に致命的な欠陥がない限り多分そのまま普通に使えるし、使ったなりのシステムになると思うんだが。
ただ単に、>>313(とか>>282？)がそのやり方を使いたくないだけではないかとちょっと思った。
- 316 名前：nobodyさん mailto:sage [2009/01/31(土) 20:31:55 ID:???]
- え、欠陥見えない？
- 317 名前：nobodyさん mailto:sage [2009/01/31(土) 20:46:34 ID:???]
- >>316
リダイレクトがちょっと引っかかるがそこは適当な処理に読み替えるとして、
致命的な欠陥があるなら指摘してみたらいいじゃない。正直煽りうざい
- 318 名前：nobodyさん mailto:sage [2009/01/31(土) 21:02:59 ID:???]
- 致命的とは思わん、が、ショップじゃ使えないな。売り上げが落ちる。
煽り？どこが。
- 319 名前：nobodyさん mailto:sage [2009/01/31(土) 21:03:44 ID:???]
- だから、使えないというのなら、その理由を指摘してみたらいいじゃない。
- 320 名前：nobodyさん mailto:sage [2009/01/31(土) 21:05:32 ID:???]
- 売上が落ちるから、でわからんの？
- 321 名前：nobodyさん mailto:sage [2009/01/31(土) 21:06:31 ID:???]
- 2段階ログインはありがちな処理だし、使いまわせないとは思わないな。
まあ、好みの問題はあるだろうが。
俺なら設定依存じゃなくてコントローラから明示的に呼び出す方式にするかな。
フレームワークにもよるだろうし、どっちの方法も一長一短だけど。
|
 |
