Rick Strahl's Web Log

A first look at SignalR

Rick Strahl — Wed, 22 May 2013 12:23:42 GMT

SignalR is the latest in a long string of new technologies pouring out from the ASP.NET team recently, when Microsoft rolled out version 1.0 of SignalR when Visual Studio Update 2 was announced. In a nutshell, SignalR is technology for .NET that allows you to build real time, connected Web applications. Connected in the sense that you can build Web applications that can send and receive and broadcast data in real time. The canonical example of a 'connected' application is a chat application where a client can broadcast messages to all other connected clients. While that's pretty cool in and of itself, that only begins to scratch the surface of what's possible with SignalR as you can communicate in a wide variety of ways between client and server and between all clients to push data around.

Go ahead - Push Me Around!

The idea behind SignalR and other tools like it (like the socket.io or now.js JavaScript libraries) is that you can push data from client to server, from server to client and even from client to client, all in real time without having to poll or check for new data at specified intervals. Callback driven interfaces on both client and server receive pushed messages immediately. The key word here is push - servers and clients can push data at any time and the other end of the connection sees the updated data immediately. It's pretty cool to watch an application, where one browser client updates a value in a text field and all other instances that are connected see that same change at the same time. Or having a server push a notification message down, and having all browsers immediately update to see the new data.

This sort of thing used to be the domain of connected TCP/IP services and peer to peer servers, but SignalR makes all of this available using standard Web protocols, using the HTTP protocol and port 80 or any other HTTP port and with .NET services on the server side. Behind the scenes SignalR combines the use of various connection protocols from WebSockets, to Long Polling to plain AJAX callbacks when all else fails, to bridge the compatibility gap between what modern browsers support and what you can do with legacy browsers. If you want to see all of these techniques highlighted along with a older preview of SignalR, there's a great conference session by Steve Sanderson on Channel 9 that discusses the various Async messaging approaches.

The key feature here is that SignalR's server maintains a persistent connection - abstracted over WebSockets/LongPolling/Ajax depending on what's available on the browser - to the client. So while with AJAX we could always push data to the server, but the server could never push data to the client, with SignalR you can push data both from client to server and from server to client. In order to broadcast messages from one client to all other clients you can callback to the server which can then broadcast a message to all or selected connected clients.

SignalR Server and Client Components

SignalR abstracts these various protocols and allows a seamless experience regardless of what the client supports. Additionally SignalR provides a very easy to use .NET server side framework for creating the backend services that either push data directly or broadcast data in bulk to many clients. SignalR includes the concept of Hubs which use simple methods in a .NET class as endpoints, as well as a lower level Connection interface that allows for streaming and low level access for the data that is both sent and received. SignalR then also provides rich client libraries for JavaScript, full .NET, Win8, Silverlight and a host of other clients to easily connect to either Hubs or Connections on the server, using an easy to use dynamic mapping model that is very flexible and easy to use. It's surprisingly easy to create SignalR services and consume them, both in Web and non-Web applications.

One of the cool things about SignalR is that you can also easily self host a SignalR server. A typical SignalR server application hosts in ASP.NET and is totally transparent and easy to run as part of the ASP.NET stack. However, you can also host SignalR in a self-hosted application, using an OWIN server host that can bootstrap SignalR and make it available in Console applications, Services or even full blown desktop applications. I recently built a monitoring service application that is running as a Windows Service and was able to use SignalR to efficiently push notification messages to a Web Browser based front end interface, pushing over 50 messages a second to several connected clients in real time. The possibilities this opens up really can't be overstated.

Signal What? A small real World Use Case

When I first heard about SignalR about a year and a half ago, the first thing that came to my mind was: "Yeah that's nice, but it's not a common scenario to have truly connected Web applications." The first thing that springs to mind are chat applications, messaging popups or continuous tickers of updating data pushed down to clients. That demo's nicely and is impressive to see, but it's not exactly a very common use case.

However, recently I had a chance to put SignalR to use in a real application with a scenario that's a little bit different. Specifically we needed a way to connect a standalone Windows Service application to a Web browser clients to provide real time updates. This project involved a queue service application running as a Windows Service with a Web front end that can monitor and manipulate the queue's operation using any browser.

