12:28こんにちは。私が借りている共用サーバーがクラスタリング環境というものらしく、セッション機能は使えないと言われました。書籍などで勉強をしているのですが、ログイン認証のサンプルはセッションを使うものばかりで困っています。18:21こんばんわ。クッキーにIDとパスワードを保存するのは危険です。通信の傍受によって漏洩することが考えられます。認証フォームの段階からSSL通信は必須でしょう。通信傍受以外にも、クロスサイトスプリクティングの脅威もありますので万が一漏洩した場合の防衛措置も必要です。認証がOKならば「一時的なユニークなID」を生成しクッキーとサーバの両方に保存して、これらを照合して認証済みの確認にすべきです。ユニークなIDが漏洩した時のために、IDの妥当性を確認する仕組みや、すみやかにIDを無効にする仕組みが必要です。今、コードをさわれないので、お時間頂ければ、これらを考慮した自前のセッションハンドラに手を加えて見ます。デフォルトのままユーザ認証に用いるのは危険です。13:07ありがとうございます。使い方を調べて利用します。漏洩した場合の防衛措置とは、それらのことを言っているのでしょうか。見本が欲しいのが本音です。自分のレベルでは残念ながら書籍を真似していくしかありません。ユニークIDを発生することもできないのですが、IDの妥当性を確認するロジックも想像がつきません。ユニークIDは認証者のIPアドレスを使って生成されているので、たとえ同じユニークIDを使って攻撃者がアクセスをしてきても、IPアドレスが違うから認証者ではないと判断し、ユニークIDをDBから削除...と考えたのですが、こういった感じでしょうか。勉強不足で申し訳ありませんが、よろしければ続けてご教授をお願いします。19:26思いのほかてこずって遅くなりました。漏洩した場合の防衛措置とは、それらのことを言っているのでしょうか。XSS対策やSSL通信は、これらは情報が漏洩しないための対策ですね。SSL通信と、XSS対策を施してもウイルスやスパイウェアなど、ユーザの不注意で情報が漏れることもあります。クッキーにも、ID以外の情報は残さない。他のユーザがそのIDを使っても意味がないものにしてしまおう、という発想です。漏洩した場合の防衛措置とは、この、IDの妥当性を確認したり、古いIDを無効にしたり、といったことを指しています。ユニークIDを使う流れは、さとさんが考えていらっしゃる通りです。そこで、今使ってるセッションハンドラに手を加えて認証状態の管理を行うクラスを書いてみました。コピーして使ってみてください。するだけで、認証処理は含んでいません。今の認証処理は変えずに利用できます。・登録の有効期限を秒単位で設定できます。・指定の時間が経過するとuidを自動更新します。使い方ですが、あらかじめ、これ用のテーブルを作っておきます。自分の環境に合わせて書き換えます。通ったところに置きます。下のコードを参考にそれぞれの処理に書き加えてください。何かを出力(表示)する前に使用してください。更新せずに処理を続けると誤動作することが考えられます。可能な限り別のページに飛ばす処理を行ってください。ここは現在の認証処理に置き換えてください。認証OKとなったと仮定します。10:06わざわざサンプルを上げていただき、ありがとうございます。サンプルをテストして勉強します。書籍よりもゆうじさんに講師になってもらいたいぐらいです。09:40日本語入力がONになってなく送信されてしまいました...。パスワードも空だったので、上のレスは消せません。最初はセッションを使って書籍の通りにテストしたことがあったのですが、その時はセッションは有効でした。同じサーバーを使うとは限らないので使用できない...といった返事をもらいました。achさんの質問をチャンスがあったら、サーバー管理者へ質問してみたいと思います。