AngularJS Training

Tuesday, January 21, 2014 by K. Scott Allen
4 comments

UPDATE: The next public class will be the week of September 8th in Oslo, Norway.  

UPDATE 2: AngularJS: Get Started is now available to Pluralsight subscribers. This course is a small but focused subset of the full class. 

At the end of last year I put together and taught a 2 day workshop on AngularJS fundamentals at NDC London, which due to popular demand I’m offering as part of a larger class for ProgramUtvikling.  Feel free to contact me if you would like an on-site workshop, although my bandwidth for custom training is scarce.

AngularJS Fundamentals

From animations to testing and everything in between, this course covers the features of AngularJS with a focus on practical scenarios and real applications. We will see how to build custom services, directives, filters, and controllers while maintaining a separation of concerns with clean JavaScript code. Hands on labs will reinforce concepts.

The outline of topics:

  1. Introduction
  2. Modules and Controllers
  3. Views and Templates
  4. Services
  5. Directives
  6. Testing
  7. Routing
  8. UI and Animation

Some  of the material is based on blog posts here on OTC.

Implementing ASP.NET Identity

Monday, January 20, 2014 by K. Scott Allen
5 comments

In previous posts (listed below), we saw how the UserManager class in ASP.NET Identity provides the domain logic for an identity and membership system. Your software makes calls into a UserManager object to register and login users, and the UserManager will then call into a UserStore object to persist and retrieve data. 

Microsoft’s UserStore class uses the Entity Framework for persistence. If you don’t like or can’t use Microsoft’s UserStore class, then implementing the storage interfaces for ASP.NET identity is easy.

The goal of a custom storage class is to provide the basic CRUD operations required by the features your application needs. Since the storage features are factored into granular interfaces, your storage class can pick and choose the interfaces it needs to implement.

Here are the current interfaces you can choose from.

IUserStore<TUser, TKey>

The one required interface in the identity system is IUserStore. In the 2.0 alpha release, a TKey generic parameter allows you to specify the type of the identifier / primary key for a user, which was assumed to be a string in v1.0. This interface has 5 simple CRUD requirements:

  • Create a user
  • Update an existing user
  • Delete a user
  • Find a user by ID
  • Find a user by username

These methods each require < 10 lines of code, and the count of 10 includes checks for valid parameters and premature disposal. Each method only needs to forward data to a data framework or existing API. For example, a simple implementation of CreateAsync with the Entity Framework might look like the following (where _users is a DbSet<TUser>).

public Task CreateAsync(User user)
{
    user.Id = Guid.NewGuid();
    _users.Add(user);
    return _db.SaveChangesAsync();
}

And with MongoDB, users would probably be stored in a MongoCollection:

public Task CreateAsync(User user)
{
    user.Id = ObjectId.GenerateNewId();
    _db.Users.Insert(user);
    return Task.FromResult(0);
}

All other interfaces derive from IUserStore and add additional functionality. The following interfaces also take TUser and TKey generic type arguments. The generic arguments are omitted from the headings for aesthetic reasons.

IUserPasswordStore

Implement this interface in your custom user store if you want to store users with local hashed passwords. The interface will force you to implement methods to:

  • Get a user’s password
  • Set a user’s password
  • Check if a user has a password

IUserLoginStore

Implement this interface if you want to store 3rd party user logins, like logins from Twitter, Facebook, Google, and Microsoft. Again, the interface only requires some simple CRUD operations.

  • Add a login for a user
  • Find a user given their login data
  • Get all logins for a user
  • Remove a login for a user

IUserClaimStore

Manage System.Security.Claim information for users with three simple methods.

  • Get all claims for a user
  • Add a claim to a user
  • Remove a claim from a user

IUserRoleStore and IRoleStore

Implement IUserRoleStore if you want to associate roles with each user. There are a total of 4 methods required.

  • Add a user to a role
  • Get all the roles for a user
  • Check is a user is in a specific role
  • Remove a user from a role

The IRoleStore interface, like IUserStore, is a storage API with CRUD operations for role management. You’ll want to implement this interface and pass it to the ASP.NET Identity RoleManager.

IUserStore goes with UserManager; IRoleStore goes with RoleManager.

The IRoleStore interface requires 4 operations. 

  • Create a role
  • Delete a role
  • Update a role
  • Find a role by ID or name

IUserSecurityStampStore

The security stamp is best explained in a stackoverflow.com answer from team member Hao King.

… this is basically meant to represent the current snapshot of your user's credentials. So if nothing changes, the stamp will stay the same. But if the user's password is changed, or a login is removed (unlink your google/fb account), the stamp will change. This is needed for things like automatically signing users/rejecting old cookies when this occurs, which is a feature that's coming …

The interface requires only two methods.

  • Get the security stamp for a user
  • Set the security stamp for a user

IUserEmailStore and IUserConfirmationStore

New in Identity 2.0 are the abilities to confirm users via a token and allow for users to reset their password. To offer both features you’ll want these 2 interfaces. When combined they require the following operations. 

  • Find a user by email address
  • Get a user’s email address
  • Set a user’s email address
  • Check if a user is confirmed
  • Set a user’s confirmation flag

IUser*Store Interfaces and UserManager

When you create a new instance of a UserManager you pass in an object implementing at least IUserStore and 0 or more of the other IUser*Store interfaces. If you ask the user manager to do something that isn’t supported (like by calling FindByEmailAsync when your custom user store doesn’t support IUserEmailStore), the manager object throws an exception.

Working Implementations

There are a few OSS projects out there already providing IUser*Store implementations with various storage mechanisms. You can NuGet these implementations into a project, or peruse the source to get an idea of how to implement a custom user store.

Tugberk Ugurlu has an implementation for RavenDB: AspNet.Identity.RavenDB 

Daniel Wertheim has an implementation for CouchDB / Cloudant

SoftFluent has an implementation for CodeFluent Entities

InspectorIT has an implementation for MongoDB: MongoDB.AspNet.Identity

Stuart Leeks just published a store using Azure Table Storage: AspNet.Identity.TableStorage

ILMServices has an implementation for RavenDB, too: RavenDB.AspNet.Identity

Antônio Milesi Bastos has built a user store using NHibernate: NHibernate.AspNet.Identity

Bombsquad AB provides a user store for Elastic Search: Elastic Identity

aminjam built a user store on top of Redis: Redis.AspNet.Identity

cbfrank has provided T4 Templates to generate EF code for a “database first” user store: AspNet.Identity.EntityFramework

Previous Posts

Meet The AngularJS Injector

Monday, January 13, 2014 by K. Scott Allen
0 comments

Most of us never see the $injector service in Angular until there is a problem with dependencies, at which point we’ll see an error message like the following.

Uncaught Error: [$injector:unpr] Unknown provider: someServiceProvider <- someService

It is the Angular $injector that knows how to invoke functions by analyzing their dependencies and passing the correct parameters by fetching the proper service instances. Angular creates a single $injector when it bootstraps an application and uses the single $injector to invoke controller functions, service functions, filter functions, and any other function that might need dependencies as parameters.

The above error would occur if a function asks for a service named “someService”, but “someService” is not a service the injector knows about (because, perhaps, the service wasn’t registered correctly).

You can use the $injector service, like any service, just by asking for the $injector by name.

var someFunction = function($rootScope, $http) {
    return "called!";
};

app.run(function($rootScope, $injector) {

    $rootScope.annotations = $injector.annotate(someFunction);
    $rootScope.message = $injector.invoke(someFunction);

});

The above code demonstrates two capabilities of the $injector.

1. You can use the annotate API to discover the dependency annotations for an injectable function (the above code would list “$rootScope” and “$http” as annotations).

2. You can use the invoke API to execute an injectable function and have the $injector pass in the proper services.

Manual Injection

In some cases you might find it useful to create your own $injector instead of using the injector created by Angular during application startup. As an example, creating your own injector is useful in unit tests where you do not want singleton service instances. You can create your own injector using the angular.injector method.

var injector = angular.injector(["ng"]);

var someFunction = function($http) {
        // ...
};

injector.invoke(someFunction);

You must pass a list of the modules the injector will work with (just the core “ng” module in the above code). You have to explicitly list the ng module if you are going to use any services from the core of Angular. Unlike the angular.module method, which assumes you have a dependency on the ng module and will silently add “ng” to your list of dependencies, the injector function makes no assumptions about dependent modules.

Customization Options With ASP.NET Identity

Thursday, January 9, 2014 by K. Scott Allen
6 comments

Identity and membership systems are difficult to implement because there is such a wide variety of business needs and technology requirements for these systems. Out of the box solutions for identity management will never make everyone happy and are guaranteed to make somebody angry.angry identity bird

Here are a few thoughts, pointers, and links revolving around customization options with the new ASP.NET Identity features.

But first, previous posts in this series:

1. For New Applications

The sweet spot for ASP.NET Identity is a greenfield application with minimal architectural constraints. If you are comfortable taking a dependency on the Entity Framework and aren’t trying to apply domain driven design to a complex problem space, the Identity framework is a quick approach to storing usernames, passwords, and logins.

By deriving from IdentityUser you can store custom profile properties per user. By deriving from IdentityDbContext you can add relationships between members and other data in a system.

2. For Existing Applications

