Earlier this week I started a series on the old workhorse, .Net Membership that was introduced with ASP.NET 2.0 waaay back in 2005. Why drudge it up? Well, simply put, it is really useful and can save you a lot of development time. Also, it isn’t sexy so it doesn’t get a whole lotta press (like say…Ajax) so I figured this series could serve as a nice “reintroduction”.

The first part of the series introduced the functionality and explained how to set it up for your site. Today I am going to go deep and explain the LoginView control. This is definitely one of the more useful controls developed by Microsoft when it comes to user management and it bears a bit of time to look at it.

In addition to the basics of the control, I will also get into some of its “quirks” so you don’t beat your head against the wall in frustration the first time you use it.

LoginView this is the Reader…Reader meet the LoginView
As I mentioned earlier, the LoginView’s job is to show your site’s visitors only what you want them to see. It has basically three states: Anonymous, LoggedIn, and Roles.

The anonymous state is what people who have just arrived will see. No login required here. The LoggedIn state is exactly what it sounds like. It houses the controls you want to show your visitors after they have logged in. Finally, the Roles state shows its goodies only to those of a specific role.

So that is its purpose, now lets see how to use it.

The Basics
When you throw a LoginView onto your page it looks something like this:

<asp:LoginView ID="loginView" runat="server">
    <AnonymousTemplate>
        Welcome Mr. Anonymous
    </AnonymousTemplate>
    <LoggedInTemplate>
        Ooh, you are logged in
    </LoggedInTemplate>
    <RoleGroups>
       <asp:RoleGroup Roles="Role1, Role2">
           <ContentTemplate>
               Your are either a member of Role1 or Role2
           </ContentTemplate>
       </asp:RoleGroup>
       <asp:RoleGroup Roles="Role3">
           <ContentTemplate>
               You must be in Role3
           </ContentTemplate>
       </asp:RoleGroup>
   </RoleGroups>
</asp:LoginView>

Now obviously we are pretty stripped down here, but the basics are all there. Notice the example has all three states. You can pick and choose if you don’t need all three for some reason.

In the simple example here, if you aren’t logged in all you would see is “Hi Mr. Anonymous”. Everything else just simply won’t be there (even if you view source). The anonymous and loggedin templates are pretty plain vanilla so there really isn’t a need to delve into those. Notice though, the RoleGroups section. Inside are multiple “RoleGroup” elements. If you want to show a different section for 3 Roles, then you need three RoleGroup elements. However, if, like the example above, you want two of your Roles to see the same thing, you can do that simply by listing the Role names in a comma delimited list.

Since we are on the subject, lets talk about Roles in a bit more detail shall we?

Role, Role, Role your boat…man that is cheesy
Where do Roles come from? The easiest way to create them is to load up the Visual Studio “.NET Configuration” tool. With this you can create and manage roles with a few clicks. If you don’t want to use this tool, or you don’t have access to it, you can simply go to the aspnet_Roles table (this was created by the asp_reqsql.exe command I mentioned in part one) and add your records there. The only tricky part is creating your own Guids…

Same goes for assigning users to roles. Either use the configuration tool, or insert directly into the aspnet_UsersInRoles table.

Once you have Roles setup you can Roles .NET object on the server side. This is a handy dandy guy that gives you methods like GetRolesForUser(username), and IsUserInRole(username, rolename). Its pretty easy to get a handle on, especially since the roles that are passed around are the friendly names rather than the Guids.

Ok, so there is a bit about Roles, lets get back to the LoginView and talk about some of the funky stuff.

Time to get funky
While the LoginView is a pretty handy control, it does have its quirks. Namely accessing controls in the various states is more difficult than you might thing. If you have a textbox in the LoggedIn template, you can’t just go to the server side and access it like you would a normal control. The reason for this is that the controls in the various states are not loaded unless the state is shown on the screen. In other words, if you aren’t logged in, then the controls in the LoggedIn template simply do not exist and therefore cannot be accessed.

To get around this is easy once you get the hang of it, but it seems awfully cumbersome until you do. Here is an example. Say I have a textbox in my Loggedin template that I would like to change the text on. To access it would require code like this:

TextBox txt = (TextBox)logView.FindControl("txtExample");
if (txt != null)
    txt.Text= "changed";

In the example above “logView” is the ID of our LoginView control. We use the method FindControl on logView to get ahold of our textbox. If we are in a different state (i.e. Anonymous), then the control can’t be found and therefore our txt variable is null. If we are in the correct state, then we can change our text. Again, it isn’t difficult, but the first time you use this control it can be really frustrated if you don’t know what to expect.

Another bit of funkiness are the events associated with the LoginView, specifically the ViewChanged and the ViewChanging events. For the life of me, I cannot get these things to fire. I may just be stupid, but I have used this control many times and I have signed up for both of these events and they never get triggered. I am not sure why, or what their purpose is, but they are pretty useless from what I can tell. If you can get these things to fire, please let me know what I am doing wrong. However, if you are like me, then you will just get used to ignoring them.

So there you have it…the LoginView control. It can really save you a lot of time, and it is definitely one of the more useful controls that MS has provided as part of the Membership functionality. So give it a try and let me know if you get those events to work!

The next part of this series will go over a couple more of the controls and explain the Profile object.