ちょっと、みなさん、クールダウンしません？発散しすぎ

>>300
いや常識（笑）

汎用的なパーツは、一つのパーツを複数のサイトで使える物。

それ以外の意味なんて無いだろｗ


まさか今まで抽象クラスの話をしていたのか。驚きだｗ

やっぱおかしいと思ったんだよ。なんかずれてるって。

この質問をしたのは正しかった。　↓

> 282 ：nobodyさん：2009/01/31(土) 16:52:07 ID:???
> それのどこが汎用的なんだよ。個別実装べったりじゃん。
> 日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。
>
> 283 ：nobodyさん：2009/01/31(土) 17:04:17 ID:???
> >>282
> お前にとって汎用的とはどういうことを指す言葉なんだ？
>
> 例を出して説明したまえ。

この質問の時点で抽象クラスのことって言ってくれれば話は早かったんだが。

ちゃんと質問に答えてくれていれば
この時点で、君の汎用的ってのは抽象クラスのことね（笑）で終わっていた。

クールダウンして>>185,188の質問に戻ろうか？ｗ

> フレームワークのSSL対応ってどうなっているのでしょうか？

>>302
>>303 熱いねぇ

>>280は汎用的なクラスと書いてるなぁ。
>>281は個別実装でも別サイトで利用できたら汎用的なんだってさ。
汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
少なくともコンクリートのことじゃないと思うが、まぁ個人的な見解だからいいや。

それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。

> SSLページと非SSLページでセッションIDを共通にしたらセッションハイジャックされますよね。
> こういう部分をフレームワークは解決してくれているのでしょうか？
> 解決してくれているとしたら、どういった設計になっているのでしょうか？

さすが、こういうレベルの人の頭の中は面白い。

>>303

>>284でFAだが？

> 汎用的なクラスといったら、抽象クラスに限定するわけじゃないが、
> 少なくともコンクリートのことじゃないと思うが

それは無いｗ

>>305
> それにしても、>>302は汎用的な"パーツ"って言い換えて苦しそうだねぇ。

別に、分かりやすく言い換えただけで
汎用的なクラスという言い方でもいいが？

以　下　、「　汎　用　的　」　禁　止。

こんないい加減な言葉で喧嘩するなｗ みっともない。

クールダウンして>>185,188の質問に戻ろうか？ｗ

> フレームワークのSSL対応ってどうなっているのでしょうか？

>>302
> いや常識（笑）
> 汎用的なクラスは、一つのクラスを複数のサイトで使える物。
> それ以外の意味なんて無いだろｗ

先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？

> 先生！複数のサイトで使えないクラスの方がめずらしいと思うんですが？

複数のサイトで使えないクラス。
それがビジネスロジックを記述したクラス

じゃ、>>281のロジックはどこのサイトでも使いようがないので、
>>302の定義でも汎用的ではないってことで落ち着きそうですね

基幹業務系の処理なんて再利用できるほうが珍しいｗ

>>313
そうか？
手法に致命的な欠陥がない限り多分そのまま普通に使えるし、使ったなりのシステムになると思うんだが。
ただ単に、>>313(とか>>282？)がそのやり方を使いたくないだけではないかとちょっと思った。

え、欠陥見えない？

>>316
リダイレクトがちょっと引っかかるがそこは適当な処理に読み替えるとして、
致命的な欠陥があるなら指摘してみたらいいじゃない。正直煽りうざい

致命的とは思わん、が、ショップじゃ使えないな。売り上げが落ちる。
煽り？どこが。

だから、使えないというのなら、その理由を指摘してみたらいいじゃない。

売上が落ちるから、でわからんの？

2段階ログインはありがちな処理だし、使いまわせないとは思わないな。
まあ、好みの問題はあるだろうが。
俺なら設定依存じゃなくてコントローラから明示的に呼び出す方式にするかな。
フレームワークにもよるだろうし、どっちの方法も一長一短だけど。

分かるわけ無いだろｗ
どういう理由で売り上げが落ちるんだよｗ

>>318
最初からそう書けば誰も煽りとは思わんよ
ああ、なんか違う話をしてる人がいるなーって思うだけでｗ

インフラと絡むが、セッション固定攻撃は可能だし

>>323
自演？

2段階もなにも、ログインを強要してる段階で売上減だな

>>324
じゃあ改良してセッション固定攻撃を防ぐようなコードにすれば
問題ないって話？

>>326
えっ？ それだけの話？
それならログインを強要するかしないかの
オプションをつければ解決する話じゃない。

>>327
自分のサイトは防ぐようにしてますが何か？
今は、>>281のクラス？の問題だろ

>>328
ログインを強要しないで、>>281はセキュアにできるのかね？

ログインしなくてもセキュアに処理できなきゃ、この手のスクリプトは無意味だよな。

上のほうでは、一行でできるからフレームワークに入れるほどでもないと
いっているやつがいるかと思えば、話がすすんでみれば
結局、いろんなことを考えないといけないってことになってしまったな。

だからフレームワークに入れておいて簡単に使えるようにするべきだというのに。

ワラタ。
「汎用的なカレー調理器具を考案しました」って言ってる奴に
「それじゃボルシチには使えないから汎用的じゃねえよ」
「うちは蕎麦屋だから関係ねえよ」って言ってるようなもんだな。

>>281 がまあミスリーディングというか

> 全てのコントローラのアクション実行前に、セキュアにするべきか一覧に入っているか調べる。
> セキュアページにhttpでアクセスしていたら、httpsにリダイレクト

ここと、

> セキュアトークンを持っていなければ、ログインページにリダイレクト
> ログインが許可されればセキュアトークンをセット（secure属性を負荷したクッキーを発行）し元のページに戻す。
> ログインページはデフォで用意するがカスタマイズ可能。要するにscaffold（土台）

これは別の処理
で、どちらも実は元の流れの、セキュアセッションと非セキュアセッションの持ち方について、
直接は関係ないじゃないかｗ
どう発展させるつもりだったんだろうと気にはなるが

>>330
ようは、ゲスト会員の話をしているんだろ？
あんなの新規会員をその場で作成するのと同じことだよ。

>>333
挙句の果てに、
「それカレー調理器具じゃねーか。そんなの汎用的とはいえない。
いろんな調理器具をはめ込める規格を作れ。」

といっているやつまでいるから手に負えないｗ

汎用的な調理器具は鍋だろ

中華鍋だな

>>335
すばらしく重いサイトができそうですね

>>337-338
コンクリートクラスはだめだって誰かが言ってたｗ

>>339
それの解決策を君は思いつけたかな？

それはコンクリート批判の方が当りだと思うぞ

>>341
普通に実装してますが何か？

じゃあ問題ないじゃんｗ

おれにとっちゃ問題ない。
しかし、>>281は使えないよって話

じゃあ使えるようになおせばいいだけの話。

文句はいらない。改善したコードを示せ。

ぶｗ

なくなｗ

結局具体的な理由をちゃんと説明できないから
煽りだっていわれるんだよね。自業自得。

>>185があぁいう質問の仕方じゃなくて素直に質問してたら書いたかもな。