The specific UI use case was to replace an old and ugly Windows Forms user interface that had to run on the physical server to monitor the real time queue activity and manipulate the queue application settings. With SignalR we were able to move this app to a real time, Web browser based interface.

There are a several important pieces that SignalR provided and made possible for this project:

The ability to have a Windows Service push real time messages to a Web browser
The ability for many Web browser clients to be connected
The ability for many users to modify settings on the Web browser user interface and
reflect those changes immediately for other browser users

While the application created for this is not very complex it did highlight these various different scenarios of sending messages that you can use with SignalR:

Sending messages from the server to all clients (message list display)
Sending two-way messages from one client to the server (updates - like AJAX calls but using SignalR)
Sending messages from the server a specific caller (individual status updates)
Sending messages from a single browser instance to all browsers (Updating the global queue settings or stopping the service)

The interface for this application is basically a list type view of real-time active queue requests as they occur, some status information of the pending items in the queue and the current connection status to the server, as well as a small set of input controls that manage the queue operational status - the number of threads running the wait time and the ability to start and stop the queue.

Here's what the UI for this interface looks like:

As requests hit the queue they show up in this monitor and the main form's list. The queue service calls SignalR when it starts processing a queue request and again when a queue request either completes successfully or fails. The list status bar then displays the number of pending messages that are waiting in the queue. The textboxes above let the administrators of this application who have access to the the service manage the queue by tweaking a few settings or by stopping the service altogether. When the update or start/stop button is clicked, a SignalR request is fired to save and or change the service status and then fire a notification to all clients to update their status.

The web site client uses knockout.js for databinding a couple of fairly simple models - the list of visible list items and the queue's status - which are updated by the SignalR callback methods that receive message data from the server. When the model data is updated knockout bindings kick in and refresh the UI immediately resulting in a mostly codeless update process. The only explicit code to display server content are the status messages which are not bound but explicitly called via a showStatus message.

For what it does there's a surprisingly little amount of code involved and the logic involved to make this work is pretty simple.

Granted this isn't a very complex UI, but still it was pretty amazing for me to see hundreds of requests rolling through in a few seconds and updating 10 browser windows simultaneously - until you see this happen with your own application it's hard to appreciate how much satisfaction you get from that very concept working so efficiently! It brings me back to the very early days of the Web when it was exciting to see any dynamic content on a live Web page :-)

I can think of a bunch of use cases where this technology makes a lot of sense:

Any sort of two-way messaging applications (chat, messaging)
Real time data feeds or ticker displays
Real time data monitors for logs, lists, users etc. (Admin interfaces)
Long running async requests with real-time status updates
A replacement for some Queue type operations with direct real-time connections
Screen sharing applications with shared editing data by multiple users
Interactive multi-player games with real time screen updates
and, and, and…

Ease of Use

Another thing that impressed me about SignalR when I started working with it is that this has to be some of the easiest to use Microsoft technology to come along in a long time, while providing some really powerful features. SignalR is based on dynamic language features which do away with a lot of ceremony in defining of interfaces and mapping client to server. In many cases it's as easy as creating a class on the server and having the client reference the server side hub and method and just call it. End of story. The same is true for broadcasting of messages from the server to the client - there's no contract, no special interface, all you do is call a method that may or may not exist on the client - if you implement it on the client it will get called. End of story - again.

What was really surprising about this project was that going from zero knowledge of SignalR to a fully functional, initial implementation that hit all the initial usage points I mentioned above, took all of 2 work days to accomplish. This included learning about SignalR and experimentation with a few different approaches, dealing with knockout.js, plus building robust connection management code that can deal with disconnects and reconnects (which truthfully was the most complex and time-consuming piece and the only part that required a bit of research and some help on the SignalR Jabbr channel).

This solution uses a Windows Service Project on the server using SignalR's OWIN hosting, which trivial to set up. In fact it takes all of 10 lines of code to hoist up the server.

Low Ceremony

It's extremely easy and low ceremony to broadcast a SignalR message even in a self hosted environment. The following C# server side code calls a JavaScript callback on all clients that are listening (this method displays a queue list item):

// Write out message to SignalR clients  
HubContext.Clients.All.writeMessage(id,
    "Info",
    DateTime.Now.ToString("HH:mm:ss"),
    message,  
    string.Empty);

