You can use the security information you learned about in the sidebar, "Use Forms Authentication Events," to set up levels of access for your system. In this example, you can assign users to roles within a system. Each role allows a user to do different things; for example, you could have Guest, User, and Admin roles for your application. Guests would only be able to read information, users would be able to use the application fully, and administrators could use a secured section of the application that allows assigning users to roles.

You can implement this role-based security easily (assuming this information is available in your user security database). For this example's purposes, assume you've modified your SecurityUser object to add a property called Role. This property is available to you after a successful authentication. As a result, you can use its value because you cached off the entire object as part of a Session variable in the original login ASPX page after a successful authentication.

Once that information is available to your application, you can display or hide information (such as menus or secure information) dynamically in any future page in your application, based upon the role information stored during the initial login process. You can also access the current user's identity information using the Identity object, which implements the FormsIdentity class when you're using forms authentication. This eliminates the need for you to store the authenticated user's name in a Session variable, because you can always access it with the User.Identity.Name property. This class also has two other read-only properties named IsAuthenticated and AuthenticationType.

Now that you have a user logged in to your application, you might want to give the user the option to log out in the current browser session. This can be useful if you want to provide the ability for users to log in and out as different users. Use the SignOut method like this:

MobileFormsAuthentication.SignOut()

This method calls the base FormsAuthentication.SignOut method, which removes the session cookie. It then sets the value of PersistCookielessData to False, which tells ASP.NET not to persist the cookie information as part of the querystring. From there, you can redirect the user manually back to the login page (a common technique) using the MobilePage.RedirectToMobilePage method (note that using the Response.Redirect isn't supported for mobile ASP.NET applications, so using this method is required to redirect manually to another mobile ASP.NET page).

A standard technique for developing Web applications is to provide both a full Web client and mobile client using the same base URL with different subdirectories. You might want to mix these modes so you can create a single Web project with multiple subdirectories: one for full browser clients, and another for mobile browser clients. Each subdirectory would have its own unique Login page, customized to either a full or mobile browser. At the application's root, you could put all your classes that are common to the application itself. Then, in each subdirectory, you'd put only the ASPX files (the client UI), providing the recommended separation of business logic from presentation logic.