For now, check out my girlfriend’s new blog.  She’s the rabid bibliophile that is the inspiration for this whole project.

In order to setup your SQL Membership provider in your web.config, you first need to provide a connection string to the database holding your Membership information. Since, for this application, all providers reside in the same database, I have added a generic Providers connection string:

<add name="Providers" connectionString="Data Source=DEVLT01\SQLEXPRESS; Initial Catalog=Providers; Integrated Security=SSPI;" />

Now, under system.web, we want to add the membership node.  This node contains Membership providers (in this case, just one) and specified which of these providers is the default:

<membership defaultProvider="SqlMembershipProvider">
	<providers>
	  <add name="SqlMembershipProvider"
		   connectionStringName="Providers"
		   applicationName="hiddensanctum"
		   type="System.Web.Security.SqlMembershipProvider"
		   maxInvalidPasswordAttempts="5"
		   minRequiredNonalphanumericCharacters="0"
		   minRequiredPasswordLength="1"
		   passwordFormat="Hashed"
		   requiresQuestionAndAnswer="false"
		   requiresUniqueEmail="false" />
	</providers>
</membership>

The values I have in here will probably change as I determine the policies I will be using for passwords.  One thing I know is that I will want to remove a limit on the maximum number of invalid password attempts and instead add a CAPTCHA after a few invalid login attempts, much like Gmail does.  Another thing I know is that I don’t want passwords to be retrievable, so I set passwordFormat to Hashed.  Users will be able to reset their passwords, but they will not be able to recover them.

The final thing to do to setup your Membership provider is to set your application to use the provider as opposed to the default Windows authentication.  This can be done by changing your authentication mode to Forms:

<authentication mode="Forms" />

Now you’re set to actually use your Membership provider!

My usage begins in my PageBase class.  As I mentioned in my post about MasterPages, each page in this web application will derive from my PageBase class, which will provide universal, generic functionality.  First, let me show you the properties that I’m creating, then I will discuss them:

public bool UserIsLoggedIn
{
	get
	{
		return Context.User.Identity.IsAuthenticated;
	}
}

public bool CurrentUserIsTargetUser
{
	get
	{
		return string.IsNullOrEmpty(TargetUserName);
	}
}

public string CurrentUserName
{
	get
	{
		if (UserIsLoggedIn)
			return Context.User.Identity.Name;
		else
			return null;
	}
}

public string TargetUserName
{
	get
	{
		return Context.Items["UserName"] as string;
	}
}

MembershipUser currentUser = null;
public MembershipUser CurrentUser
{
	get
	{
		if (currentUser == null)
			currentUser = Membership.GetUser();

		return currentUser;
	}
}

MembershipUser targetUser = null;
public MembershipUser TargetUser
{
	get
	{
		if (targetUser == null && !CurrentUserIsTargetUser)
			targetUser = Membership.GetUser(TargetUserName);

		return targetUser;
	}
}

These properties provide the basics of handling users to all of my pages.  The first thing I want to point out is that I’m not using Membership everywhere; I’m only using it for getting the actual MembershipUser objects.  Elsewhere, I am using the Context to get the information that already resides there.   Context.User provides the user from a broader scope – any authentication – and is already there.  Membership, on the other hand, provides information only from the Membership provider and contains more information.  I am using this only where it is needed.  (Thanks to Pierreten and Thomas at stackoverflow for assisting me with figuring out the difference between Membership.GetUser() and Context.User.)

Since we have two user contexts to keep in mind, that of the current user and that of the user we are viewing (the target user), we are providing access to information about both of these.  You will also notice a CurrentUserIsTargetUser property – this allows us to check if we are viewing a different user or if we are defaulting to the current user for all viewing purposes.  Looking back on it now, I’m not sold on the name of this property, because I want this to be false if we are viewing our own information through a user context switch – this will allow the user to see their own information from the eyes of a friend.

Improving on our “page being served” example from my user context post, we can now do the following:

<% if (UserIsLoggedIn) { %>
	You are <%= CurrentUserName %>.
<% } else { %>
	You are a nonny mouse.
<% } %>

<% if (!CurrentUserIsTargetUser) { %>
	<br />
	You are looking for <%= TargetUserName %>.
<% } %>

I have a base MasterPage (Base.Master) in my root directory, and I will have at least one Nested MasterPage in each module (to include the root directory).  The base MasterPage will contain the bare basics – login functionality, a footer, and common links.  The base MasterPage provides three ContentPlaceHolders – one for the title, one for additional needs in the head of the page, and one for the main content:

<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Base.master.cs" Inherits="net.hiddensanctum.web.Base" %>

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

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>
        <asp:ContentPlaceHolder ID="cphTitle" runat="server" />
    </title>
    <asp:ContentPlaceHolder ID="cphHead" runat="server" />
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:ContentPlaceHolder ID="cphBody" runat="server" />
    </div>

    <div>
        © 2010 hiddensanctum.net
    </div>
    </form>
</body>
</html>

The Nested MasterPages will address site module-specific layouts as well as append a distinct string to the end of each Page title.  For example:

<%@ Master Language="C#" MasterPageFile="~/Base.Master" AutoEventWireup="true" CodeBehind="NestedLibrary.master.cs" Inherits="net.hiddensanctum.web.library.NestedLibrary" %>

<asp:Content ID="Content1" ContentPlaceHolderID="cphTitle" runat="server">
    <asp:ContentPlaceHolder ID="cphTitle" runat="server" /> - hiddensanctum.net library
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="cphHead" runat="server">
    <asp:ContentPlaceHolder ID="cphHead" runat="server" />
</asp:Content>

<asp:Content ID="Content3" ContentPlaceHolderID="cphBody" runat="server">
    <asp:ContentPlaceHolder ID="cphBody" runat="server" />
</asp:Content>

All of the values appended to the title will have ” – hiddensanctum.net” at the beginning.  It would be nice to be able to place this in the Base.Master, but the Base.Master title gets overridden when there is something from the Nested MasterPage going into the title.

MasterPages will focus solely on presentation – universal logic will be placed in a separate base class (PageBase) which I will cover as I go over Membership, Profiles, and Themes.

I’ve decided to use one database to hold all of the providers I plan on using:  Membership, Profile, Role, Session State.  I’ve made this decision because I don’t expect any of these to grow quickly – the fastest-growing table should be the one for Session State, and even that won’t be that fast (unless you sparse readers have a lot of friends) and can be cleared often with a job.  If they do end up growing too quickly, I will split them out.

I used aspnet_regsql to create the provider database, but I had to run two commands, because you can’t create a session state database while also creating the support for the other providers.  (They probably don’t want you to have them all in the same place.)

The command I used to create the Providers database with the Membership, Profile, and Role providers:

aspnet_regsql -S DEVLT01\SQLEXPRESS -E -A mrp -d Providers

The command I used to add the SQL Session State provider support to the Providers database:

aspnet_regsql -S DEVLT01\SQLEXPRESS -E -ssadd -sstype c -d Providers

At some point, I will script this database out and save the script to my solution – this will let me deploy scripts to other environments (once I’m at that point).  I may try to use the -sqlexportonly argument to see what scripts that generates.  I’ll let you know how it goes.

So, back to user contexts.  Because I want users to be able to link others directly to, say, a certain list of their library books, I need to be able to specify which user’s information a page should be displaying.  I could do it in the query string, but I think that’s a bit cheesy, so I wanted to avoid that.  I wanted to be able to pick up on users and applications through the path – so, for instance, http://hiddensanctum.net/megan.fox/library would serve up megan.fox’s library, while just http://hiddensanctum.net/library would serve up my own library (assuming I’m logged in).

The problem with the above example, though, is this:  if I go to http://hiddensanctum.net/megan.fox, I would reasonably expect to pull up megan.fox’s profile.  (This will seem less reasonably when I write a post about implementing it, but, for now, let’s assume that it’s a reasonable expectation.)  However, what if I go to http://hiddensanctum.net/library?  Would I expect to be brought to my library… or to the profile of a user named library?

In order to make this work, I need to identify users a bit more concretely.  The first idea that came to mind was to use the tilde that you see other places; for example, http://hiddensanctum.net/~megan.fox/library.  However, I don’t like how that looks, and it sort of gets away from the natural flow of a path, in my mind.  There’s an obvious break where the username is being emphasized.

The next idea was to use a period in place of the tilde; for example, http://hiddensanctum.net/.megan.fox/library.  However, that still breaks the flow – and, now that I’ve typed it out with a username that has a period in it, it looks even worse than the tilde option above.

Then I had it!  http://hiddensanctum.net/u/megan.fox/library.  That keeps with what I wanted, and I think it looks pretty good.  But how to implement it?

I ran the situation by a coworker of mine, Mike, and he pointed me to MVC as a possibility. However, having had some experience with MVP at work, I wanted to avoid MVC if I could.  I think the application is going to get pretty complicated already; I’d like to keep it as simple as possible where I can.  Maintainability is key.

However, I did do some poking around into MVC, and I came across something called Routing, which is how MVC actually creates and uses virtual paths.  I followed MSDN‘s How to: Use Routing with Web Forms, and, with some extra legwork, got what I think is a good solution.  I won’t go into the web.config changes made, as those are given step by step in the MSDN article, but the code I am using follows:

In my Global.asax, I am registering the user context route like so:

protected void RegisterRoutes(RouteCollection routes)
{
    // Change viewing context from current user to user specified by {UserName}
    routes.Add(
        new Route(
            "u/{UserName}/{*Path}",
            new UserRouteHandler()
        )
    );
}

This is called from the Application_Start method:

protected void Application_Start(object sender, EventArgs e)
{
    RegisterRoutes(RouteTable.Routes);
}

The registered route will handle only URLs of the form http://hiddensanctum.net/u/{username} and any sub-URLs.  So if you go to http://hiddensanctum.net/library, you will hit the library folder directly; however, if you go to http://hiddensanctum.net/u/megan.fox/library, the new RouteHandler will handle the request.

How is the request handled?  Let’s take a look:

public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
    // Get path variables from Routing
    string userName = requestContext.RouteData.Values["UserName"] as string;
    string path = requestContext.RouteData.Values["Path"] as string;

    // Assign "UserName" from Routing to the HttpContext
    requestContext.HttpContext.Items["UserName"] = userName.ToLower();

    // Fix path to ensure that a blank path end points to a Default.aspx page
    path = EnsurePathPointsToAspx(path);

    // Return a new instance of the requested path
    return BuildManager.CreateInstanceFromVirtualPath(
        path,
        typeof(Page)
    ) as IHttpHandler;
}

First, we get the username provided and the path the visitor is trying to reach.  We will assign the username into the context in order to pass it into the page we are creating.  Then we do some cleanup (see end of post) and create a new IHttpHandler of the actual page requested to return.  This will allow the page being requested to be served – and now it will have access to the username we added to the context.  Simple as that!  Now, in the page that is being served, we can do something like this:

<% if (string.IsNullOrEmpty(Context.Items["UserName"] as string)) { %>
    You are looking for your own information.
<% } else { %>
    You are looking for: <%= Context.Items["UserName"]%>.
<% } %>

Of course, once we have some content, this will be more sophisticated and driven through the code-behind, but this illustrates the point.

Now, some of you are wondering, “When is this incredibly long post going to end?”  And some few of you die-hard sparse readers are wondering, “Wait a second!  What’s that ‘cleanup’ bit you did there with the hand waving and the not telling us?”  Well, in answer to the first question – after I answer the second:

One of the things we unfortunately lose when we’re doing Routing this way is IIS’s assignment of a default page when a visitor requests a directory (such as http://hiddensanctum.net/library).  So my cleanup code just ensures that the path requested ends in an ASPX file:

///
/// Ensures that the given path ends with .aspx.
///
protected string EnsurePathPointsToAspx(string path)
{
    string result = path;

    // Ex.: The incoming url is /u/name/
    if (string.IsNullOrEmpty(result))
        result = DEFAULT_FILENAME;

    // Ex.: The incoming url is /u/name/library/
    else if (result.EndsWith("/"))
        result = string.Format("{0}{1}", result, DEFAULT_FILENAME);

    // Ex.: The incoming url is /u/name/library
    else if (!result.ToLower().EndsWith(".aspx"))
        result = string.Format("{0}/{1}", result, DEFAULT_FILENAME);

    return string.Format("~/{0}", result);
}

This could be more complicated, but it’s been left simple for now because I currently plan to put anything not an ASPX file under the App_Themes folder.  Whether or not this decision will pan out as development continues is yet to be seen, but I will post any updates I make if it doesn’t.

One thing you will notice about the above code is that there is no handling of query strings.  I originally had code to handle pages with query strings, but then I noted an odd behavior – even when there were query strings, they never showed up in the path that I got from my Routing.  Turns out, this is because the query strings are automatically stripped out and put into the Request; no handling is necessary.  (Of course, if you need it for your routing, you can access it through requestContext.HttpContext.Request.)

Tune in next time for Themes and Profiles!

While I’ve been sitting on the domain for a while, what sparked this effort was a promise to my girlfriend, a rabid bibliophile, that I would make her a tool through which she could track her books and interact with her book lists.  Toward that end, I have decided to create a base on top of which I can develop a number of modules (that number currently being one – the library module).  The base site will provide basic functionality such as membership, theming, and profiles.  The modules will provide their own functionality.

I decided to blog about the process for a number of reasons.  One, I plan to post code snippets that will likely help me out in the future – and will hopefully help others as well.  Two, I think it will be interesting to look back on the process and see what I’ve done and where it all went so horribly, horribly wrong.

As a note of warning, between working full time and working on my doctorate, this project is not my top priority, so the project and the blogging will probably be slow going.

I’d already made some headway on the application before deciding to start this, so I will be making a couple catch-up posts before continuing on with development.

Edit 3/28/10 8:07 PM: Oh yeah – this is all being done in ASP.NET with a C# code-behind and a SQL Server 2008 back-end.