WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

パスワードに有効期限を設定

by WebSurfer 2011年10月22日 16:31

Forms 認証でパスワードに有効期限を設定するにはどうしたらよいでしょうか?

有効期限切れパスワードの変更

有効期限を知るためのデータ(例えば、最初にアカウントを作成した日時またはパスワードを変更した日時)をデータベースに記録し、ユーザーがログインした際にそのデータを取得して期限が過ぎているか否かの判断をするという操作が必要です。

組み込みの機能にそのようなものはないと思っていましたが、よく調べてみたら、標準の Forms 認証用 SQL Server データベースの aspnet_Membership テーブルに LastPasswordChangedDate というフィールドがあり、それを取得するために MembershipUser.LastPasswordChangedDate プロパティ が用意されていました。

これを利用すれば、パスワードに有効期限を設け、ユーザーがログインする際に有効期限が過ぎていたら ChangePassword コントロール を表示して、ユーザーにパスワード変更を促すというような操作が簡単に可能になります。

以下のコードは、パスワードの有効期限を 90 日とし、ユーザーがログインする際に 90 日を過ぎていたら Login コンロトールを非表示にするとともに ChangePassword コントロールを表示し(上の画像がそれです)、パスワードを変更したら Login コンロトールを再度表示して新しいパスワードでログインするというシナリオになっています。

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Web.Security" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

  double expireDays = 90;

  protected void Login1_LoggingIn(object sender, 
    LoginCancelEventArgs e)
  {
    MembershipUser user = 
      Membership.GetUser(Login1.UserName);

    if (user == null)
    {
      // MembershipUser が取得できなければその後の
      // 処置は Login コントロールに任せる。
      return;
    }

    if (user.LastPasswordChangedDate.AddDays(expireDays) <
      DateTime.Now)
    {
      Msg.Visible = true;
      Msg.Text = "パスワードが有効期限を過ぎています。";
      ChangePassword1.UserName = Login1.UserName;
      ChangePasswordPanel.Visible = true;
      LoginPanel.Visible = false;
      e.Cancel = true;
    }
    else
    {
      Msg.Visible = false;
    }
  }

  protected void _ChangingPassword(object sender, 
    LoginCancelEventArgs e)
  {
    if (ChangePassword1.CurrentPassword == 
      ChangePassword1.NewPassword)
    {
      Msg.Visible = true;
      Msg.Text = "新旧パスワードが同じです。";
      e.Cancel = true;
    }
    else
    {
      Msg.Visible = false;
    }        
  }

  protected void _ChangedPassword(object sender, EventArgs e)
  {
    ChangePasswordPanel.Visible = false;
    LoginPanel.Visible = true;
    Msg.Visible = true;
    Msg.Text = "新しいパスワードでログインしてください。";
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title>Login</title>
</head>
<body>
  <form id="form1" runat="server">
    <h3>有効期限つきパスワードでのログイン操作</h3>

    <asp:Label id="Msg" 
      runat="server" 
      ForeColor="maroon"  
      Visible="False" />
    <br />

    <asp:Panel ID="LoginPanel" 
      runat="server">
      <asp:Login ID="Login1" 
        runat="server" 
        DisplayRememberMe="False" 
        OnLoggingIn="Login1_LoggingIn">
      </asp:Login>
    </asp:Panel>

    <asp:Panel ID="ChangePasswordPanel" 
      runat="server" 
      Visible="False">
      <asp:ChangePassword ID="ChangePassword1" 
        runat="server" 
        DisplayUserName="True" 
        OnChangingPassword="_ChangingPassword" 
        OnChangedPassword="_ChangedPassword" 
        CancelDestinationPageUrl="~/Default.aspx">
      </asp:ChangePassword>
    </asp:Panel>
  </form>
</body>
</html>

参考にしたのは MembershipUser.LastPasswordChangedDate プロパティChangePassword.CurrentPassword プロパティ のサンプルコードです。

Tags: ,

Authentication

Forms 認証チケットの受渡しに URI を使用

by WebSurfer 2011年8月6日 14:59

今回は URI に認証チケットを追加して送る場合の Forms 認証のログインとログアウト動作について調べてみました。クッキーを使用した場合については、先の記事 Forms 認証のログイン・ログオフ動作 を参照してください。

認証チケットの入れ物に URI を使った場合の Forms 認証のログイン・ログオフ動作

web.config で authentication の forms 要素 の cookieless 属性を AutoDetect に設定し、Firefox 5 で「サイトから送られてきた Cookie を保存する」のチェックを外してテストしました。

URI を使用する場合の問題は、上の画像に示したように、ブラウザのアドレスバーに認証チケットが表示されるので、認証チケットが一般ユーザーの目に直接さらられてしまうことです。というわけで、できればクッキーのみを使うようにしたほうが無難だと思われます。

***** ログイン *****

  1. 匿名アクセスが許可されているページ default.aspx で、ログインしていない状態から LoginStatus をクリックする。
  2. JavaScrip が起動してポストバック(default.aspx への POST 要求)がかかる。
  3. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。応答ヘッダーに含まれる Location(リダイレクト先)は web.config で指定したログインページ login.aspx となる。
  4. ブラウザはリダイレクト先のページ login.aspx を GET 要求する。・・・ここまではクッキーを使った場合と同じ。
  5. 再び、サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。応答ヘッダーに含まれる Location は同じく login.aspx だが、クエリ文字列に AspxAutoDetectCookieSupport=1 が追加されている。
  6. 再び、ブラウザはリダイレクト先のページ login.aspx を GET 要求する。前回の要求の時と違うのは、クエリ文字列に AspxAutoDetectCookieSupport=1 が追加されていること。
  7. サーバーから応答(login.aspx)が返ってく��。
  8. ユーザーが ID とパスワードを入力して[ログイン]ボタンをクリックする。
  9. [ログイン]ボタンのクリックで login.aspx にポストバックがかかる。ただし、form 要素の action 属性に (X(1))/ が追加されているので、POST 先は login.aspx ではなく (X(1))/login.aspx となる。クエリ文字列 にも AspxAutoDetectCookieSupport=1 が追加されている。
  10. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。応答ヘッダーに含まれる Location は (X(1)F(mfZdwXpqsmZ ... 2Qg2g1))/default.aspx となり、mfZdwXpqsmZ ... 2Qg2g1 という認証チケットが追加されている。
  11. リダイレクト指示を受けて、ブラウザは (X(1)F(mfZdwXpqsmZ ... 2Qg2g1))/default.aspx を GET 要求する。
  12. サーバーから応答(default.aspx)が返ってくる。認証チケットが URI に含まれているのでユーザーは認証済みとなる。

***** ログアウト *****

  1. ログインしている状態のページ (X(1)F(mfZdwXpqsmZ ... 2Qg2g1))/default.aspx で LoginStatus をクリック。
  2. JavaScrip でポストバックがかかる。
  3. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。Location は (X(1))/default.aspx となる。この時、URI から認証チケットは削除されている。
  4. ブラウザは (X(1))/default.aspx を GET 要求する。
  5. サーバーから応答 (X(1))/default.aspx が返ってくる(ログアウトした後も URI に (X(1)) は含まれる)。ユーザーはログアウト状態となる。

Tags: ,

Authentication

Forms 認証のログイン・ログオフ動作

by WebSurfer 2011年8月3日 22:14

Froms 認証のログイン・ログオフ動作

認証クッキーを使用した場合における Forms 認証のログインとログアウト動作で、サーバーとクライアントのやり取りがどのように行われているか調べてみましたので、備忘録として書いておきます。

ログアウト操作で、認証クッキーを削除するため、ポストバックして同じページにリダイレクトをかけていることと、ロール名クッキーの追加と削除が認証クッキーより 1 ステップ遅れるのが新しい発見でした。

認証クッキーを使用せず、代わりに URL に認証チケットを追加して送るケースではどうなっているかは別途調べる予定です。

***** ログイン *****

  1. 匿名アクセスが許可されているあるページ(ここでは default.aspx とする)において、ログインしていない状態から LoginStatus をクリックする。
  2. JavaScrip が起動してポストバック(default.aspx への POST 要求)がかかる。この時、サーバーに送信される隠しフィールド __EVENTTARGET に LoginStatus の UniqueID が設定される(これにより、サーバーはログイン要求であると認識するらしい)。
  3. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。応答ヘッダーに含まれる Location(リダイレクト先)は web.config で指定されたログインページ(ここでは login.aspx とする)となる。
  4. リダイレクト指示を受けて、ブラウザは login.aspx を GET 要求する。
  5. サーバーから応答(login.aspx)が返ってくる。
  6. ユーザーが ID とパスワードを入力して[ログイン]ボタンをクリックする。
  7. [ログイン]ボタンのクリックで login.aspx にポストバックがかかる。
  8. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。応答ヘッダーに含まれる Location は default.aspx となる。この時、サーバーからの応答ヘッダーには認証クッキーが含まれる。(この時点ではロール名クッキーは送られないので注意)
  9. リダイレクト指示を受けて、ブラウザは default.aspx を GET 要求する。この時、上のステップで受信した認証クッキーを要求ヘッダーに含める。
  10. サーバーから応答(default.aspx)が返ってくる。認証クッキーが要求ヘッダーに含まれているので、ユーザーは認証済みとなる。(この時点で応答ヘッダーにロール名クッキーが含まれて送られてくる)

***** ログアウト *****

  1. あるページ(default.aspx とする)で、ログインしている状態から LoginStatus をクリック。
  2. JavaScrip でポストバック(default.aspx への POST 要求)がかかる。この時、サーバーに送信される隠しフィールド __EVENTTARGET には LoginStatus の UniqueID が設定される(これにより、サーバーはログアウト要求であると認識するらしい)。
  3. サーバーからリダイレクト指示(HTTP/1.1 302 Found)が返ってくる。ただし、リダイレクト先は同一ページ(Location は default.aspx)となる。この時、認証クッキーを削除するため、応答ヘッダの Set-Cookie は、認証クッキーを空にして、expires を過去の日時に設定している。
  4. ブラウザは default.aspx を GET 要求する。この前のステップの、応答ヘッダの Set-Cookie の設定により、認証クッキーは要求ヘッダーには含まれなくなる。(ただし、ロール名クッキーはこの時点ではまだ要求ヘッダーに含まれている)
  5. サーバーから応答 (default.aspx) が返ってくる。ユーザーはログアウト状態となる。この時、ロール名クッキーを削除するため、応答ヘッダの Set-Cookie で、ロール名クッキーを空にして、expires を過去の日時に設定している。

なお、Windows 認証の場合は、先の記事 Windows 認証でのロール に示した Windows OS の認証ダイアログを使います。従って、Web ページにはログイン画面は実装できませんし、ログイン操作も Forms 認証とは異なります。

また、ログアウトについても、Windows 認証の場合は一旦ログインしたユーザー情報はブラウザを閉じるまで保持され続けるので、Forms 認証とは異なり、Web ページにログオフ機能は実装できません。

Tags:

Authentication

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年4月  >>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar