Individual User Accounts

More from Scott K. Allen's pluralsight.com trainings: When starting a new ASP.NET Project in Visual Studio 2013 and picking "MVC" the "Change Authentication" button one may change the default away from "Individual User Accounts" to something else. The options are: No Authentication, Individual User Accounts, Organizational Accounts, and Windows Authentication. The first just lets everyone see every "page" as if for a vanity web site perhaps while the second is going to store user accounts in database tables not unlike the tables that worked with the goofy web forms login controls which were shoved down your throat with Visual Studio 2005. Twitter accounts and the like (Facebook, etc.) may also be used in this option. (Organizational Accounts is for Azure while Windows Authentication is of Active Directory.) It looks like the Individual User Accounts controls will just be set up when one spins up a new project. The _LoginPartial partial shows if you are logged in or baits you to log in based upon Request.IsAuthenticated. User.Identity.GetUserName() retrieves the username. A "ContentResult" as a return type is basically a string which may be returned from an MVC action. It can bubble up into a browser. Using the [Authorize] attribute on an MVC action (or Controller) will shut out anonymous users and just reroute them to the login view when then try to access something they should not. [AllowAnonymous] on an action will open up an action within a Controller decorated by [Authorize] to "the dumb public" so to speak. [Authorize(Users="tjaeschke")] and [Authorize(Roles="whatever, freaks")] are examples of restraining who may login. If you do the "Show All Files" trick in Solution Explorer you should be able to find an .mdf in "App_Data"which is where user accounts are being written to by default. Double-click it to see the tables in the "Server Explorer." A _MigrationHistory table is a giveaway that the process is using the Entity Framework. The DefaultConnection string in connectionStrings in the Web.config tells you where the database is found. Cookies are used in the login means. There may be some cookie caching nastiness when one is swapping databases. When you point the connectionString to a new database, Mr. Allen's training implies that the user tables will just be built out for you. Perhaps this is the Entity Framework code first stuff in action. The NuGet package Microsoft.AspNet.Identity.Core is installed by default with the Individual User Accounts thing and manages this stuff. User IUserStore to create, edit, and delete users. IUserPasswordStore inheirts/implements/subclasses IUserStore and lets you also set passwords and such. But, don't use IUserStore or IUserPasswordStore directly. Use the IDisposable type of "UserManager" as an API to interface with these interfaces. Or at least, Mr. Allen recommends that you don't use IUserStore or IUserPasswordStore directly. UserStore (which I suppose subclasses IUserStore in the default way-to-go) is of EntityFramework and need you to give it a DbContext.