Html – Do I need AJAX and ASP.NET for what I’m doing

For HTML 4, the answer is technically:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

HTML 5 is even more permissive, saying only that an id must contain at least one character and may not contain any space characters.

The id attribute is case sensitive in XHTML.

As a purely practical matter, you may want to avoid certain characters. Periods, colons and '#' have special meaning in CSS selectors, so you will have to escape those characters using a backslash in CSS or a double backslash in a selector string passed to jQuery. Think about how often you will have to escape a character in your stylesheets or code before you go crazy with periods and colons in ids.

For example, the HTML declaration <div id="first.name"></div> is valid. You can select that element in CSS as #first\.name and in jQuery like so: $('#first\\.name'). But if you forget the backslash, $('#first.name'), you will have a perfectly valid selector looking for an element with id first and also having class name. This is a bug that is easy to overlook. You might be happier in the long run choosing the id first-name (a hyphen rather than a period), instead.

You can simplify your development tasks by strictly sticking to a naming convention. For example, if you limit yourself entirely to lower-case characters and always separate words with either hyphens or underscores (but not both, pick one and never use the other), then you have an easy-to-remember pattern. You will never wonder "was it firstName or FirstName?" because you will always know that you should type first_name. Prefer camel case? Then limit yourself to that, no hyphens or underscores, and always, consistently use either upper-case or lower-case for the first character, don't mix them.

A now very obscure problem was that at least one browser, Netscape 6, incorrectly treated id attribute values as case-sensitive. That meant that if you had typed id="firstName" in your HTML (lower-case 'f') and #FirstName { color: red } in your CSS (upper-case 'F'), that buggy browser would have failed to set the element's color to red. At the time of this edit, April 2015, I hope you aren't being asked to support Netscape 6. Consider this a historical footnote.

Here's how I do it.

I decided to use IPrincipal instead of IIdentity because it means I don't have to implement both IIdentity and IPrincipal.

1. Create the interface

   interface ICustomPrincipal : IPrincipal
   {
       int Id { get; set; }
       string FirstName { get; set; }
       string LastName { get; set; }
   }
   

2. CustomPrincipal

   public class CustomPrincipal : ICustomPrincipal
   {
       public IIdentity Identity { get; private set; }
       public bool IsInRole(string role) { return false; }
   
       public CustomPrincipal(string email)
       {
           this.Identity = new GenericIdentity(email);
       }
   
       public int Id { get; set; }
       public string FirstName { get; set; }
       public string LastName { get; set; }
   }
   

3. CustomPrincipalSerializeModel - for serializing custom information into userdata field in FormsAuthenticationTicket object.

   public class CustomPrincipalSerializeModel
   {
       public int Id { get; set; }
       public string FirstName { get; set; }
       public string LastName { get; set; }
   }
   

4. LogIn method - setting up a cookie with custom information

   if (Membership.ValidateUser(viewModel.Email, viewModel.Password))
   {
       var user = userRepository.Users.Where(u => u.Email == viewModel.Email).First();
   
       CustomPrincipalSerializeModel serializeModel = new CustomPrincipalSerializeModel();
       serializeModel.Id = user.Id;
       serializeModel.FirstName = user.FirstName;
       serializeModel.LastName = user.LastName;
   
       JavaScriptSerializer serializer = new JavaScriptSerializer();
   
       string userData = serializer.Serialize(serializeModel);
   
       FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
                1,
                viewModel.Email,
                DateTime.Now,
                DateTime.Now.AddMinutes(15),
                false,
                userData);
   
       string encTicket = FormsAuthentication.Encrypt(authTicket);
       HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
       Response.Cookies.Add(faCookie);
   
       return RedirectToAction("Index", "Home");
   }
   

5. Global.asax.cs - Reading cookie and replacing HttpContext.User object, this is done by overriding PostAuthenticateRequest

   protected void Application_PostAuthenticateRequest(Object sender, EventArgs e)
   {
       HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];
   
       if (authCookie != null)
       {
           FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
   
           JavaScriptSerializer serializer = new JavaScriptSerializer();
   
           CustomPrincipalSerializeModel serializeModel = serializer.Deserialize<CustomPrincipalSerializeModel>(authTicket.UserData);
   
           CustomPrincipal newUser = new CustomPrincipal(authTicket.Name);
           newUser.Id = serializeModel.Id;
           newUser.FirstName = serializeModel.FirstName;
           newUser.LastName = serializeModel.LastName;
   
           HttpContext.Current.User = newUser;
       }
   }
   

6. Access in Razor views

   @((User as CustomPrincipal).Id)
   @((User as CustomPrincipal).FirstName)
   @((User as CustomPrincipal).LastName)
   

and in code:

    (User as CustomPrincipal).Id
    (User as CustomPrincipal).FirstName
    (User as CustomPrincipal).LastName

I think the code is self-explanatory. If it isn't, let me know.

Additionally to make the access even easier you can create a base controller and override the returned User object (HttpContext.User):

public class BaseController : Controller
{
    protected virtual new CustomPrincipal User
    {
        get { return HttpContext.User as CustomPrincipal; }
    }
}

and then, for each controller:

public class AccountController : BaseController
{
    // ...
}

which will allow you to access custom fields in code like this:

User.Id
User.FirstName
User.LastName

But this will not work inside views. For that you would need to create a custom WebViewPage implementation:

public abstract class BaseViewPage : WebViewPage
{
    public virtual new CustomPrincipal User
    {
        get { return base.User as CustomPrincipal; }
    }
}

public abstract class BaseViewPage<TModel> : WebViewPage<TModel>
{
    public virtual new CustomPrincipal User
    {
        get { return base.User as CustomPrincipal; }
    }
}

Make it a default page type in Views/web.config:

<pages pageBaseType="Your.Namespace.BaseViewPage">
  <namespaces>
    <add namespace="System.Web.Mvc" />
    <add namespace="System.Web.Mvc.Ajax" />
    <add namespace="System.Web.Mvc.Html" />
    <add namespace="System.Web.Routing" />
  </namespaces>
</pages>

and in views, you can access it like this:

@User.FirstName
@User.LastName