Migrating existing applications to use the Identify framework is a bit trickier. You’ll need to provide some custom mapping for EF to work with an exiting schema, and also manage hashed passwords in a way that the Identity password hasher understands (which is extensible through an IPasswordHasher typed property on the UserManager class. Recently, a few articles appeared to help with this scenario:

The Identity framework doesn’t yet include all of the features of the previous membership frameworks, so you should perform a gap analysis before heading in this direction.

3. Using Identity 2.0 (And Integer Keys)

Based on feedback from the first release of the Identity framework, there is already a prerelease of Identity 2.0. Most notable in this release is the addition of an IUser<TKey> type, where TKey is the type of the primary key / identifier for a user. IUser<TKey> is useful for anyone who doesn’t like the default string type for a primary key. More information is available in the blog post Announcing preview of Microsoft.AspNet.Identity 2.0.0-alpha1, where you can also see the following improvements.

  • Account confirmation
  • Password Reset
  • Security Token Provider
  • Better Katana Integration
  • And more….

4. Ripping Things Apart

There are a number of good reasons to use the Identity framework’s UserManager class while implementing your own user store persistence logic.

For starters, implementing your own persistence logic in a scenario where you just need users with passwords, but not roles, claims, or 3rd party logins, is relatively straightforward. The UserManager can work with a class only implementing IUserStore and IUserPasswordStore, which require a total of 8 CRUD type methods. Following this path has a few benefits.

  • You don’t need to take a dependency on the Entity Framework in the assembly where you define a user
  • In fact, you don’t need the Entity Framework at all
  • The only constraint on a user is to implement IUser, which requires Id and UserName properties

The next post in this series will look at building a custom user store both with a relational and non-relational database.

5. Other Links and Ideas

Brock Allen’s analysis:  The good, the bad and the ugly of ASP.NET Identity

Khalid Abuhakmeh’s analysis: ASP.NET MVC 5 Authentication Breakdown and ASP.NET MVC 5 Authentication Breakdown : Part Deux

A database project template from Konstantin Tarkus to work with Identity in a DB first approach: ASP.NET Identity Database

A customization article by John Atten: Code-First Migration and Extending Identity Accounts in ASP.NET MVC 5 and Visual Studio 2013

6. Alternatives

Brock Allen’s Membership Reboot

Thinktecture’s IdentityServer 2

Experimenting with Forms and AngularJS

Monday, January 6, 2014 by K. Scott Allen
3 comments

The directives and controllers that AngularJS automatically associates with <form> and <input> elements offer quite a bit of functionality that is not apparent until you dig into the source code and experiment.

For example, in this plunkr I’ve created a simple HTML form with two inputs.

 <div ng-controller="registerController">
     
    <form name="registerForm" ng-submit="register()">
        
        <input name="username" type="text" placeholder="Username" 
               ng-model="username" required ng-minlength="3" />
        <input name="password" type="password" placeholder="Password" 
               ng-model="password" required />
        <input type="submit" ng-disabled="registerForm.$invalid"/>
            
        <div>{{message}}</div>
        <pre>{{ registerForm | alljson }}</pre>        
    </form>

</div>

Notice the form has a name. Giving a form a name means Angular will automatically associate the form with registerController’s $scope object. The associated property will have the same name as the form (registerForm) and contain information about input values, clean and dirty flags, as well as valid and invalid flags.

The plunkr will dump out the data available about the form using an alljson filter, defined below. I’m using a custom filter because the built-in Angular json purposefully ignores object attributes that start with $ (like $invalid).

app.filter("alljson", function() {
    return function(o) {
        return JSON.stringify(o, null, 4);
    };
});

The output will look like the following (some information omitted for brevity).

{
    "$name": "registerForm",
    "$dirty": true,
    "$pristine": false,
    "$valid": true,
    "$invalid": false,
    "username": {
        "$viewValue": "sallen",
        "$modelValue": "sallen",
        "$pristine": false,
        "$dirty": true,
        "$valid": true,
        "$invalid": false,
        "$name": "username",
        "$error": {
            "required": false,
            "minlength": false
        }
    },
    "password": {
        "$viewValue": "123",
        "$modelValue": "123",
        "$pristine": false,
        "$dirty": true,
        "$valid": true,
        "$invalid": false,
        "$name": "password",
        "$error": {
            "required": false
        }
    }
}

In addition to managing properties, Angular manipulates CSS classes in the DOM and provides extensibility points with model formatters and parsers,  We’ll look at these features in a future post.

ASP.NET Identity with the Entity Framework

Friday, January 3, 2014 by K. Scott Allen
16 comments

ASP.NET EF Identity In a previous post  (Core Identity), we saw how the .Core identity assembly provides interfaces for describing the data access needs of a membership and identity system. Core also provides a UserManager class with the domain logic for identity management.

The .EntityFramework identity assembly provides concrete implementations for the core interfaces.

Here are 5 things to know about how it all works together.

In A New MVC 5 Application

If you use File –> New Project to create an MVC 5 application with the “Individual User Accounts” security option, the new project template will spit out all the code needed for users to register, login, and logoff, with all information stored into a SQL Server database.

The new identity bits do not support some of the features included with membership providers in the years past, features like counting invalid login attempts and lockouts, but the extensibility is in place and the current implementation has some clean separations, so perhaps they’ll be in by default in the future.

Remember the UserManager is the domain logic, and the UserManager needs (at a minimum) an IUserPasswordStore to persist users and passwords. Thus, the way the default AccountController constructs a UserManager is by passing in a new UserStore, which implements IUserPasswordStore in addition to the other core identity interfaces for persisting claims, roles, and 3rd party logins.

new UserManager<ApplicationUser>(
    new UserStore<ApplicationUser>(
        new ApplicationDbContext()))

It turns out that UserStore also has a dependency, a dependency on an EF DbContext class, and not just any context but one that derives from IdentityDbContext. IdentityDbContext provides all of the EF code-first mapping and DbSet properties needed to manage the identity tables in SQL Server. The default “new project” code provides an ApplicationDbContext that derives from IdentityDbContext with the idea that you’ll add your own DbSet properties for the entities, tables, and overall data that your application needs and keep everything in the same database.

In short, an identity specific DbContext plugs into the concrete user store, which then plugs into the user manager.

Once all three are together you have an identity system that supports third party logins as well as local accounts.

In A New Web API or SPA Application

The WebAPI and Single Page Application project templates also support user registration and password logins, but in these templates the AccountController is an API controller that issues authentication tokens instead of authentication cookies. Because the identity management work happens inside both the AccountController and inside Katana middleware, a UserManager factory is responsible for creating the user manager that both the middleware and API controller share.

public static Func<UserManager<IdentityUser>> UserManagerFactory { get; set; }

This static property is in the Startup.Auth.cs file that holds the Katana Startup configuration class. The actual factory function is initialized in this class, also.

UserManagerFactory = () => new UserManager<IdentityUser>(new UserStore<IdentityUser>());

This code uses the default constructor for the UserStore class, which will create a new instance of an IdentityDbContext object since an object isn’t supplied. If you want to use your own IdentityDbContext derived class, like the MVC 5 project does, you can modify the above initialization code and pass in your own context.

Side note: the SPA application template produces more than 2700 lines of code to get started. Not a large amount, but there are structural design issues (like the static UserManagerFactory) that require a healthy amount of rework for real applications. My personal advice is to use the template to get some ideas, but throw the code away and start from scratch for production applications.

Connection Strings

By default, IdentityDbContext uses a connection string named “DefaultConnection”, and all the new project templates will include a DefaultConnection connection string in the project’s web.config file. The connection string points to a SQL Local DB database in the AppData folder.

To change the SQL Server database being used, you can change the value of the connection string in web.config. You can also pass a different connection string name into the DB context constructor.

The Easy Customizations

A new MVC 5 project (not the SPA or WebAPI templates) provides an IdentityModels.cs file with the following two classes.

public class ApplicationUser : IdentityUser
{
}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection")
    {

    }
}

