WebSurfer's Home

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

ASPNETDB.mdf の作り方

by WebSurfer 2012年7月4日 23:20

ASP.NET フォーム認証用のユーザー情報のストアとして SQL Server を用いる場合、サーバーでのデータベースの作り方を備忘録として書いておきます。

開発環境では、開発マシンに Visual Studio と SQL Server がインストールされていれば、Visual Studio の「ASP.NET Webサイト管理ツール」が、フォーム認証用のデータベースファイル ASPNETDB.MDF をアプリケーションルート直下の App_Data フォルダに自動生成してくれます。

自分がサーバーの管理者であれば、開発マシンの ASPNETDB.MDF ファイルをサーバーにコピーして使うことができます。(もしくは、下に述べるデータベース作成用のスクリプトを SQL Server Management Studio を使って実行する手もあります)

しかしながら、ホスティングサービス(レンタルサーバー)を利用している場合は上記のようなことはできません。ホスティングサービス会社に、自分が作った ASPNETDB.MDF を送って SQL Server にアタッチしてもらうのも望み薄です。

では、どうするかと言えば、通常、ホスティングサービス会社が SQL Server の管理ツールを提供しているはずなので、そのツールからスクリプトを走らせることができれば、遠隔地にあるサーバーにデータベースを作成することができるはずです。

以下に、自分が使っているホスティングサービス(ActiveWeb)の場合の例を書きます。ActiveWeb の管理ツールは Plesk と myLittleAdmin です。ExpressWeb の場合も、同じ会社がサービスしているので、手順は大筋で同じです。(他のホスティングサービスの場合は不明です。無責任モードですみません)

  1. まず、ホスティングサービス会社が提供しているツールを使って SQL Server にデータベースを作成し、ユーザーの設定をします。その時点で、データベース名、ユーザー名、パスワードが決まるはずですが、それらは、それぞれ、接続文字列の Initial Catalog、User ID、Password に設定するので覚えておいてください。(接続文字列の Server に設定するサーバー名は、別にホスティングサービス会社より通知されていると思います)
  2. 次に、自分の開発マシンで、aspnet_regsql.exe を利用して、必要な機能(テーブル、ストアドプロシージャ、トリガ)を上記 (1) で作ったデーターベースに追加するための SQL スクリプトファイルを生成します。以下のようにコマンドラインから入力します。この例で、FormsAuth は上記 1 で指定したデータベース名、script.sql は生成する SQL スクリプトファイルの名前です。

コマンドラインから aspnet_regsql を実行

  1. ホスティングサービス会社が提供している SQL Server の管理ツールを使用して、上記 2 で作ったスクリプトを走らせ、データベースにテーブル、ストアドプロシージャ、トリガを作成します。ActiveWeb、ExpressWeb の場合は myLittleAdmin を利用します。下の画像を参照してください。「新しいクエリ」という文字の下にある myLittleAdmin 上のファイルを開くボタン 印のボタンをクリックすると、ファイルを選択するダイアログが開きますので、それでステップ 2 で作ったスクリプトを指定します。

myLitleAdmin でスクリプトの実行

  1. 接続文字列を実環境に合わせて修正します。開発環境は、開発マシンの SQL Server Express に Windows 認証でユーザーインスタンスを利用して接続しているのを、レンタルサーバーでは Express 版でない SQL Server の既定のインスタンスに SQL Server 認証で接続するのが普通だと思います。その場合、接続文字列は以下のようになるはずです。不明な点はレンタルサーバー会社に確認してください。

開発環境(Visual Studio が自動生成)

<connectionStrings>
  <add name="ApplicationServices"
    connectionString=
     "data source=.\SQLEXPRESS;
      Integrated Security=SSPI;
      AttachDBFilename=|DataDirectory|\aspnetdb.mdf;
      User Instance=true"
    providerName="System.Data.SqlClient" />
</connectionStrings>

運用環境

<connectionStrings>
  <add name="ApplicationServices"
    connectionString=
     "Server=サーバー名;
      User ID=ユーザー名;
      Password=パスワード;
      Initial Catalog=データベース名"
    providerName="System.Data.SqlClient" />
</connectionStrings>
  1. ここまでで ASPNETDB.mdf 相当のデータベースが生成され、Web アプリから接続できるようになっているはずです。ただし、データベースのテーブルの中身は空なので、自分でユーザー登録とロールの設定が必要です。

管理用のページを作るなりしないとユーザー登録やロールの設定はできないので、そこが少々面倒かも知れません。参考に、指定されたユーザーを指定されたロールに追加するサンプルコードのある MSDN ライブラリのページ Roles.AddUserToRole メソッド を紹介しておきます。

それが問題であれば、開発環境で作ったユーザー登録やロールが設定済みの ASPNETDB.mdf から、Database Publishing Wizard を利用してスクリプトを生成すれば、上記 5 の手順は不要になるはずです。

Tags:

Authentication

Froms 認証クッキーの永続化

by WebSurfer 2011年12月3日 13:29

