msg# 1
XUGJがダウンしているようですので、こちらに書き込ませていただきます。
XOOPS JP版のメンテプロジェクト
XOOPS JPExを始めたのですが、 GIJOEさん作の「オートログインハック」と「お手軽高速化ハック」をJPExに取り込ませていただいても問題ないでしょうか?
よろしくお願いいたします。
Votes:10
Average:7.00
msg# 1.1
monsukeさん、こんにちは。
Quote:
XOOPS JP版のメンテプロジェクトXOOPS JPExを始めたのですが、 GIJOEさん作の「オートログインハック」と「お手軽高速化ハック」をJPExに取り込ませていただいても問題ないでしょうか?
以前にも書きましたが、私のXOOPSに関するコードはすべてGPLです。
というわけで、どのような利用・取込みも、まったく問題ありません。確認も報告も不要です。
「GPLのHack」、となるとどういう扱いになるか、私にも正直判りませんが、Patchを当てたものの「配布」を目的とするときに、制限さえかけなければ問題ないと思われます。
Votes:9
Average:10.00
msg# 1.2
お返事ありがとうございます。
問題なし、確認・報告不要とのこと承知しました。
JPExのライセンスもGPLですので、その辺りは問題ないと思います。
お手数をお掛けして申し訳ありませんでした。
Votes:9
Average:10.00
msg# 1.2.1
monsuke さん、こんにちは。
今読み返してみると、私自身とてもぶっきらぼうに返事してますけど、そういう確認をしていただくことは迷惑でも何でもありません。むしろ感心してます。
ご丁寧にありがとうございました。
あと重要な書き忘れですが、「JPExプロジェクト頑張ってください」
私自身、XCL Optimizedなモジュールはチョロチョロ作ってますが、「専用」のモジュールは今後も作らないでしょうから。
(まったく新しいXCベースなら話は別)
リリース情報をXUGJにも投稿してくれたら嬉しいですね。
Votes:12
Average:9.17
msg# 1.3
ご丁寧にありがとうございます。
次のリリースからはXUGJでも告知させていただきます。
別件ですが、オートログインハックの再投稿についてバグレポです。
(私の勘違いでバグじゃなかったら・・・すみません)
1点目:
トークンありの投稿を再投稿する場合についてですが、セッションに保存されているトークンの半券が取得できないため、再投稿処理でトークンエラーになるのではないでしょうか。
2点目:
session_confirm.phpでhiddenタグを作成している箇所についてですが、チェックボックスのように値が配列で渡ってきた場合、正しいhiddenタグが作成できないのではないでしょうか。
今さらX2ネタで申し訳ありませんが、ご確認ください。
よろしくお願いします。
Votes:10
Average:10.00
msg# 1.4
1点目のトークンはX2標準のXoopsTokenのことを指していますが、再投稿を実現するためにはgticket2を使用する必要があるのでしょうか?
今ふと思いついただけなので、gticket2の実装までは確認していないのですが。
Votes:10
Average:9.00
msg# 1.3.1
monsukeさん、こんにちは。
おそらくは勘違いだと思います。
もともと、私のオートログインは、フォーム処理のセッション切れなどに対応したものではありません。
ログインセッションのタイムアウトについては、別の方法で対応してください。
オートログイン==常時ログイン状態
となると、CSRFに対して極めて弱くなってしまうので、なんらかのクエリが含まれている時点で、フォームを経由させる、という仕掛けが、session_confirmです。
だから、POSTデータが含まれている可能性も、当然想定していません。
チケット処理などは、まったく別の概念です。
Votes:9
Average:10.00
msg# 1.5
ご回答ありがとうございます。
オートログインハックに含まれるcommon.phpの198行目あたりで$_POSTがカラでなければ、session_confirm.phpにリダイレクトし、「時間切れでした。再投稿しますか?」というメッセージを表示していましたので、オートログインハックにセッション切れの再投稿機能があるものと思っていました。
あと余談ですが、X2のカスタムセッションは効いていませんね。
session.gc_maxlifetimeに$xoopsConfig['session_expire']の設定値をセットしていますが、session.cookie_lifetimeにセットしないといけないようです。
環境によって違うのかもしれませんが。
Votes:9
Average:10.00
msg# 1.5.1
monsukeさん、こんにちは。
Quote:
オートログインハックに含まれるcommon.phpの198行目あたりで$_POSTがカラでなければ、session_confirm.phpにリダイレクトし、「時間切れでした。再投稿しますか?」というメッセージを表示していましたので、オートログインハックにセッション切れの再投稿機能があるものと思っていました。
ああ、ほんとうですね。
あまりにも昔なので忘れてました。
確かにそういうことを実装しようとした残骸が見えます。
チケットさえなければ、おそらく動作するだろう、という気もします。
ただ、セッションが切れているのですから、チケットが効かないのは当然ですよね。
gticket2であれば、POSTデータだけは失わないように再投稿画面を出力してくれそうですが。
このあたりは確かに難しいところですね。
私自身、チケットシステムとオートログインで、思いっきり複雑な仕掛けにしちゃってますし。
Quote:
あと余談ですが、X2のカスタムセッションは効いていませんね。
session.gc_maxlifetimeに$xoopsConfig['session_expire']の設定値をセットしていますが、session.cookie_lifetimeにセットしないといけないようです。
環境によって違うのかもしれませんが。
このあたりは、チェックした記憶があります。
少なくともその時は正しく動作しました。
クライアント側(クッキー)の有効期限は、下の方でsetcookie()されてるはずですよ。
gc_maxlifetimeはサーバ側の有効期限設定なので、意味も全く違います。
Votes:10
Average:10.00
msg# 1.6
再投稿については、チケットが含まれない場合は正常に動作しています。
また、gticket2を使用している場合も正常に動作しますね。
カスタムセッションについては、XOOPSの管理画面でセッションタイムアウト時間を1分に設定しても、実際に1分でセッションがタイムアウトしていません。
(環境依存かもしれませんが)
session.gc_maxlifetimeにセッションタイムアウト時間を設定した場合、サーバー側でセッションデータのGCが行われる確率が「セッション開始 × session.gc_probability / session.gc_divisor」になるためではないかと推測しています。
セッションタイムアウト時間は、gc_maxlifetimeよりもcookie_lifetimeに設定した方が確実だと思いますが、もう少し検証してみたいと思います。
ありがとうございました。
Votes:11
Average:9.09
msg# 1.7
ソースを追いかけたところ、確率の問題でもないことが分かりましたので訂正します。
Quote:
クライアント側(クッキー)の有効期限は、下の方でsetcookie()されてるはずですよ。
gc_maxlifetimeはサーバ側の有効期限設定なので、意味も全く違います。
common.phpの192行目でsession_start()した際に、sessionテーブルからsession_idが一致するセッションデータを取得しますが、このsession_idは$xoopsConfig['session_expire']の設定が反映されていません。
(183行目でクッキーのsession_nameをsession_idに設定しようとしていますが、このクッキーはcommon.phpの201行目で$xoopsConfig['session_expire']の設定が反映されているため、すでに取得できません)
そしてここでのsession_idは、php.iniのsession.cookie_lifetimeの設定値に従って設定されます。
ですので、カスタムセッションを使う場合は、common.phpの189行目で
@ini_set('session.cookie_lifetime', $xoopsConfig['session_expire'] * 60);
を呼ぶ必要があると思います。
gc_maxlifetimeの設定もそういう意図で行われているのかと思いましたが、真相は分かりません。
Votes:11
Average:9.09
msg# 1.7.1
monsukeさん、こんにちは。
Quote:
common.phpの192行目でsession_start()した際に、sessionテーブルからsession_idが一致するセッションデータを取得しますが、このsession_idは$xoopsConfig['session_expire']の設定が反映されていません。
(183行目でクッキーのsession_nameをsession_idに設定しようとしていますが、このクッキーはcommon.phpの201行目で$xoopsConfig['session_expire']の設定が反映されているため、すでに取得できません)
そしてここでのsession_idは、php.iniのsession.cookie_lifetimeの設定値に従って設定されます。
ああ、なるほど。
先に、PHPSESSIDでセッションIDが送られてきてますね。
(そっちでもSet-Cookieされているのを見落としてました)
確かにこれじゃ、ブラウザを閉じるまで、有効期限の設定も何も効かないでしょう。
ただ、ブラウザを閉じた後については、そのちゃんとその設定は効いていると思いますよ。
それと、繰り返しになりますが、クッキーの生存時間と、サーバ側セッション情報の保持時間はまったく独立した事象ですので、gc_maxlifetimeの代わりにcookie_lifetimeをセットすべき、というのは違うでしょう。
それこそ、第3者へクッキーが漏洩した時に、セッションハイジャックを防御する可能性があるのは、gc_maxlifetimeのみであり、cookie_lifetimeなんて何の意味も持ちません。
そこを改善するなら、セッションハンドラで頻度設定を無視して、セッション開始前に期限切れのレコードを常に全部消しちゃう、くらいですかね。
Votes:10
Average:10.00
msg# 1.8
cookie_lifetimeだとダメな理由が理解できました。
cookie_lifetimeにこだわっているわけではありませんが、gc_maxlifetimeとcookie_lifetimeを併用すればよさそうですね。
プラス、セッション情報取得時に期限切れレコードを削除(もしくは検索条件に期限を追加)しておけば万全ですね。
Votes:10
Average:10.00
msg# 1.8.1
Quote:
cookie_lifetimeにこだわっているわけではありませんが、gc_maxlifetimeとcookie_lifetimeを併用すればよさそうですね。
monsukeさんも書かれてましたが、gc_maxlifetime だけだと、確かに確率の問題が発生してしまうので、むしろ
Quote:
プラス、セッション情報取得時に期限切れレコードを削除(もしくは検索条件に期限を追加)
こっちがMUSTかもしれませんね。
こんなことを書くのもナニですが、クッキーの有効期限が設定されたカスタムセッションの有効期限より長い分にはほとんど問題ないんですよ。
だって、肝心のセッション情報さえそのセッションID(クッキー)で取り出せないのなら、なんの意味もないんですから。だから、今までもこの部分は問題にならなかったのだと思います。
歴史的に見ても、X2のカスタムセッションって、おそらくはオートログインを実装しようとした名残ですよね。
ただ、そういう形でセッションを長期間保存すると、セッションテーブルがふくれあがるから、ログインIDとハッシュ済パスワードをクッキーで渡す形のオートログインにしましょう、となったわけで。(しかも、安全性という点では後者の方がさらに悪い)
ちゃんとセッションテーブルの掃除をして、一定期間毎にセッションIDを切替えれば、実はオートログインHack自体不要かもしれません。
Votes:10
Average:10.00
msg# 1.9
Quote:
ちゃんとセッションテーブルの掃除をして、一定期間毎にセッションIDを切替えれば、実はオートログインHack自体不要かもしれません。
うーん、なるほど。確かにそうですね。
オートログインハックの役割は、
「少し安全性(ログイン情報漏洩)が下がっても利便性(ログインの手間を省略)を優先したいユーザに
選択肢を提供すること」
かなぁと思っています。
Votes:8
Average:8.75