>>247
携帯サイト、なんて、そりゃぁもう。機種ごとにハンドメイドだよ。
これを解決してるオープンソースのフレームワークはない。

PerlならMobaSifがあるけどなぁ。

>>245
>>236,238の流れから言うと、まさにセキュアと非セキュアでセッションが
分離出来てていいじゃないかｗ
分離されすぎてクッキーすらデータの受け渡しに使えないけどな
どうやってフレームワークに組み込めばいいんだろう

クッキー切ってる人相手にシステム作ってる人なら、もともとドメイン関係ないし
素晴らしいフレームワークを持ってるんでは無かろうか

URLにセッションID差し込んでCookie使わない実装にするのなんて普通だろ
IDはアクセス毎に変える

>>253
これを言い出すと、もうセッションIDのクッキーをsecureにする意味もないな

>>253
PHPの$_SESSION自体そういう仕様になってなかったか？

use_trans_sid

まぁ、URLに差し込むだけじゃ携帯全機種対応は無理だけどな。

っていうか議論に問題だらけの端末の話を持ってくるのは暴論じゃないか？
携帯サイト対応ってそれだけで一仕事だよ。

SSL対応議論、参考になります！(ｷﾘｯ)
この手の話は、頭がこんがらがって十分に理解できていないです。
もっと勉強しなくちゃ、買い物サイトは作れないな～＞＜

誰も十分に理解できていないから、
はっきりとした答えが出せないんだろうな。

土日を利用して勉強してみましょう

継続を使ったWEBアプリ
http://www.thinkit.co.jp/article/74/1/

Kahuaは継続ベースのアプリケーションサーバ/フレームワーク
http://www.kahua.org/

セッションも良いけど継続もね☆

クッキーはサイズの制限があるから結局セッションを使うとして、
そのセッションをどうやって実現しているかだ。

セッションIDの格納にクッキーを使う場合。
非セキュアサイトでのセッションIDは盗聴されるから
非セキュアサイトでのセッションIDと、セキュアサイトのセッションIDは別に持たないといけない。
（セキュアサイトのセッションIDはセキュアサイトでしか送信されない。）

問題は、セキュアサイトでセッションに格納した情報が、非セキュアサイトとセキュアサイトの
セッションIDのどちらに関連付けられているかということ。

もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
盗聴して使えば、他人がセッションの情報を取得することが可能になる。

そもそも、セキュア、非セキュア、二つのセッションIDを持つことがPHP or フレームワークで可能なのか？という問題もある。

>>262
おまいさんの理解が浅いということだけはわかった。

何も書かないと単なる煽りと思われるので一つだけ例示すると、

> もし、非セキュアサイトでのセッションIDに関連付けられていたら、そのセッションIDを
> 盗聴して使えば、他人がセッションの情報を取得することが可能になる。

それは実装が甘いだけ。
非セキュアサイトに関連付けられたセッションIDを使いまわしたとしても、
たとえば、
「セキュアな情報を表示するためのトークンを持っていなければ表示しない」
という基本的なロジックでラップしてあればセキュアな情報を見ることはできない。

情報のキーになるのはセッションIDだけじゃない。普通にクッキー使うだろ。

>セキュアな情報を表示するためのトークン
それって一般にはセッションIDって呼ぶと思うの。

いいえ

おせっかいなオレが例を出したるわ。
・SSL下でログインに成功したら、トークン($uniq)を育成
・非セキュアなセッションでもいよいので$_SESSION['tokens'][] = sha1($uniq);
・$uniqをsecure属性をつけて、setcookie
・セキュアサイト内では、sha1($_COOKIE['uniq'])がセッションtokensに含まれるか検証。だめなら再認証に飛ばす

すくなくとも$uniqをセッションIDとは言わない。

>>266
で、これが有効な手段として、ここまでをライブラリ化して標準装備した
フレームワークは無いのか？無いとしたらどんな問題があるのってところで
やっと>>185,188の質問に戻るわけだし、このスレでの話題になるわけだな。
まあそれに関する議論？もちょろちょろあるが。

おれとしては、添付ライブラリとしてはあってもいいと思うな。くだらんヘルパーを
ごちょごちょつけてるんだから、ついでに。

なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問

そんなに欲しかったら開発リクエストすればいいんじゃない？
投票が集まればサクッと作るでしょ。

>>268
>>266の処理を一行で書かれたら絶対に読みたくない。

>>268が冗長なだけ

>>268じゃなくて、>>266

>>262-272
マジで参考になります＾＾（もっとやれ的な意味で）