Remember ApplicationDbContext is the context used to initialize a UserStore for a UserManager. The context will already include Users and Roles properties it inherits from IdentityDbContext, but you can add additional properties to store movies, books, accounts, employees, or whatever an application needs to solve a problem.

The ApplicationUser class includes Id, Username, PasswordHash, and other properties it inherits from IdentityUser. You can add additional properties here to store additional profile information about a user.

For simple applications this all works well, but for more complex applications you again probably want to use the starting project template code only for inspiration and start your own implementation from scratch. The names, structure, and code organization all have a prototype code feel and aren’t production ready.

Managing Contexts

In a real application you’ll have to decide if you want to mingle your data context with IdentityDbContext. One issue to be aware of is that the UserStore class does not play well when using the unit of work design pattern. Specifically, the UserStore invokes SaveChanges in nearly every method call by default, which makes it easy to prematurely commit a unit of work. To change this behavior, change the AutoSaveChanges flag on the UserStore

var store = new UserStore<ApplicationUser>(new ApplicationDbContext());
store.AutoSaveChanges = false;

What’s Next

The new Identity system is easy for greenfield projects with no existing users, but quite a bit trickier if you have an existing schema or don’t use the Entity Framework. Fortunately, the separation of domain logic in the UserManager and persistence logic behind IUserStore and friends is a fairly clean separation, so it is relatively easy to implement a custom persistence layer. This is one of the topics we’ll cover in a future post.

Ten Years Of OdeToCode.com

Thursday, January 2, 2014 by K. Scott Allen
10 comments

The first article appeared here in December 2003, and just kept coming.

Quand on n'avance pas, on recule.

by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!