ASP.NET 標準の Forms 認証に使用される認証クッキーの「永続化」については、先の記事 永続的ってデフォルトで 30 分? に書きましたが、続けて「永続化」した時としない時の動作の違いを備忘録として書いておきます。

まず、ログインに成功した時にサーバーからブラウザに送られる認証クッキーですが、「永続化」した場合は以下のよう expires によって有効期限が指定されます。「永続化」しない場合は認証クッキーに expires=...; が存在しません。

Set-Cookie: .ASPXAUTH=...; expires=Wed, 30-Nov-2011 13:21:29 GMT; path=/; HttpOnly

expires の日時は、ログインに成功した時点から authentication の forms 要素 の timeout 属性で設定した時間(デフォルトで 30 分)だけ先の日時になります。

認証クッキーは認証チケットの入れ物に過ぎないことに注意してください。認証チケットの有効期限は、ユーザー名などの他の情報と一緒に暗号化されて、認証チケットの中に含まれています。

[永続化」した場合の認証クッキーの有効期限は、認証チケットの有効期限と同じになりますが、認証クッキーの有効期限で認証チケットの有効期限を判定しているわけではありません(そもそも、サーバー側ではクライアントから送られてきたクッキーの有効期限はわかりません)。

認証チケットが発行された以降、有効な認証チケットがブラウザからの要求と一緒にサーバーに送られてくれば、サーバーはユーザーを認証済みと見なし、匿名アクセスが許可されてないペ��ジへのアクセスを許可します。

認証チケットが送られてこない場合、もしくは送られてきた認証チケットが期限切れの場合、サーバーはユーザーをログイン画面へリダイレクトします。

slidingExpiration が true になっている場合、timeout 属性で設定した時間の半分を過ぎてアクセスすると、有効期限が延長された認証チケット/クッキーが再発行されます。「永続化」している場合は、expires=...; も延長されて認証クッキーが再発行され、クライアントの HDD 上の既存の認証クッキーが上書きされます。

認証クッキーを「永続化」した場合としない場合(即ち、認証クッキーの有効期限の有無)では、以下のように動きが異なります。

「永続化」した場合

クッキーに有効期限がある(即ち、Set-Cookie: に expires=...; が指定される)ので、ブラウザはクッキーを HDD に保存します。

ブラウザを閉じたり Windows をシャットダウンしたりしても、再度ブラウザを立ち上げてアクセスすれば、ブラウザは認証クッキーを HDD から取得してサーバーに送ります。

クッキーの有効期限が切れると、ユーザーが次にサイトを訪問した時にブラウザによって削除されます。

次回アクセスする際にログイン操作の手間が省けるということが「永続化」のメリットですが、timeout をデフォルトの 30 分程度の短い時間に設定した場合はほとんど意味がないです。

ちなみに、BlogEngine.NET のオリジナルの web.config では timeout="129600"(90 日)に設定してありました。「永続化」もこのぐらい長ければ役に立つと思いますが。

でも、セキュリティ上は、timeout をできるだけ短い時間に、ついでに slidingExpiration は false に設定しておく方がよさそうです。

「永続化」しない場合

この場合、認証クッキーはブラウザのメモリにしか保持されません。従って、ブラウザを閉じれば認証クッキーは消えます。

逆に、ブラウザを閉じなければ認証クッキーは消えません。要求のたびに送られ続けます。(ただし、中身の認証チケットが有効かどうかは別の話で、timeout の設定によります)

Tags: , ,

Authentication

永続的ってデフォルトで 30 分?

by WebSurfer 2011年11月25日 22:57

ASP.NET の標準の Forms 認証で、Login コントロールを使用してログインのページを作ると、デフォルトで [次回のために保存] チェックボックスが表示されます。

フォーム認証のログイン画面

これにチェックを入れてログインすると永続的な cookie が発行される、と MSDN ライブラリなどに書いてあります。

永続的というのは、cookie の有効期限が 50 年だからというのはあちこちで目にするので(例:Login.RememberMeSet プロパティASP.NET の組み込み機能を活用し、Web 攻撃を回避する)、信じて疑わなかったのですが、どうやら間違い(修正漏れ?)のようです。

[次回のために保存] チェックボックスをオン(Login.RememberMeSet を true)に設定してログインすると、Set-Cookie: ヘッダーに expires が指定されますが、それは 50 年先ではなく、timeout で設定した時間(デフォルトで 30 分)だけ先の時間になりました。

「永続的ってデフォルトで 30 分なの?」って感じです。(苦笑)

MSDN ライブラリの authentication の forms 要素 (ASP.NET 設定スキーマ) のメモに "ASP.NET V1.1 の場合、永続的な Cookie は timeout 属性の設定に関係なくタイムアウトしません。一方、ASP.NET V2.0 の場合、永続的な Cookie は timeout 属性に従ってタイムアウトします。" とありますが、どうやらこれが正しいようです。

なお、認証クッキーの中にある認証チケットの有効期限は認証クッキーの有効期限と同じに設定され、slidingExpiration も期待通り動く(有効期限が延長されたクッキーが発行される)のは確認しました。

Tags: ,

Authentication

About this blog

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

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar