Joshua Arnold

This is the third post in a series of entries that I am using to describe the architecture used in my most recent social networking project. While some of the architecture is omitted from these discussions, I would like to share some of the tricks that my team used to decrease development time and meet the rough and ambitious deadlines that were placed upon us. This entry will continue the discussion on web controls with an emphasis on distinguishing between server and user controls.

During the domain modeling phase of the application, we noticed that Comments were utilized by several different areas of the application:

The first piece of the application to utilize the control was the User profile. As mentioned in the previous post, we constructed useful server controls to facilitate a consistent layout throughout the application. Using one of these controls, the LayoutModule, we constructed what we referred to as a CommentContainer to display comments.

As we expanded the functionality of the control, we realized we needed/wanted two things:

1. AJAX comment posting, deleting
2. Pagination

In order to allow for this functionality, we needed to abstract out the functionality that was required using a variation of the Bridge pattern:

Note: The CommentProvider is an extension of a generic EntityProvider that is used to define the general functionality shared by all of the controls that utilize this pattern.

After the CommentContainer and CommentProvider were finalized, adding comment functionality for additional pages was a piece of cake and the code is very easy to maintain.

This is the second post in a series of entries that I am using to describe the architecture used in my most recent social networking project. While some of the architecture is omitted from these discussions, I would like to share some of the tricks that my team used to decrease development time and meet the rough and ambitious deadlines that were placed upon us. This entry will continue the discussion on role-based security but it will focus on creating role-based web controls.

First, I will discuss the design of the commonly used controls. The layout of the application consistently made use of a Cascading Style Sheet (CSS) class named “module”. This was essentially a tabbed container with varying content that was used consistently throughout our mockups. The other variation of this style was a similar construct without the tabs. This spawned two controls that became the basis of the site:

• LayoutModule
• TablessModule

These controls use a template container approach to ensure that the proper classes are used but allow for complete customization of the inner content. The following is an example using the TablessModule:

<rr:TablessModule ID="contactModule" runat="server">
	<HeaderTemplate>
		<h2>
			Company Information</h2>
		<hr />
	</HeaderTemplate>
	<ContentTemplate>
		<p>Content here</p>
	</ContentTemplate>
</rr:TablessModule>

After creating the skeleton structure of the majority of our pages, we began to observe a pattern: we were showing/hiding controls based on roles that the principal user belonged to. This then spawned a series of controls which utilized the notion of “AllowedRoles” and “DeniedRoles” which then controlled their visibility.

Consider the following helper method:

/// <summary>
/// Parses the specifed <see cref="System.String"/> values into a comma separated
/// list of values.
/// </summary>
/// <param name="values"></param>
/// <returns></returns>
public static string GetCommaSeparatedString(params string[] values)
{
	if (values == null || values.Length == 0)
	{
		return String.Empty;
	}

	StringBuilder retVal = new StringBuilder();
	int last = values.Length - 1;
	for (int i = 0; i < values.Length; ++i)
	{
		retVal.Append(values[i]);
		if (i != last)
		{
			retVal.Append(",");
		}
	}
	return retVal.ToString();
}

Given a TablessModule “userInfoModule”, consider the following example:

userInfoModule.AllowedRoles = SiteUtil.GetCommaSeparatedString(SiteRoles.User);
userInfoModule.DeniedRoles= SiteUtil.GetCommaSeparatedString(SiteRoles.Friend);

This is especially helpful for profile links that are useful for other users viewing your profile. We don’t want to display links like “Send a Message” when you’re looking at yourself. The example above grants Users in the Role ‘User’ to view the module and explicitly denies access to Users in the Role ‘Self’. A simple translation would be:

Given some TablessModule containing information for some User x, some User y may view that TablessModule if that User y is in the Role ‘User’ and that User y is not that User x.

Once again, this was another step towards readability and simplicity for business-rule implementation. Stating the allowed and denied roles in code is easily understandable, in my opinion. This concludes the role-based web control section of this discussion.

Next up: Reusable user controls

This is the first post in a series of entries that I will use to describe the architecture used in my most recent social networking project. I will discuss the thought processes surrounding each major design decision and explain how the design of the application has helped my team reach the very rough and ambitious deadlines that were placed upon us. This entry will focus on leveraging role-based security and how business rules can easily be written using this approach.

After the information modeling phase of the application was complete, I felt it necessary to focus on the rules that will govern the application’s privacy settings and overall user experience. Given the nature of the application, privacy settings were going to be a large part of every operation that we did so it was important that these rules were clearly defined in a central location. While establishing these rules, we realized that the majority of the rules could be define via roles. Let’s take a look at one rule and observe the evolution as we moved towards a role-based approach.

First iteration:

Some User x may create a Comment for some User y’s profile if at least one of the following is true:

1. y is equal to x
2. x is a friend of y

Role-based version:

Some User x may create a Comment for some User y’s profile if at least one of the following is true:

1. y is in the role ‘Self’
2. x is in the role ‘Friend’

This isn’t a huge evolution by any means but it introduces artificial roles that the application must be made aware of. It was time to design a solution that could utilize these artificial roles. The first step was to clearly establish the URL patterns used throughout the application. These URLs represent the very base structure - that is, the URLs that are used underneath any URL rewriting. For the purpose of this article, let’s take a look at a user’s profile page URL:

~/Users/Profile.aspx?UserId=x

For the majority of the projects that I’ve worked on in the past, the validation of these rules would occur by making a call to the business layer in the code behind file of the page. This may work for a variety of cases, but I was beginning to find the restrictions of validating these rules at such a late part in the request lifecycle (e.g. location restriction using roles, role aware controls). To overcome this restriction, we introduced the a series of role-based management HttpModules. Knowing the URL structure, we could rest assured that the “UserId” query string parameter will be present for any User-based viewing action (this was placed in a configuration manager to prevent any potential typos). If the UserId parameter is present, then we can execute a custom stored procedure to retrieve a value that indicates the artificial roles that user belongs to and add the principal user to them.

The code to handle these rules was then pulled into a series of ‘RuleValidator’ classes that were code-based representations of the business rules. The aforementioned rule could be represented in code with the following statement:

/// <summary>
/// Returns a flag indicating the result of rule R102:
///
/// Some User x may create a Comment on some User y's profile if at least one
/// of the following are true:
///
/// <list type="bullet">
/// <item>y is equal to x</item>
/// <item>x is in the role 'Friend'</item>
/// </list>
/// </summary>
/// <param name="pCurrentProfile">The <see cref="UserDetail"/> currently being viewed.</param>
/// <returns></returns>
/// <exception cref="ArgumentNullException"><paramref name="pCurrentProfile"/> was null.</exception>
public static bool IsAuthorizedToCreateComment(UserDetail pCurrentProfile)
{
    if (pCurrentProfile == null)
    {
        throw new ArgumentNullException("pCurrentProfile");
    }
    IPrincipal _user = HttpContext.Current.User;
    return (_user.IsInRole(SiteRoles.Self) || _user.IsInRole(SiteRoles.Friend));
}

After the initial pattern was created for the role-based manager modules (abstracted out into a base role manager class), it was a piece of cake to implement them for the rest of the application modules (e.g. groups, events, photos). That concludes the role-based injection section of the architecture.

Next up: Role-based web controls.