where the writeMessage method call is translated to the client side JavaScript handler. On the client there's a callback handler registered on a writeMessage operation which is then fired on the client. The script code then proceeds to bind the values to a view model item using knockout.js and updates the display dynamically.

On the client I can simply register a method that handles a callback which effectively 'publishes' that method on the client:

hub.client.writeMessage = self.writeMessage;

And I can then implement the writeMessage callback method that handles this logic (or use an anonymous method):

writeMessage: function (message, status, time, id, elapsed, waiting) { 
    … update collection item viewModel and let knockout.js bind
}

The server can now call the writeMessage function on the client using the C# code shown above. It's all dynamic.

Calls in the other direction - from client to server are equally simple. The client calls a server method like this (where self is my top level object container and hub is an instance of the SignalR hub stored on it):

self.hub.server.getServiceStatus()
               .fail(page.statusMessage);

This calls a GetServiceStatus() method on the server's hub.

Once a hub has been created and stored you can simply call the server object which maps any methods you call straight to the .NET server methods implemented on the hub. Here's the server code:

public void GetServiceStatus()
{
    var instance = Globals.Controller;
    if (instance == null)
       Clients.Caller.getServiceStatusCallback(null);
    else
       Clients.Caller.getServiceStatusCallback(
         new QueueControllerStatus()
         {
            queueName = instance.QueueName,
            waitInterval = instance.WaitInterval,
            threadCount = instance.ThreadCount,   
            paused = instance.Paused
         });
}

This server code receives the JavaScript client's request and then broadcasts a message back to all connected clients. Effectively this code has a single JavaScript client requesting that the server should broadcast a message to all clients. Here the code basically pushes down status information which is then picked up on the client and bound via knockout to the textboxes and the start/stop button.

The server code can use the Client.All, Clients.Caller, Clients.AllExcept collections to reference common groups or you can add users to specific Groups that you can then broadcast to. Lots of flexibility again in a really easy to use model.

Performance and Resources

Since this was my first time using SignalR I had no idea what to expect in regards to performance with using SignalR's messaging. I was actually surprised that I couldn't overload the UI operation by stuffing even 5000 messages into the queue. SignalR happily and rapidly kept up with the service in sending out messages and updating the list UI faster than you could even begin to keep reading it. 1000 queue requests (x2 for begin/end message) went through in less than 4 seconds! Also tried this with 10 clients connected simultaneously and performance didn't change noticably with the increased number of connected clients.

It's important to understand that this application will be used by a small number of administrative users, so it's not going to be used by thousands of users simultaneously. At most we figure there may be 10 people connected at a time. However, connections are something to consider with SignalR. As cool as this technology is, it's connected technology meaning that each client connected through SignalR is using a persistent and dedicated connection on the Web Server. 10 users or 100 are probably not much of a problem, but thousands of users may bump up against the Web server connection and Windows thread and resource limits eventually. SignalR also includes some scalability features, but these get very complex quickly and if this becomes an issue I personally think that one should reconsider whether SignalR or a real-time connection based interface is the right choice…

While the SignalR's docs claim that it's capable of thousands of simultaneously connected clients (given the connection pool is high enough), there is a finite limit to the amount of connections you can simultaneously run with IIS or self-hosting along with the CPU and memory overhead associated with each connection.

Caveat emptor - make sure you understand the implications of using SignalR in terms of connection, memory, cpu and bandwidth usage.

Documentation and Support

As I mentioned the basics and overall behavior of SignalR are pretty easy to grasp and put into practice and the online documentation does a pretty good job of getting you started and explain the general model of how the messaging flow and program implementation code works. There are nice and simple examples and it works great.

However, some of the more specific documentation is a bit sketchy and often limited or missing altogether. The hardest part of this small component we built was dealing with the connection and disconnection notifications required to determine whether the Windows Service is online and the SignalR server running and how to deal with scenarios where connections are dropped and then reconnecting as necessary. SignalR actually includes some very sophisticated logic to notify you of connect and disconnect events on the client, but there are quite a few overlapping different events that fire on the client and I for one got lost in which one actually needed to be handled to reliably re-connect. There were a handful of other issues at this same lower level that were difficult to resolve through the documentation or even searching.

