上に書いたコードをそのまま突っ込んでほしいとか、そういうことではなくて、検証が必要であることは十分認識しております。検索かけてもセッション対応についてはあまり語られているところがありませんので、立てさせていただきました。$varsが確定しておらず、$_REQUESTを使っているように見受けられます。13:47:17本BugTrackの先頭に各種リンクを追加。セッションで認証関係を作成しようとするなら上記パッチはあてないほうがいいでしょう。上記パッチのセッション、クッキーは公開情報を補助する役割として使う方向で考えるためのものです。プラグインのパッチなどがあります。それはまさしくパンドラの箱です。11:51:04おそらく、そのときには認証情報のプラグイン(もしかすると本体機能?)も含めてオフィシャルで作成したほうがいいでしょう。その参考になるのは他のCMS系ソフトウェア(xoopsとか)になっていくかとおもいます。11:55:16お疲れ様です*5。私がセッション変数を追加してできると考えているのは完璧な認証ではなく、現状の認証と同じくらいのものです。それは、例えば、一度凍結のパスワードを入力すると、そのウィンドウを閉じるまではパスワード入力が免除される、というような使い方ができないだろうか、と考えています。13:56:03それこそまさしくセッションによる認証の回避、というパンドラの箱なのです。箱から世界中に飛び出るものはセッションIDという名前の認証回避チケットです。一度蓋を開ければ最後、様々な側面から外に飛び出そうとします。それを押さえ込むために必要な背景情報は多様です。17:40:26なるほど*6。このページを足がかりにでも、色々調べ回ってからでも遅くないですよ。17:59:09しっかり勉強します。18:17:30いつもすいません。コメントありがとうございます。これで(このページで)上記実装のスタンスが明確になったと思います。どこに入れるべきか、といった話題があります。結局のところ程度の問題ではあるんですけどね。11:31:38結局のところ、認証の場合はPukiWikiを使用している人のセキュリティのレベルをどこにおくかになります。自由に開発者に使わせてみてもいいんじゃないですか?もともと本家で対応していない理由はクロスブラウザ対応やサーバ(自己/プロパイダ)やPHPのモード(CGI/SAPI)と多岐にわたってメンテするのを回避している理由もありましたし。11:38:37どのような下地か、という点につきましては、上記のやりとりの中で「補助的な利用のためのもの」であるということは明確かと思います。それを踏まえて実装するならば、パッと思いつくだけでも以下のようなチェックポイントがあると思います。SAPI対応全般をクリアにすること。(というかSSL対応全般をクリアにすること。お手数をおかけいたします。