フレームワークを勘違いしたひとが沸いて荒らしてくれたおかげでスレの進みが半端ネェ！
たまにこういうことがあるから面白い

>>274
フレームワークの話題も振れずかといって実装についての話もできないのに
レスするのって寂しくならないか？

>>266
そこら辺の処理をちゃんと説明している本って無い？

>>268
> なんで、1行で済む処理をライブラリかしたがるのか、いまだに疑問

それは、君が説明した事からも分かるように、実装の説明をする余地があるからだよ。
そしてこれは汎用的に使える処理であり、ビジネスロジックではない。

ビジネスロジックに集中できるようにしてくれるのがフレームワークのよいところ。

汎用的ではない。
インフラの扱いやサイトのセキュリティポリシーや集金ロジックに密接に関係する。

>>277
それはフレームワークのよいところを語りたかったわけ？

>>277
それが汎用的な処理だっていうんなら、汎用的なクラスを書いてここに貼ってくれ
みんな喜ぶ。

>>280
ヒントやるから実装は自分でやれな。

SSL_Login_Class

セキュアにするべきページの一覧や正規表現を設定配列に入れておく。

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

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

セキュアトークンのサーバー側のデータは、セッションでも独自のファイルやデータベースにも格納可能。
ハッシュはsha1でもそれ以外でも選択可能。

以上のことをやってくれるクラス。

使い方は簡単。CakePHP風に言えば共通のコントローラAppControllerの
componentsに上記のクラスを入れるだけ。これとセキュアページのリストさえあれば
具体的な実装を書かなくてすむ。

それのどこが汎用的なんだよ。個別実装べったりじゃん。
日本語の蘊蓄はいらないから、汎用的にするためのインターフェースでも示してくれ。

>>282
お前にとって汎用的とはどういうことを指す言葉なんだ？

例を出して説明したまえ。

セキュアにするためのロジックだよ。
>>266に書いてあるのは、セキュアなサイトを作る時のHelloWorld
実サイトでは、Yahooにしろamazonでも楽天でも>>266とは別のロジック。

そういうロジックを設定でインジェクションできないなら汎用的とは言わない。

>>284

>>281のはロジックの一つだよ。
別のロジックを使いたければ、別のロジックを実装したクラスを
AppControllerのcomponentsに設定すればいいだけ。

これで汎用的になりましたね（笑）

あほか、だったら、FWが持ってる認証クラスで十分やんけ

んだ。

>>286
本当に十分なのか？ FWが持っている認証クラスが
このようなロジックになっているのか？

>>266のロジックなのか？ それともYahoo、Amazon、楽天のロジックのなのか？


それが、そもそもの>>185,188の質問だろうが。
> フレームワークのSSL対応ってどうなっているのでしょうか？

それで答えは？

>>288
結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その
ロジックを実装したクラスを設定するわけだろ。
それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。

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

対応する必要なし。

>>289
> それなら、FWが持ってる認証クラスのアサーションにそのロジックを指定するだけ。

そのロジックをお前は毎回作るのか？
そのロジックは使いまわし出来るだろ？

それを汎用的という。

>>285
> >>281のはロジックの一つだよ。

うは、コンクリートじゃんおもいっきり

> 結局、>>281に書いたクラスで、何かサービスを実装しようと思ったら、その

考え方がおかしいね。 >>281のクラスを使ってサービスを実装するんじゃない。

なにかのサービスを実装したとき、>>281のクラスを利用する。

考え方が逆だよ。

>>291
コンクリートだねぇ。だからなに？

>>290
元はといえば、お前さんの書いたクラスのサンプルが汎用的じゃないわけだろ。
ロジックはサイトの管理ポリシーによって違うでしょ。
それをカバーできるようは汎用的な設計を示してから言ってくれ。

>>293
汎用的じゃないって、告白ありがとう

>>292

>>281のクラスじゃ実装できないサービスがてんこ盛りなんですが

>>294
お前はロジックという言葉の使い方がおかしい。
管理ポリシーは違っても、それを実装するロジック（数パターンある）は同じ。
ロジックと管理ポリシーは違うもの。

>>297
まぁ、そういうことだろうな。
数パターンしか思いつかないレベルならいいや。おまえさんすごいよ。

>>295
あのなぁ。お前、コンクリートと汎用的とは別の考え方だよ。
GUIの例で言えば分かるだろ。

テキストボックスはコンクリートクラスであるが、
汎用的に使われるパーツだ。

抽象クラスと汎用的つ使えるクラスをごっちゃにするなよ。

>>299
君の汎用的ってのは、１つのロジックを複数のサイトで使えるってことね。了解