I also found searching on SignalR content a bit frustrating because a lot of the hits I'd get for topics in blog posts or StackOverflow answers ended up being from preview versions with information that was no longer valid. Hopefully this stuff will work itself out in time.

In the meantime however, I hopped over to the SignalR Jabbr Channel and posted a few of my conundrums over there. There's lots of help offered on this channel from peers and from the authors of SignalR (or David Fowler mostly) frequently jumping in and answering questions. David helped me with two sticky issues and in a few minutes pointed me in the right direction. This type of interactive support is just awesome and it also shows the enthusiasm by some of the people involved with SignalR. I do wonder though how well this type of support will scale in the future. We'll see - in the meantime it's great to see this kind of direct interaction which hopefully helps the SignalR guys iron out some rough spots that come up more frequently.

SignalR - Hell Yeah!

As you can probably tell I'm pretty jazzed about what SignalR offers to .NET developers. Web based real-time communication technology like SignalR offers many opportunities to rethink of what we can actually build with Web applications today, offering many more opportunities to build interactive and collaborative applications. It provides a different way to access information in Web applications in a more direct, real time manner and it does this in a way that is relatively simple to accomplish. SignalR is amongst the cleanest and easiest to implement solutions I've seen coming from Microsoft in a very long time.

I'm especially excited about the ability to interface SignalR's server side code with self-hosted applications that gives us the ability to more easily connect back end services to browser front ends. For administrative applications or dashboards this is incredibly powerful stuff and it's easy to integrate into existing applications. I'll post more on this topic in the future.

But even in plain old Web applications the opportunities to provide real time data or to have users share information across multiple live browser instances is pretty cool. The abstraction provided by SignalR's client and server make it so easy to take advantage of this functionality in just about any application. There are so many opportunities here - from the obvious real time broadcast services to more subdued server callbacks that can replace traditional AJAX interfaces to providing real time access to changing data in Line of Business or even public facing applications. Then there is the use case for running long running async operations on the server and providing real-time feedback to the client page. And there's the whole opportunity with interactive games or productivity applications where multiple users can interact with the same shared information to provide a live and updating interface. Doing simple interactive games like Battleship etc. become almost trivial with this sort of technology and even more interactive graphics intensive games become a possibility with this toolset.

Lots of opportunities to dream up, so dream on…

Posted in ASP.NET JavaScript SignalR

Publish Individual Files to your Server in Visual Studio 2012.2

Rick Strahl — Fri, 10 May 2013 09:29:26 GMT

In Visual Studio 2012 Update 2 there's a sweet little new gem, that I championed for some time in the past, and that has finally made it into the VS box: You can now publish individual files to the server without having to publish the entire site. You can now publish 1 or more files simply by selecting them in the Solution Explorer and using the Context Menu's Publish Selected Files or Publish File xxxx.xxx.

In the past if you wanted to publish your site, it was an all or nothing affair: You basically had to rebuild and re-publish the entire site. Publishing works great when you're making major updates that affect binaries and configuration settings. In that case you do want a full publish to push up your binary file changes as well as web.config transformations etc. This is a great feature and the cornerstone of publishing which is as it should be.

But on more than a few occasions I've:

Forgotten to include some content file like an image in a full publish
Had to make a really minor change to a content file or image and need to push it up
Make some quick iterative changes repeatedly to a file to tweak the UI or an image on the server

Now, with Update 2 you have another option to publishing the entire site -you can now publish an individual file.

I know this is a minor thing, but I can't tell you how often I use this for quick image or CSS updates. Sometimes I actually prefer making changes to these sorts of things on a live site rather than firing up the local copy first especially if the live site is running with a full set of data. It's often convenient to just push individual files. This is especially true for my personal content sites, more so than typical business applications.

Web Deploy Getting Easier

As a side note I've been a big fan of Web Deployment in Visual Studio - it's such a tremendous time saver over manually uploading files to the server and trying to figure out what needs updating. Prior to Web Deploy features in Visual Studio I actually had used a custom solution I cobbled together using FTP that provided much of the same functinality including the abililty to push individual files which I found very useful.

It's also great in a team environment, since publish settings are typically shared in source control. This ensures that everybody is pushing up code consistently to the staging or live server using the same settings that are configured only once. It's great when a new developer comes on board especially - they don't have to configure anything they are just ready to go.

When Web Publishing was introduced the intial versions were horrible to the point of unusability. In VS 2010 it improved somewhat, but the server side installation of Web Deploy was still a major pain in the ass. Getting Web Deploy configured properly on the server has been a real pain in the ass with 3 different installs required and several manual configuration steps.

With the latest Web Deploy 3.0 release though, Microsoft finally seems to have gotten Web Deploy right to where it's a single simple installation on the server that just works once installed. There no longer are any finicky configuration settings and it just works off the single install. Inside of the Visual Studio 2012 Web Publish client also has made the Publish Settings dialog a bit more user friendly and more flexible in what you can use to connect to the server. VS now understands pure site urls and virtuals as opposed to the base site url and Site ID/Name that was required previously and was always confusing.

The end effect is I no longer dread setting up Web Deploy for the first time on a server, nor do I have to go look up the configuration for another site to figure out what put in the boxes :-).

It's kind of sad that it took so long for Web Deploy to get it all right, but now the whole thing is ridiculously smooth. There are a still a few issues with web.config transforms that are difficult to deal with from time to time, but that's not really Web Deploy's problem, but a problem of how to partition developer specific settings in configuration files which is always a problem.

In any case, I hope some of you find the new single file or selected file publishing feature as useful as I have. It's just one more little tweak that makes life easier and shaves a few minutes off the development process. Score!

Posted in ASP.NET Visual Studio

A WebAPI Basic Authentication MessageHandler

Rick Strahl — Tue, 30 Apr 2013 10:29:42 GMT

In my last post I showed a very simple Basic Authentication Filter implementation and several people commented that the 'right' way to do this is by using a MessageHandler instead. In the post I discussed why I opted for a filter rather than the MessageHandler: A filter is much simpler to implement and keeps all the relevant code pieces in one place instead of scattering them throughout the Web API pipeline. This might not be the right choice for all authentication, but if you're doing custom authentication/authorization in your app you're not going to mix and match and plug a multitude of auth mechanisms together. For simple auth scenarios a filter is just fine, especially since even when you implement a MessageHandler you need to implement an AuthorizationFilter anyway.

Just as an exercise, I spend a little time today to put together a message handler based Basic Authentication implementation to contrast the two. There are a few more moving pieces to this implementation:

A MessageHandler to handle the Basic Auth processing
A custom Identity to pass the username and password around
An Authorization filter to validate the user

MessageHandler for Authentication

MessageHandlers in Web API are chainable components that hook into the request/response pipeline. You can plug many message handlers together to provide many module like features. MessageHandlers can handle processing on the inbound request cycle and the output response cycle, via a simple Task<T> abstraction that provides the asynchronous pipeline processing.

To implement the BasicAuthenticationHandler you can create a class derived from DelegatingHandler and override the SendAsync method:

public class BasicAuthenticationHandler : DelegatingHandler
{
    private const string WWWAuthenticateHeader = "WWW-Authenticate";

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, 
                                                           CancellationToken cancellationToken)
    {
        var credentials = ParseAuthorizationHeader(request);

        if (credentials != null)
        {
            var identity = new BasicAuthenticationIdentity(credentials.Name, credentials.Password);
            var principal = new GenericPrincipal(identity, null);

            Thread.CurrentPrincipal = principal;
            //if (HttpContext.Current != null)
            //    HttpContext.Current.User = principal;
        }

        return base.SendAsync(request, cancellationToken)
            .ContinueWith(task =>
            {
                var response = task.Result;
                if (credentials == null && response.StatusCode == HttpStatusCode.Unauthorized)
                    Challenge(request, response);


                return response;
            });
    }

    /// <summary>
    /// Parses the Authorization header and creates user credentials
    /// </summary>
    /// <param name="actionContext"></param>
    protected virtual BasicAuthenticationIdentity ParseAuthorizationHeader(HttpRequestMessage request)
    {
        string authHeader = null;
        var auth = request.Headers.Authorization;
        if (auth != null && auth.Scheme == "Basic")
            authHeader = auth.Parameter;

        if (string.IsNullOrEmpty(authHeader))
            return null;

        authHeader = Encoding.Default.GetString(Convert.FromBase64String(authHeader));

        var tokens = authHeader.Split(':');
        if (tokens.Length < 2)
            return null;

        return new BasicAuthenticationIdentity(tokens[0], tokens[1]);
    }


    /// <summary>
    /// Send the Authentication Challenge request
    /// </summary>
    /// <param name="message"></param>
    /// <param name="actionContext"></param>
    void Challenge(HttpRequestMessage request, HttpResponseMessage response)
    {
        var host = request.RequestUri.DnsSafeHost;                    
        response.Headers.Add(WWWAuthenticateHeader, string.Format("Basic realm=\"{0}\"", host));
    }

}

