Security Briefs

SoCal Code Camp

keith-brown — Mon, 28 Jun 2010 19:26:59 GMT

It was great meeting all of you at the camp! Thanks for coming to my talk, “Get a Whiff of WIF”. The slides and demos can be found here. If you attended the camp, don’t forget to activate your free 7-day subscription to Pluralsight On-Demand! You’ll be able to see *all* of our courses without restriction!

Enjoy!

Keith Brown’s TechEd NA 2010 Session Demos

keith-brown — Sat, 12 Jun 2010 22:23:42 GMT

I was fortunate to be able to tag team a talk at TechEd New Orleans with Aaron Skonnard this week, and I wanted to post my bits from the demos we did.

There were three parts to my demo. The first part was where Aaron added in an attribute on his Presentation Feed service to require a claim before granting access to the feed. You can get the code for his service and my WCF behavior attribute from his demos here. The code for the client that authenticates with ACS to get a token to send in the Authorization header to Aaron’s service can be found in my demos (below). It’s in the PresentationFeedClient folder.

The second part of my demo used a simple string reverser service that I built in ASP.NET MVC. Once again, I simply authenticated directly with ACS, got a token, and sent it to the service as part of the Authorization header.

The third part of my demo simulated an enterprise single sign on. I used Justin Smith’s “mini ADFS” simulator to issue a SAML token to my client, simulating a logon request to a real ADFS federation server in a domain. I then sent this SAML token up to ACS and got back a SWT (Simple Web Token) which I sent to my string reverser service, which allowed me in.

The service and client for these last two parts can also be found in the StringReverser folder of my demos (below). I also included a copy of Justin’s MiniADFS server as part of the solution. I hope he doesn’t mind! You’ll need to install the Windows Identity Foundation SDK to run this third demo, as that’s where the SAML and WS-Trust support comes from.

I used the sample ACS Management Browser from the Azure AppFabric SDK to set up a very simple policy in ACS to issue the tokens needed by the services. I included a copy of the policy in the policy.xml file. Nothing fancy here – just simple rules based on issuer claims.

Download my demos here.

Thanks to those who turned in evaluations. Our talk was number three in our track thanks to you!

Dynamically emitting types for unit tests

keith-brown — Thu, 03 Jun 2010 02:47:00 GMT

I’m building a view engine for ASP.NET MVC 2 that locates views based on the type names of the controllers. To unit test the bits that construct a path from a namespace, I needed to have a bunch of different types of controllers, and using actual types was clearly going to get messy, so I synthesized my own dynamic types using Reflection.Emit. This particular example is hardcoded to produce classes that derive from System.Web.Mvc.Controller, but it’s a great start for anyone who wants to synthesize types for whatever reason. It was well worth 15 minutes of research and coding. Kudos to the .NET team for making it so easy!

Here’s an example of usage:

var factory = new ControllerTypeFactory();
var type = factory.MakeControllerType("Foo.Bar.MyController");

The output from this call allows you to avoid having to write this:

namespace Foo.Bar
{
    public class MyController : Controller { }
}

If you want an instance instead of just the type, call MakeController instead, which simply adds a call to Activator.CreateInstance() on the dynamically created type.

Here’s the code. Note that it creates a “RunAndCollect” assembly, which is great for simple cases like this because the assembly will be unloaded from the domain automatically once everything in it is collected. It’s making my unit tests green, which is making me smile.

public class ControllerTypeFactory
{
    private readonly AssemblyBuilder assemblyBuilder;

    public ControllerTypeFactory()
    {
        var assemblyName = new AssemblyName(Guid.NewGuid().ToString());
        assemblyBuilder = AppDomain.CurrentDomain.DefineDynamicAssembly(assemblyName,AssemblyBuilderAccess.RunAndCollect);
    }

    public Type MakeControllerType(string controllerTypeName)
    {
        var moduleBuilder = assemblyBuilder.DefineDynamicModule("module");
        const TypeAttributes typeAttributes = TypeAttributes.Public | TypeAttributes.Class;
        var parentType = typeof(Controller);
        var typeBuilder = moduleBuilder.DefineType(controllerTypeName, typeAttributes, parentType);
        return typeBuilder.CreateType();
    }

