- - PR -
ASP.NET 3.5でのセッションタイムアウトを判定する場所について
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2009-02-05 12:06
> これを見ると、ページ毎の処理より前に、認証、承認は行われているのですね。
はい、そうなります。 認証にはクッキーを利用していますが、その認証チケットはセッションとは別に管理されています。 まぁ、ASP.NETに組み込まれている認証を利用している場合、となりますが。 > たとえ匿名ユーザー(セッションタイムアウトによるユーザー)でもページ毎の処理は実行されるということですかね? ああ、セッションの有無とかでユーザ認証を独自に実装しているのであれば、その実装に依存する話になっちゃうので、そこでどう動くかは実装によりますね。 | ||||
|
投稿日時: 2009-02-06 13:45
どっとねっとふぁんさん
知りませんでした、認証チケットとセッションのクッキーが別で管理されているなんて! 僕はてっきり同一のクッキーなのかと。まだまだ無知です。。。 たぶんこっちが認証用で「.ASPXAUTH」 こっちがセッション用「ASP.NET_SessionId」 ってことですね。 Web.configで匿名ユーザーと承認ユーザーがアクセスできるページを設定して、ログイン時にユーザーIDとパスワードの存在確認をoracleに問い合わせてOKなら FormsAuthentication.SetAuthCookie([ユーザーID], False) としていて、これはASP.NETに組み込まれている認証を使用していると僕は思っているのですが。(違うのかな?) なんとなく理解できた気がしたので、書いてみる。 一度ログイン認証が成功したユーザーは認証用チケットとセッションクッキーをもっていて、ある画面でセッションタイムアウトとなった場合に、成功した認証チケットは持っているので、認証、承認にはクリアして、該当のページでセッションの情報の使用を行った時にWebサーバー上にはセッションがないので、エラーとなっているということですね!(間違っているかもしれないけど。。。) なんか分かった気になりました。笑 どっとねっとふぁんさん色々とありがとうございました。 | ||||
|
投稿日時: 2009-02-06 14:08
> FormsAuthentication.SetAuthCookie([ユーザーID], False)
はい、これを使っているならASP.NETが用意している認証を利用しています。 あとのほうで書かれていることもあっていると思います。 |