If you looked at my last post this should look fairly familiar - the basic auth logic is very similar to the filter. I reused the Challenge and ParseAuthorizationHeader changing just the inputs to the request and response messages respectively.

The message handler works in two distinct steps - the initial code that fires on the inbound request, which tries to parse the authentication header into a BasicAuthenticationIdentity and assigning that identity to the thread principle.

The second step - the part in the ContinueWith() Task block - handles the processing on the outbound response. Things have to be broken up like this in a MessageHandler because the Response doesn't exist on the inbound request yet. The code here is responsible for issuing the challenge if the response status is unauthorized.

So the logic goes like this:

Request is authenticated already - goes through
Request is not authenticated and returns a 401 (from an AuthFilter or explicit 401 ResponseMessage from code)
Request is not authenticated and returns something other 401 - request goes through

To make all this work there are a couple more things that need to be implemented.

BasicAuthenticationIdentity

Basic Authentication works via a username and password that is passed as a base64 encoded, clear text string. In order to authorize the user in a custom authorization scenario that username and password has to be passed up the pipeline into the AuthorizationFilter that actually handles the authorization of the user.

To do this I opted to create a BasicAuthenticationIdentity class. Using this identity the handler can set the username and password on the Identity and pass it to AuthorizeFilter. Here's the implementation:

/// <summary>
/// Custom Identity that adds a password captured by basic authentication
/// to allow for an auth filter to do custom authorization
/// </summary>
public class BasicAuthenticationIdentity : GenericIdentity
{
    public BasicAuthenticationIdentity(string name, string password) : base(name,"Basic")
    {            
        this.Password = password;
    }

    /// <summary>
    /// Basic Auth Password for custom authentication
    /// </summary>
    public string Password { get; set; }               
}

AuthorizeFilter

Next we need a filter to handle the authorization of the user. This logic most likely will be application specific. Because all we'll need to do here is validate the user's credentials and return yay or nay, an AuthorizeFilter is the easiest:

public class MyAuthorizationFilter : AuthorizeAttribute
{      
    protected override bool IsAuthorized(HttpActionContext actionContext)
    {             
        var identity = Thread.CurrentPrincipal.Identity;
        if (identity == null && HttpContext.Current != null)
            identity = HttpContext.Current.User.Identity;

        if (identity != null && identity.IsAuthenticated)
        {
            var basicAuth = identity as BasicAuthenticationIdentity;

            // do your business validation as needed
            var user = new BusUser();
            if (user.Authenticate(basicAuth.Name, basicAuth.Password))
                return true;                
        }

        return false;
    }
}

In the filter you can simply override the IsAuthorized() method and return true or false. If you return false WebAPI automatically fires a 401 status code, which triggers the Challenge() in the BasicAuthenticationHandler that's monitoring for 401's.

The IsAuthorized method implementation typically has business specific code in it that handles the authorization of the user. Basically you can capture the Thread Principal and the BasicAuthenticationIdentity and retrieve the username and password. You can then go to town on the username and password. In my example here a business object is fired up to authenticate the user.

By the way, notice that in my last post I used an AuthorizationFilter - and here I'm using an AuthorizeFilter. AuthorizeFilter works great if all you need to do is validate a user and return true or false. If there's more logic involved that, like creating a new response then an AuthorizationFilter is the better choice.

Configuration

Once the handler and filter exist they have to be hooked up. MessageHandlers have to be added in the configuration:

GlobalConfiguration.Configuration.MessageHandlers.Add(new BasicAuthenticationHandler());

The AuthorizationFilter can either be applied via global configuration or on the controller:

GlobalConfiguration.Configuration.Filters.Add(new MyAuthorizationFilter());

or you can apply it on the controller:

[MyAuthorizationFilter]
public class QueueController : ApiController

Filter or MessageHandler - you decide

Comparing the two modes of operation - Authentication MessageHandler or AuthorizationFilter - there's not a tremendous difference in implementation. To me the filter is more compact and easier to follow what's going on simply because everything is in one place. For most typical custom login scenarios that are tied to business logic, that'll be totally sufficient. The advantage of a message handler is that it's globally applied and is part of the WebAPI pipeline so if several components need to take advantage of BasicAuthentication with different Authorization that would work. But then again you can do that with a filter as well, especially since a MessageHandler still requires a filter for it's authorization. <shrug>

Either way you can take your pick from these two implementations.

Resources

Posted in Web Api

A WebAPI Basic Authentication Authorization Filter

Rick Strahl — Thu, 18 Apr 2013 18:35:19 GMT

Recently I needed to implement user based security in a Web API application that's easily accessible from a variety of clients. The customer asked specifically for Basic Auth support and so needed to implement custom Basic Auth support. In this post I describe a simple AuthorizationFilter based implementation of Basic Authentication for Web API.

WebAPI: Getting Headers, QueryString and Cookie Values

Rick Strahl — Mon, 15 Apr 2013 10:48:44 GMT

Finally got tired to trying to remember how to get at the Headers, Cookies and QueryString 'collections' in Web API, since there's zero consistency and messy nested collections to deal with. Here's are a set of extension methods that make it easier.

UNC Drive Mapping Failures: Network name cannot be found

Rick Strahl — Fri, 05 Apr 2013 06:58:00 GMT

Ran into a nasty issue yesterday trying to map a remote drive via UNC pathing. Basically I was unable to connect with failures occurring instantly and without prompting for credentials even when asking to use different credentials. Turns out the problem is the Network Provider Order - here's more info.

A small, intra-app Object to String Serializer

Rick Strahl — Mon, 01 Apr 2013 09:41:14 GMT

On a few occasions I've needed a very compact serializer for small and simple, flat object serialization, typically for storage in Cookies or a FormsAuthentication ticket in ASP.NET. XML and JSON serialization are too verbose for those scenarios so a simple property serializer that strings together the values was needed. Originally I did this by hand, but here is a class that automates the process.

Experimenting with Online Backups

Rick Strahl — Wed, 27 Mar 2013 21:07:23 GMT

I recently spent a bit of time looking at online synching/backup software to provide a little more resilience to my backup situation. Lots of choices but nothing that's really quite perfect yet. Here's what I found.

Firing an Entity Framework Database Initializer from within DbContext

Rick Strahl — Tue, 26 Mar 2013 19:53:00 GMT

Database initializers in Entity Framework can be a pain, especially when you're using EF as part of smaller components that may or may not load into a database shared with other EF Contexts. Here's a small helper utility that lets you internalize the database initializer and fire it the first time the context is loaded.

Text Editor Associations/Extensions in Visual Studio getting lost

Rick Strahl — Sat, 23 Mar 2013 01:47:46 GMT

Visual Studio allows you to create text editor extensions that map standard Visual Studio editors to custom extensions. It's a useful feature that I use a lot with some older products, but unfortunately I've seen alot of cases where the editor/extension mapping gets lost even though Visual Studio still shows it as registered. Here's more info on the problem and how to fix it at least temporarily.

Using plUpload to upload Files with ASP.NET

Rick Strahl — Tue, 12 Mar 2013 10:42:00 GMT

plUpload is a popular client side multi-file upload component. In this article I describe a small library that abstracts the server side processing of uploaded files with an HTTP handler demonstrate putting it all together with a small Image Upload sample application.

Sql Connection Strings in .Config Files vs. Source Control

Rick Strahl — Wed, 27 Feb 2013 20:18:56 GMT

Connection strings in projects under source control can be problematic. Each Source Control user can potentially have different connection settings to use a database connection and these differences can't be easily reconciled via Source Control. Here are a couple of approaches that have worked for me to deal with this issue.

Visual Studio Web Publish Lockup? Check for invisible Window

Rick Strahl — Thu, 21 Feb 2013 08:25:23 GMT

