Rick Strahl's Web Log

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

ASP.NET Web API allows for a number of different ways to implement security. The 'accepted' way to handle authentication is to use either IIS's built in security (ie. rely on HttpContext and the IIS authentication through Windows Security) or you can roll your own inside of Web API using Web APIs message semantics. If you roll your own the recommended way for authentication is to create a MessageHandler and then add Authorization with a Filter. AFAIK, Web API natively doesn't ship with any authentication handlers at all, so you pretty much have to roll your own if you want to host outside of IIS.

Anyway, in one of my apps for a customer we needed custom user authentication based on user credentials from the business layer and the client explicitly requested Basic authentication due to the client side requirements. Basic Authentication is easy and support by just about any Web client, but it's not secure and requires that SSL is used to keep the encoded (not encrypted) credentials somewhat safe from simple attacks. In this case the app runs on an internal network so the risk factor is low.

Filter Only?

When I looked at the various options at implementing custom login security outside of ASP.NET, the first thing I found was Authorization filters. Authorization filters are a really easy way to examine the request, determine whether a user has access and then either going on or exiting out with an UnauthorizedAccess exception.

Filters aren't meant to be full on HTTP request managers that return results - typically that's meant for MessageHandlers in Web API - but Basic Authentication is such a simple protocol that requires just a few lines of code to implement, so I went ahead and implemented the entire protocol in the filter. Since in this application we have a specific way of authorizing there's only one type of auth happening, there was little need to use a more complex implementation. For contrast in my next post I also implement a message handler based Basic Authentication implementation, so you can easily compare the two if wish.

Authorization Filters in ASP.NET Web API

An Authorization filter inherits from the AuthorizationFilterAttribute class and typically overrides the OnAuthorization() method which should handle the authorization tasks. The filter should do nothing to allow a request through if authorization is valid, throw a UnauthorizedException() if it fails to validate a user, or return a new custom HttpResponseMessage.

Here's the somewhat generic Authorization filter version I ended up with:

/// <summary>
/// Generic Basic Authentication filter that checks for basic authentication
/// headers and challenges for authentication if no authentication is provided
/// Sets the Thread Principle with a GenericAuthenticationPrincipal.
/// 
/// You can override the OnAuthorize method for custom auth logic that
/// might be application specific.    
/// </summary>
/// <remarks>Always remember that Basic Authentication passes username and passwords
/// from client to server in plain text, so make sure SSL is used with basic auth
/// to encode the Authorization header on all requests (not just the login).
/// </remarks>
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false)]
public class BasicAuthenticationFilter : AuthorizationFilterAttribute
{
    bool Active = true;

    public BasicAuthenticationFilter()
    { }

    /// <summary>
    /// Overriden constructor to allow explicit disabling of this
    /// filter's behavior. Pass false to disable (same as no filter
    /// but declarative)
    /// </summary>
    /// <param name="active"></param>
    public BasicAuthenticationFilter(bool active)
    {
        Active = active;
    }
        

    /// <summary>
    /// Override to Web API filter method to handle Basic Auth check
    /// </summary>
    /// <param name="actionContext"></param>
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (Active)
        {
            var identity = ParseAuthorizationHeader(actionContext);
            if (identity == null)
            {
                Challenge(actionContext);
                return;
            }


            if (!OnAuthorizeUser(identity.Name, identity.Password, actionContext))
            {
                Challenge(actionContext);
                return;
            }
            
            var principal = new GenericPrincipal(identity, null);

            Thread.CurrentPrincipal = principal;

            // inside of ASP.NET this is required
            //if (HttpContext.Current != null)
            //    HttpContext.Current.User = principal;

            base.OnAuthorization(actionContext);
        }
    }

    /// <summary>
    /// Base implementation for user authentication - you probably will
    /// want to override this method for application specific logic.
    /// 
    /// The base implementation merely checks for username and password
    /// present and set the Thread principal.
    /// 
    /// Override this method if you want to customize Authentication
    /// and store user data as needed in a Thread Principle or other
    /// Request specific storage.
    /// </summary>
    /// <param name="username"></param>
    /// <param name="password"></param>
    /// <param name="actionContext"></param>
    /// <returns></returns>
    protected virtual bool OnAuthorizeUser(string username, string password, HttpActionContext actionContext)
    {
        if (string.IsNullOrEmpty(username) || string.IsNullOrEmpty(password))
            return false;

        return true;
    }

    /// <summary>
    /// Parses the Authorization header and creates user credentials
    /// </summary>
    /// <param name="actionContext"></param>
    protected virtual BasicAuthenticationIdentity ParseAuthorizationHeader(HttpActionContext actionContext)
    {
        string authHeader = null;
        var auth = actionContext.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(HttpActionContext actionContext)
    {
        var host = actionContext.Request.RequestUri.DnsSafeHost;
        actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
        actionContext.Response.Headers.Add("WWW-Authenticate", string.Format("Basic realm=\"{0}\"", host));
    }

}