    internal ControllerBase MakeController(string controllerTypeName)
    {
        var controllerType = MakeControllerType(controllerTypeName);
        return (ControllerBase)Activator.CreateInstance(controllerType);
    }
}

Types vs. Strings to identify controllers and simplify Areas in ASP.NET MVC 2

keith-brown — Thu, 03 Jun 2010 00:50:00 GMT

Ever since I started working out the RESTful routing strategy we’ll be using for our MVC apps at Pluralsight, I’ve been trying to avoid identifying controllers with strings in places like HtmlHelpers.ActionLink. It occurred to me early on that I’d much rather use type names to identify resources and controllers rather than string.

If you have a WidgetController, why pass controller=“Widget” when you could specify the type of the controller instead? Then you’d see compile errors early, as opposed to having links with empty href elements because the HtmlHelper couldn’t find a matching route because you misspelled a controller name.

You could solve this particular problem by using constants (controller = Controllers.Widget), I suppose. But then when you look at how Areas work, it sure would be nice having the type as part of the route.

I suppose the reason controller names are passed around as strings so much is because of the default routes that ASP.NET MVC gives you when you run the wizard: {controller}/{id}/{action}. But for someone who wants to take a more RESTful approach, you don’t want this style of routing anyway, and you’ll be adding a bunch of custom routes instead of trying to use one generic URL pattern for routing.

In large systems, {controller} isn’t enough to identify a controller anyway. You need to add areas to ensure uniqueness of controller names. Which leads me to the subject of this post (finally!) I’m wondering if anyone can think of any major drawback to simply removing {controller} from the values used in RouteData.Values and replace it with {controllerType} in RouteData.DataTokens. In one fell swoop you eliminate both controller names and area names from the equation.

In large systems where you care about testing, you’re likely to be using ViewModels and modeling links to make them testable. So you won’t be using Html.ActionLink anyway, and it’s very natural to use controller types to build the models for links to controllers that you depend on.

I’ve got a prototype of this working now, and it allows me to put my controllers wherever I like (they don’t have to be in the Controllers folder). My unit tests for resolving incoming requests and outgoing URL generation are all green.

My next step is to build a custom view engine that looks for views based on the controller type. Once that’s wrapped up, I should have very natural support for “areas” that’s based on the types of the controllers, with a hierarchy that follows the namespace structure of the controllers, which should naturally resolve any naming conflicts that could arise. My initial thought about view resolution is that it’d be nice to be able to map an arbitrary prefix of the controller type (e.g. the first bit of the namespace) onto a root folder for the “area” then have the namespace-driven search algorithm take over from there, following the rest of the namespace down the folder tree from the “area” root. Might also be nice to have the view engine be able to pick up shared views from anywhere up the hierarchy.

Request to the MVC team: I had to make one minor change to MvcHandler to be able to get ASP.NET MVC 2 to work this way. I changed MvcHandler.ProcessRequestInit from [private] to [protected virtual]. This allowed me to reuse the vast majority of MvcHandler (the async stuff would be a *** to reimplement). This seems like a really useful extensibility point.

Update (3 Jun 2010): My view engine is complete, and it's working like a charm. No more worrying about "areas" - I get a nice hierarchical site based on the structure of the namespaces of the types that I use in my application. If I run into any problems I'll post them here, but it looks like this is a feasible way to implement a RESTful routing scheme.

Controlling TemplateDepth in ASP.NET MVC 2 Templates

keith-brown — Mon, 31 May 2010 17:43:00 GMT

In my last post, I talked about how convenient it is to use MVC 2 templates to display data. I’ve been trying to use similar ideas to construct generic forms, but I’m running into a problem that I’m hoping there’s an easy way to fix.

I’ve built a very simple example to demonstrate what I’m seeing: a Widget controller that allows you to Create new Widgets. I’m using the default route, nothing special. But I’m using view models, not domain models. Here they are:

public class CreateWidgetPage
{
    public string SummaryOfExistingWidgets;
    public CreateWidgetForm TheForm;
}

