今回はいよいよサンプルのコードを追ってみます。
ただし、単にソースを追いかけても面白く無いと思います。...ので、この「スターターサイト」テンプレートに対して、ちょっとだけ仕様を追加・変更する事を例に挙げながら、やってみようと思います。
「スターターサイト」に対して追加・変更する仕様
- ログイン時に利用するIDを、メールアドレス無く英数字からなる一意の「ログインID」とする
- メールアドレスも保持する
- ユーザ情報として、氏名と年齢の入力を受け付ける
- ログインIDは変更させないが、その他の氏名、年齢、メールアドレスは変更可能にする
- 情報を格納するファイル名を「StarterSite.sdf」ではなく「MySite.sdf」とする
- ユーザ情報を格納するテーブル名は「UserInfo」とする
情報の粒度が若干アレですが、とりあえずは上記を実装することを目標にしたいと思います。
１：第一歩、WebSecurityの初期化コード
WebSecurityクラスに関わるまず最初の一歩は、「_AppStart.cshtml」から始まります。
ASP.NET Web Pagesにおいて先頭が「_（アンダースコア）」から始まるファイルはちょっと特殊なファイルという扱いになっています。例えばブラウザから直接アクセスしても、表示することができません。
それらのうち、「_AppStart.cshtml」という名前のファイルはさらに特別扱いされていて、『ブラウザからいかなるファイルにアクセスがあった際にも必ず最初に実行される』という性質があります。
例えば「~/Default.cshtml」というファイルがあって、ブラウザから「http://localhost/Default.cshtml」とアクセスしたときにでも、まず先に暗黙で_AppStart.cshtmlが先に呼び出されてからDefault.cshtmlが呼び出される、という動きになります。
すなわち、この_AppStart.cshtmlに書かれているコードは必ず最初に実行される、という事になります。
ではこのファイルを開いて中を見てみましょう。左のファイル一覧から_AppStart.cshtmlをダブルクリックすると、開くことができます。
すると、
- @{}で囲まれたコードブロックが一つある
- コードブロックの一行目に「WebSecurity.InitializeDatabaseConnection」の記述がある
- 2行目から、WebMailクラスを使った記述が書かれ、コメントアウトされている
事が見て取れると思います。
もちろん、注目するのはWebSecurity.InitializeDatabaseConnectionの行です。
WebSecurity.InitializeDatabaseConnection("StarterSite", "UserProfile", "UserId", "Email", true);
こんな風に書いてあると思います。
ここで、WebSecurity.InitializeDatabaseConnectionのリファレンスを見てみましょう。
WebSecurity.InitializeDatabaseConnection Method (WebMatrix.WebData)
引数の個数が違うオーバーロードがありますが、とりあえず一つ目（引数の数が少ない方）を見てみてください。
せっかくですので引数の意味を一つ一つ見ていきましょう。こっちです。
WebSecurity.InitializeDatabaseConnection Method (String, String, String, String, Boolean) (WebMatrix.WebData)
- 第1引数:connectionStringName（接続文字列）
文字通り、データベースの接続文字列を指定します。
SQL Server CEの場合は、拡張子抜きのファイル名で指定します。
SQL Server等のデータベースを使う場合は、Web.ConfigのconnectionStringsセクションに記述した接続情報を指定するNameを書きます。
今回のサンプルコードを見てみると、"StarterSite"と書いてあります。前回確認した通りこのサンプルが規定で持っているSQLCEのファイル名は"StarterSite.sdf"ですので、ここではこのSQLCEのファイルを指定していることがわかります。
- 第2引数：userTableName（ユーザテーブル名）
これも文字通りユーザ情報を格納するテーブル名を指定します。
サンプルコードには"UserProfile"と書いてありますね。これも前回確認した、ユーザ情報が格納されていうテーブルと一致していると思います。ユーザ情報を格納するテーブル名を変更する（した）場合は、ここも変更する必要があります。
- 第3引数：userIdColumn（ユーザID格納カラム名）
第2引数で指定したテーブルにて、ユーザIDを格納するカラムの名前を指定します。ここで指定されたカラムに格納される値は、webpages_Membership等関連テーブルとのリレーションのキーになりますし、WebSecurityクラスの各種プロパティやメソッドで「UserID」として利用されます。（たとえば、CurrentUserIdプロパティ等）。変更することでユーザIDとして使用するカラムの名前を変更することができますが、型はintである必要があります。
- 第4引数：userNameColumn（ユーザ名称格納カラム名）
第3引数と同様、ユーザ名として利用されるカラムの名称を指定します。ここで指定されたカラムに格納される値はWebSecurityクラスの各種メンバで、UserNameとして利用されます。通常、ログインIDとして利用されたりします。
- 第5引数：autoCreateTables（ユーザテーブル名）
最後の引数は、自動的にユーザテーブルを作成するかどうかです。trueを指定すると、同名のテーブルがデータベースに存在していない場合に自動作成されます。なお作成されるのは第２引数で指定された名称のユーザーテーブルだけではなく、webpages_Membership等のwebpages_*のテーブルについても同様です。ただし、trueを指定した場合でも「データベース自身」は自動作成されません。データべース自体はいかなる場合でもあらかじめ作成しておく必要があります。
以上で、引数の役割が理解できたと思います。割と単純だったのではないでしょうか？これが理解できると、先に挙げた今回試みる予定の仕様変更についても、いくつかここでやっておく必要があることに気が付くかもしれません。
…が、今はとりあえずここまでにして、もうちょっとだけ先に進みます。
ちなみに、今回触れなかった、引数が一つ多いオーバーロードについては、以前に日記で触れていますのでそちらも参照してください。