This code relies on a customized BasicAuthenticationIdentity class that extends the standard GenericIdentity with a password:

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; }
}

The implementation of the filter is pretty straight forward and handled in a few distinct steps:

Parsing credentials into a BasicAuthenticationIdentity if available
If no credentials were found Challenge for Authorization (401 Response)
If credentials were found authorize the user based on the credentials
Set the ThreadPrinicipal (or HttpContext.User) if credentials are valid

Basic Auth is - basic

One of the reasons basic auth is often fallen back to is that it's - basic. It's very simple to implement because the data travelling over the wire is simply a user name and password encoded as a base64 string separated by a :.

username:password

The whole thing is then base64 encoded:

dXNlcm5hbWU6cGFzc3dvcmQ=

An inbound Authorization header from the client, that sends a username and password then looks like this:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Because it's so basic it's also fairly insecure. Remember in real world scenarios to use SSL with Basic Authentication accessed APIs to minimize exposure of the plain text username and password!

Authorization

The ParseAuthorizationHeader() method in the filter then decomposes the Authorization header and reconstitutes username and password into a BasicAuthenticationIdentity which simply holds the username and password so that the Authorization process can determine whether that user and password combination is valid.

The filter contains a very simple OnAuthorize() method that can be overridden in a subclass. This method simply should return true or false and should implement any business logic necessary to determine whether the user is authorized or not. You can validate against a business object, or you could even validate against local or domain Windows accounts given that you have a username and password to work with.

The default implementation simply checks for presence of the Authorization header and returns true.

Here's an example of specialized BasicAuthenticationFilter that uses a business object to validate the user:

public class MyBasicAuthenticationFilter : BasicAuthenticationFilter
{

    public MyBasicAuthenticationFilter()
    { }

    public MyBasicAuthenticationFilter(bool active) : base(active)            
    { }


    protected override bool OnAuthorizeUser(string username, string password, HttpActionContext actionContext)
    {
        var userBus = new BusUser();

        var user = userBus.AuthenticateAndLoad(username, password);
        if (user == null)
            return false;

        return true;
    }
}

To use the filter now you can simply add the attribute to a controller you want to apply it to:

[MyBasicAuthenticationFilter]
public class QueueController : ApiController

or you can globally apply it in the Web API configuration:

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

Additionally you can also apply the filter attribute on an individual method to either enable or disable the authentication functionality.

[MarvelPressAuthorizationFilter(false)]
[GET("Queue")]
public IEnumerable<QueueMessageItem> GetRecentMessages(string type = null)

Generally I prefer the first approach, since in most of my apps I have at least one section where the authentication security doesn't apply. For this filter it probably doesn't matter, but if you're using something like token based security you might have a Login API that needs to be accessible without authentication. If you need to keep an individual method (like a Login method!) from firing authentication you can use the last approach and add an attribute with the active=false parameter.

This works pretty well, and it's all fully self contained. What's also nice about this simple implementation is that you have some control over where it is applied. It can be assigned to global filters to fire against every request or against individual controllers and even individual action methods. With a MessageHandler this is considerably more involved as you have to coordinate between a MessageHandler and a Filter to decide where to apply the message handler.

Do we need a Message Handler?

Most other examples I looked at involved message handlers which are a bit more involved to set up and interact with. MessageHandlers in WebAPI are essentially pre-and post request filters that allow to manipulate the request on the way in the response on the way out. To effectively build an authentication message handler is a bit more work than the code I have above. MessageHandlers are also fully async so you have to deal with tasks (or async/await at least) in your code which adds some complexity.

An authentication message handler typically only would have to deal with checking for authentication information in the HTTP headers and if not there fire the challenge requests. Authorization is left to other mechanisms - like a filter. The handler then sets up a principal that can be checked later. The handler also has to check the response output to determine whether to challenge the client. So with a Message Handler implementation you'd have a two fold implementation: the message handler plus an AuthorizationFilter to validate the user.

For reference I also wrote a blog post about a Basic Authentication MessageHandler. It's a little more involved, but most of the code is similar, just a bit more scattered - you can check it out for yourself and take your pick from the two implementations.

I do think that if you are building a generic authentication mechanism that is universally usable, then a MessageHandler makes sense. You can combine multiple message handlers and authentication schemes for example.

But for simple use cases where you use a very application specific custom logon scheme - you are not going to care about other security implementations, so the filter actually makes sense because it keeps all the code for managing the authentication and authorization logically together.

This has been a nice and simple and self-contained solution that's easy to reuse and I've used it on a few projects now. I hope some of you find this useful as well.

Resources

Posted in Web Api Security

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.

Creating STA COM compatible ASP.NET Applications

Rick Strahl — Wed, 19 Sep 2012 01:36:42 GMT

When it comes to deploying STA COM components in ASP.NET only WebForms has native support for STA component. Other technologies like MVC, ASMX Web Services and WCF run only in MTA mode. If you need to run your STA COM Components in ASP.NET here is what you need to know and a few tools that help you create STA compatible handlers.