public class CreateWidgetForm
{
    public string Name { get; set; }
    public string Color { get; set; }
}

The page I display when you GET /Widget/Create includes more than just a form. I’ve got some display-only details that I want to show the user when she’s about to create a widget. It doesn’t matter what it is, the point is that it’s not something that’s logically part of the form that I want posted back.

Here’s the interesting part of the Create view, which relies on Brad’s tabular Object.ascx editor template to display a simple editable table for Name and Color:

<div>
<%: Model.SummaryOfExistingWidgets %>
</div>
<h2>Create</h2>
<form ...>
    <%= Html.EditorFor(m => m.TheForm) %>
    <div>
        <input type='submit' value='Create' />
    </div>
</form>

And the controller’s Create method that processes the form:

public ActionResult Create(CreateWidgetForm formModel) 
{
   // ...
}

The ViewModel that is posted to Create has null values for both Name and Color. Why? Because the EditorFor helper is encoding the scoping element, “TheForm”, as a prefix on the names of the properties on the view model. If I inspect the HTML that is rendered with a GET to /Widget/Create, the Name property is represented like this:

<input name="TheForm.Name" ... />

Clearly this isn’t going to bind well to CreateWidgetForm, which knows about a “Name”, not “TheForm.Name”.

In an effort to divorce CreateWidgetForm from its scope, I tried this:

<% var theForm = Model.TheForm; %>
<%= Html.EditorFor(m => theForm) %>

This didn’t help. The variable, “theForm”, ended up being used as the scope:

<input name="theForm.Name" ... />

I could see how someone using domain models directly in their views wouldn’t run into this problem. GET on the controller’s Create would return a Widget, say, and POST to the controller’s Create would send that exact same thing back. There’s no need for nesting the way I’ve done it here.

It feels like what I need is a way to tell EditorFor that I want a new root. Don’t pay attention to the fact that TheForm is a property on some bigger object. I want TemplateDepth = 1 when we drill into EditorFor in the above examples. There’s probably some super easy way to do this that I’m just not finding.

Indeed what I’m trying to achieve with ViewModels goes beyond the simplified example I’ve used above. I’m thinking it would be quite nice to have a very generic template for a create form. Something like this:

public class CreateForm
{
    public string PrettyNameForTheThingWeAreAboutToCreate;
    public object FormModel;
}

Coupled with a display template that looks something like this:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<CreateForm>" %>
<h2>Create <%: Model.PrettyNameForTheThingWeAreAboutToCreate%></h2>
<form ...>
<%= Html.EditorFor(m => m.FormModel) %>
<div>
    <input type='submit' value='Create' />
</div>
</form>

I searched quite a bit to see if anyone else had posted about this issue and didn’t find anything, but I can’t be the first to run into this. What am I missing?

PROBLEM SOLVED (Thanks Brad :-)

The solution in my case is to use the overloaded version of EditorFor which allows you to control the prefix:

<%= Html.EditorFor(m => m.FormModel, null, "") %>

Worked like a charm!

Dynamically Structured ViewModels in ASP.NET MVC

keith-brown — Sat, 29 May 2010 17:26:00 GMT

We started building our website back in 2004, when ASP.NET WebForms were all the rage. I’ve finally bitten the bullet and started integrating MVC into our website so that going forward, we’ll have a cleaner architecture that allows for better testability, separation of concerns, etc. This transition has been a fun and challenging one.

As part of this effort, I’ve done a lot of experimenting with different ways of implementing testable, maintainable views. There are a lot of good threads out there that touch on this. Here are a few that I happened to read this morning:

http://codeclimber.net.nz/archive/2009/10/27/12-asp.net-mvc-best-practices.aspx
http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
http://www.arrangeactassert.com/asp-net-mvc-view-best-practices-keep-logic-out-of-your-views/

A comment in the last thread by Jaime prompted me to write this post. I’m still not completely settled on the details of the techniques I think will work best for us at Pluralsight, but some ideas are definitely crystallizing, so I figured I’d jot them down here.

For one thing, I’ve come to the conclusion that using ViewModels is pretty critical for us, since I want to be able to write automated tests that assure me that the dynamic data I want rendered is likely to actually be rendered. And I want those tests to be exposed to precisely the data that’s going to be rendered in the view – no more and no less. Using domain models directly in views feels like a nice shortcut, but doesn’t lead to this outcome except in very simple cases.

Another goal of mine is to eliminate *all* logic from the views themselves so the views become simply a way to interleave HTML tags with dynamic content.

One of the first habits I worked on breaking was including “if” statements in views to manage optional sections. I used a lot of asp:Panel controls in my WebForm days, and it felt pretty natural to replace those panels with “if” statements in the view. After writing a couple of views this way, I quickly realized I was not going to get the level of testability I wanted. So instead of an “if” in the view checking a flag to see if an optional section should be rendered, I now take that section of the view and make another view model for it. Here’s a view model for showing a pencil with an optional erasor:

namespace SampleViewModels
{
    public class ShowPencil
    {
        public string Brand { get; set; }
        public Erasor Erasor { get; set; }
    }

    public class Erasor
    {
        public string Color { get; set; }
    }
}

Once ShowPencil is constructed, my automated tests can walk over the structure and assert that Erasor is null or not based on the scenario I’m testing. To render the Erasor, I use a partial view, but I don’t use an “if” statement, as you’ll see later.

I used a lot of asp:MultiView controls in my WebForms days. Now if I have a section of the view that needs to render one thing or another depending on business logic, I use a very similar approach to the Erasor, except I more loosely type the link to the child view model, such as I do with Mechanism below:

namespace SampleViewModels
{
    public class ShowPencilSharpener
    {
        public string Brand { get; set; }
        public object Mechanism { get; set; }
    }
    
    public class ElectricSharpeningMechanism
    {
        public int Voltage { get; set; }
    }

    public class MechanicalSharpeningMechanism
    {
        public double ArmLength { get; set; }
    }
}

These techniques allow me to easily test right under the surface of my views. I say “easily” because it’s conceptually easy, but as business logic gets more complicated and views have more optional features, tests get more complicated as well, but that’s the price you pay for complicated business logic.

Now the only trick is to build a set of views and partial views that can render these dynamically structured view models. It turns out the templating features[1] introduced in ASP.NET MVC 2 work very nicely for this. For example, here’s a what a partial view for ShowPencilSharpener might look like:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<SampleViewModels.ShowPencilSharpener>" %>

<div>
Brand: <%: Model.Brand %>
</div>

<%= Html.DisplayFor(model => model.Mechanism) %>

DisplayFor won’t show anything if model.Mechanism is null. But if there’s something there, it will use a well defined template resolution strategy[2] to find an appropriate partial view to use. And the view selected depends on the type of object that my controller (or better yet, my view model builder) put into the Mechanism property.

Let’s say my view model used a MechanicalSharpeningMechanism. I write a custom display template (which is really just a partial view) so I can control how that section of the view should look. Another nice feature of breaking things up like this is that if any other view model uses MechanicalSharpeningMechanism, I can easily reuse that partial view for rendering that part of the view model, if it makes sense to do so. Here’s what that partial view might look like:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<SampleViewModels.MechanicalSharpeningMechanism>" %>

<div>
Arm length: <%: Model.ArmLength %> inches
</div>

This sort of view model composition seems really powerful to me. This morning I’m experimenting with new ways of generating forms based on this idea.

Huge kudos to Brad Wilson for taking the time to walk us all through MVC 2 templates. His lucid explanation made my life much easier when I went searching for a way to render these dynamically structured view models.

[1] http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-1-introduction.html
[2] http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-3-default-templates.html

How to programmatically change the physical directory for a web app in IIS 7.x

keith-brown — Fri, 21 May 2010 14:30:00 GMT

There’s lots of info out there on using Microsoft.Web.Administration to configure IIS programmatically. I personally found most of it rather confusing, and I spent way too much time trying to figure this out, calling GetApplicationHostConfiguration, etc.

There’s a dead simple way to do this that I finally found.

Notes about this code:

The collections return null if they don’t have the thing you are looking for. I’m not checking for that in this sample code.
Don't forget to include a slash in front of your app name.

Edit later same day: Updated code to be more robust by not assuming first vdir is root. Now the code searches for a vdir named "/" under the app.

using Microsoft.Web.Administration;
class Program
{
    // add reference to System.Web
    // and %WINDIR%\system32\inetsrv\Microsoft.Web.Administration.dll
    static void Main()
    {
        const string WebsiteName = "Default Web Site";
        const string AppName = "/test"; // Note: starts with slash
        const string NewPhysicalPath = @"c:\temp\newDir";

        using (var serverManager = new ServerManager())
        {
            var site = serverManager.Sites[WebsiteName];
            var app = site.Applications[AppName];
            var vdir = FindAppVdir(app);
            vdir.PhysicalPath = NewPhysicalPath;
            serverManager.CommitChanges();
        }
    }

    private static VirtualDirectory FindAppVdir(Application app)
    {
        return app
            .VirtualDirectories
            .FirstOrDefault(vdir => vdir.Path == "/");
    }
}

Question to Software Designers: IUser

keith-brown — Thu, 08 Apr 2010 23:09:11 GMT

Even as Web Single Sign On is gaining more and more traction, there’s still churn. I would much prefer to isolate my application developers from the details of whatever library I happen to be using today to get details about my user.

ASP.NET developers are used to getting an IPrincipal (and from that, an IIdentity) from HttpContext.User, WCF’s SecurityContext, etc. But modern web SSO libraries offer more than just the Name and IsInRole() query that these interfaces deliver. And as much as Microsoft may claim that IClaimsIdentity from the Windows Identity Foundation (WIF) is the LAST identity interface we’ll ever see, I’m doubtful. There’s a LOT of churn in the identity space right now. And even if there weren’t a lot of churn, I don’t think I’d want to have my developers worrying about which URI (ClaimType) they should search for to get the user’s email claim. What if there’s more than one? What would that mean?

I’m still of the opinion that an application would benefit from having a custom interface that encapsulated all of the identity needs for that application. It might be as simple as this:

public interface IUser
{
    string Name { get; }
    string Email { get; }
    bool IsInRole(string role);
}

I threw IsInRole and Name in the mix for convenience; these are also available on the default IPrincipal/IIdentity pair that you get from ASP.NET, WCF, etc. Email is the interesting addition here.

The question I have for you, readers, has nothing to do with the structure of IUser itself, but rather, how would you suggest *getting* to a concrete implementation of it? Is this the sort of thing you’d want in an Inversion of Control Container, for example? Or would you prefer to hang this off of a custom principal object that you’d hang off of HttpContext.User?

Seems like using HttpContext.User makes it less unit-testable because then your code depends on HttpContext.

While we’re at it, does it offend you that I didn’t derive IUser from IPrincipal? If I had done that, it would imply that you could get to an IClaimsIdentity in order to get to extra stuff without changing the IUser interface. But that wasn’t the intent.

I’d love your feedback! Keep in mind that comments are moderated so it may take a day or so for your comments to appear here (blame the spammers for this annoyance, sorry!)

My DevWeek slides and demos

keith-brown — Sun, 21 Mar 2010 21:20:00 GMT

Get them here.

Thanks to all who joined me - I had a great time in London!

Be certain to redeem your Pluralsight On-Demand trial subscriptions, guys!

Labs for my Attack/Defence talk today at DevWeek

keith-brown — Thu, 18 Mar 2010 13:53:00 GMT

For those who were in my talk today, I mentioned that the SQL injection and XSS demos are actually labs that you can find on the Internet.

Here's links to them. I built these for Patterns & Practices a few years ago.

http://channel9.msdn.com/Wiki/SecurityWiki/InputValidationTrainingModules/

There's more here than just the two I mentioned - enjoy!

Keith

Rocky Mountain Tech Trifecta

keith-brown — Mon, 01 Mar 2010 16:33:00 GMT

Thanks to Julie and David for inviting me to speak this past weekend in Denver. I hope I opened some eyes to the direction the industry is headed with identity and single sign on!

You can find my slides here.

For those who attended, don't forget to redeem your trial coupons for Pluralsight On-Demand! training. Five days of access to all of our content should give you enough time to take a full course. Tell your friends if you like what you see!

Did FxCop tell you to use System.Uri?

keith-brown — Sat, 10 Oct 2009 18:28:42 GMT

It told me to do that. And silly me, I took the advice.

Maybe it wasn’t silly advice at all. But when, like me, you’ve been used to programming ASP.NET for years (which does NOT follow this advice) and you flip over to use the Uri class to represent URI instead of raw strings (like ASP.NET still does), you will be in for a few surprises that may hurt you down the road.

Don’t get me wrong. This is a bit of a rant, and I recommend using System.Uri. But I can recommend using it only after you’re aware of the gotchas.

1) System.Uri is not at all friendly to relative URI.

Many of the most useful properties that help you parse a URI are simply not supported for relative URI. Get used to your code compiling fine and then at runtime seeing InvalidOperationException thrown when you try to access helpful properties such as Uri.Query, etc. Sure seems like it would be helpful to have an HttpUri derived class that *would* know how to work with relative HTTP URI. I would certainly use it!

My recommendation to avoid surprises here? Test evey line of code that uses System.Uri with relative URI. Now some code will be specifically designed to work only with absolute URI, and in that case, you should use the Uri.IsAbsoluteUri property to confirm your assumption as part of that code.

2) Beware converting System.Uri to its string value.

Use Uri.AbsoluteUri to pull out the string value when you know you’ve got an absolute URI.

If the Uri could be relative, AbsoluteUri will throw InvalidOperationException (because, well, it’s not an absolute URI). But don’t fall back and call Uri.ToString instead like I did. Prefer Uri.OriginalString which acts more like Uri.AbsoluteUri in that it does not transform the URI before returning it like Uri.ToString does (Uri.ToString unescapes the URI which could leave you with a bug that only shows up occasionally).

3) Take what the debugger shows you about System.Uri with a grain of salt.

The debugger appears to call Uri.ToString to show you the value of a URI. This will confuse the heck out of you when you’re looking at a URI that you KNOW contains escaped characters, because it will appear as if the URI has been unescaped. If you think you’re a victim of this treachery, set your watch on the OriginalString property of your Uri instead and breathe a sigh of relief that you are not crazy after all.

Microsoft should practice what they preach.

If ASP.NET used the URI class like FxCop tells us we should, it’d be much harder to run into problems with (2) because developers wouldn’t be worried about converting back and forth between System.Uri and strings. Indeed when you program ASP.NET it’s actually harder to write correct code using System.Uri because of these required conversions. You certainly do need to think a lot harder when using System.Uri. I think the ASP.NET team should talk with the FxCop team and get their story straight. Either use URI everywhere, or strings everywhere. Expecting imperfect developers (like me) to deal with this boundary is just asking for trouble, IMHO.

Thanks for listening to my little rant. I hope this spares somebody else the headaches I’ve endured trying to use System.Uri in my ASP.NET web apps.

Beware Uri.ToString

keith-brown — Sat, 10 Oct 2009 18:04:20 GMT

I admit it. System.Uri (from the .NET Framework) has had me fooled for a long time. Normally when I need to extract the string value of a Uri instance, I use the AbsoluteUri method to do that. But that doesn’t work when the Uri instance models a relative URI. Indeed support for relative URI in the Uri class is almost nonexistant (makes me wish for a derived class called HttpUri that *would* allow you to work with relative URI, but that’s a topic for another day).

So the quick and dirty fallback I took when I wasn’t sure what type of Uri I had was to call ToString() to get the value of the URI (typically to pass to Response.Redirect, which sadly doesn’t use the Uri class, but expects a string). And this works just dandy until you get a Uri that has escaped characters in it that need to stay escaped for things to work properly (the example that killed me was ReturnUrl for Forms auth in ASP.NET).

The problem with carelessly using Uri.ToString is that it unescapes the URI before returning it.

That bears repeating, in bold.

Uri.ToString unescapes the URI before returning it.

The documentation for this method clearly states that this happens. But if you’re not thinking about escaped characters when you write your code, you’re not going to notice that anything’s wrong until it actually encounters certain escape sequences (in my case, the ReturnUrl was being truncated after an escaped ampersand got unescaped by Uri.ToString).

This can be really confusing while debugging…

…when for example, you hover your mouse over a variable of type System.Uri in the debugger. Because the debugger calls ToString() to get a string to display (at least I assume this is what’s happening, because if you set a watch on a System.Uri object, what you see will be different than if you watched its OriginalString or AbsoluteUri property instead, if there are escaped chars in the URI). This fooled me for a long time. But no longer! Now I know to take what the debugger shows for a Uri object with a grain of salt.

Unless you *really* want to unescape the URI, when writing code that uses the System.Uri class, I’d recommend using Uri.OriginalString instead of ToString to get the value of a Uri that may be absolute or relative. That will *not* unescape the string, and it’s one of the few properties on the Uri class that don’t throw an InvalidOperationException for a relative URI.

Here are my new personal rules that I’m going to use when using the System.Uri class:

Use Uri.AbsoluteUri to get the value of a URI when you know it’s absolute.

Use Uri.OriginalString to get the value of a URI when it could be either absolute or relative.

Use Uri.ToString to get the value of a URI only when you really want it to be unescaped (e.g. when you want to display it nicely for a human).

I hope this saves you a headache like the one I’ve had trying to track down the silly bug that this caused in our website.

What goes into claims

keith-brown — Wed, 07 Oct 2009 18:52:45 GMT

I love the pictures that Vittorio uses in this post. While I’ve always thought of issuers as “caring” for their users (in the case where the issuer is acting as an identity provider) or “caring” for their apps (in the case where the issuer is designed to issue tokens with claims specific to an app), Vittorio takes it a step further and shows the boundaries at which the user’s token can be “enriched” by authorities as these boundaries are crossed. I think this is an excellent way to think about things.

Now that there’s actually something to toy with, as opposed to hand-weave how beautiful a claims-flavoured world would be, I distinctly felt a change in the kind of questions I get: more pragmatic, aimed at understanding how to solve specific *practical* (as opposed to hypothetical) problems or how to integrate with existing assets. One thing that really surprised me is how difficult it could be for people to understand what to put in claims, or who is supposed to add what/where, and so on. There is surprisingly little in literature about this: or rather, this should not surprise at all since the tools that would enable the industry to even pose the question are emerging just now.

So, after so many practical/basic posts lately here there’s some scatter consideration about what should go into claims…

We’re still a ways from being able to prescribe detailed guidance for what to put into claims, where to put it, etc. but this is a step in the right direction. Thanks, Vittorio.

Using LET in LINQ with extension method syntax

keith-brown — Wed, 07 Oct 2009 17:53:03 GMT

For a variety of reasons (many of which Scott Allen discusses in his wonderful LINQ course), I prefer to use extension method syntax with LINQ instead of query expression syntax. But one thing I miss is the “let” operation that allows me to compute intermediate results and store them in a new variable.

This morning I came across a case where this would really simplify things, so I sat down to remember how to do it (I know I’ve done it before but I couldn’t remember the trick). So I wrote the simplest query I could think of using LET…

string[] input = { "asdf", "asd", "as", "a" };

IEnumerable<string> results =
    from s in input
    let x = s.Length
    select string.Format("{0} ({1})", s, x);

Print(results);

…and looked at it with RedGate Reflector, and remembered how I’d done this before – by introducing an enveloping anonymous type. Here’s the equivalent using extension methods:

results = input
    .Select(s => new { s = s, x = s.Length })
    .Select(e => string.Format("{0} ({1})", e.s, e.x));

Both of these queries produce the same results:

asdf (4)
asd (3)
as (2)
a (1)

There’s an object being processed in the pipeline – in this case it’s a string. The trick is to envelope that object with an anonymous type so that you can add one or more sibling variables that travel with it through the pipeline. The variable “e” in this example is the envelope.

It’s not often I need LET, but when I do, I’ll be glad I jotted this down.