If your Web Publish dialog appears to lock up Visual Studio when you click on the Publish option, most likely the Web Publish window is hidden on a second screen that is not currently visible. Here's how you can work around this annoying little bug.

Building a better .NET Application Configuration Class - revisited

Rick Strahl — Fri, 28 Dec 2012 12:41:29 GMT

Managing configuration settings is an important part of successful applications. It should be easy to ensure that you can easily access and modify configuration values within your applications. If it's not - well things don't get parameterized as much as they should. In this post I discuss a custom Application Configuration class that makes it super easy to create reusable configuration objects in your applications using a code-first approach and the ability to persist configuration information into various types of configuration stores.

Process.Start() and ShellExecute() fails with URLs on Windows 8

Rick Strahl — Thu, 13 Dec 2012 04:14:30 GMT

It appears that on Windows 8 there's a bug in the ShellExecute() API that causes failure in URL navigation when running under Administrative privileges.

A Small Utility to Delete Files recursively by Date

Rick Strahl — Sat, 01 Dec 2012 05:13:05 GMT

After again searching for a script or tool that can easily delete files recursively down a folder hierarchy with a date filter and coming up with several 'almost there' solutions I sat down and created a small Console app that handles this task. I've posted the resulting project on Github, with both the binary and source code, in case you ever find yourself with the same need.

Set-Cookie Headers getting stripped in ASP.NET HttpHandlers

Rick Strahl — Fri, 30 Nov 2012 01:38:26 GMT

Ran into a nasty problem with Cookies not getting sent in HttpHandler code when using Response.AppendHandler() with the Set-Cookie key. It turns out it's a very narrow edge case, but one that can bite in unexpected system level applications.

WCF WS-Security and WSE Nonce Authentication

Rick Strahl — Sat, 24 Nov 2012 13:31:00 GMT

I ran into a Web Service last week that required WS-Security headers with an embedded nonce value. Unfortunately WCF doesn't support this particular protocol directly. Here's how to create custom credentials and a tokenizer to write out the customized WS-Security header.

Windows 8 Live Accounts and the actual Windows Account

Rick Strahl — Tue, 20 Nov 2012 04:10:30 GMT

When you log on with a Windows Live account in Windows 8, what really happens to your credentials? It's not quite obvious, so here are a few thoughts and examples that demonstrate the relationship between Windows and Live accounts.

DevConnections Session Slides, Samples and Links

Rick Strahl — Tue, 13 Nov 2012 13:20:02 GMT

Finally getting around to posting links to my DevConnections session in Vegas a couple of weeks ago. It was a fun time after a long absence from speaking...

HTML5 Input type=date Formatting Issues

Rick Strahl — Fri, 09 Nov 2012 02:27:09 GMT

The new HTML5 Input types make it easier to display special formatted input types like dates and email addresses. Browsers that support them display a nice UI for editing and can validate values. However, support currently is limited and date formatting especially is complex as it involves using an ISO date format that doesn't fall back nicely to non-supporting browsers.

Back to Basics: When does a .NET Assembly Dependency get loaded

Rick Strahl — Sat, 03 Nov 2012 23:39:12 GMT

Assembly loading in .NET is often a cause of confusion. So many times I've heard how evil it is to add a reference to some big assembly, if it's just a minor feature. But .NET is really smart in assembly loading and by default uses just in time loading of referenced assemblies. In this post I review when assemblies are loaded with a few simple examples that demonstrate the process.

Caveats with the runAllManagedModulesForAllRequests in IIS 7/8

Rick Strahl — Fri, 26 Oct 2012 06:15:00 GMT

IIS 7 and 8 support using Managed Modules to handle access to all IIS request content which is very powerful. But sometimes you actually want to not handle non-ASP.NET content and it's not very obvious how to minimize access to non-ASP.NET requests in managed modules.

Dynamic Code for type casting Generic Types 'generically' in C#

Rick Strahl — Tue, 23 Oct 2012 09:06:26 GMT

Here's a short entry on how dynamic can be a life saver when you can't cast a type between multiple objects, specifically when the object in question is a generic type without a common base type to cast to.

A tiny Utility to recycle an IIS Application Pool

Rick Strahl — Tue, 02 Oct 2012 10:29:36 GMT

Here's a small console app to recycle an Application Pool which seems to be something I've needed to do repeatedly in the past.