It doesn’t matter how you’re orchestrating each instance of your application. Whether each instance is hosted on its own virtual machine, inside a container, has its own physical server, or some combination of the above. You’ll still run into the issue of moving state to a centralized place where all instances can access it.

The application probably already does this for most of its state. For example, most of the application’s data probably lives in some sort of centralized database, like PostgreSQL or MySQL. If this isn’t the case, then that would be step one for scaling the application across multiple instances.

I believe that any running instance should be able to handle any request. When a client uses a web application, each request from the browser should be able to be handled by different backend servers, and the client application shouldn’t know or care.

Session Data

How about session data that’s being stored on the server that handled the request, unavailable to other instances? Many technology stacks are configured by default to work this way.

I prefer updating the session storage of the framework I’m using to store that data in something like redis. The redis server now becomes the central location which instances hit to load the data it needs for that user’s session.

Third Party Libraries

Scaling your application also requires knowledge about how the third party libraries your application uses. For example, does your .NET application use NHibernate second-level caching? For ease, it may have been setup to use one of the built in memory caches, such as CoreMemoryCache, RtMemoryCache, SysCache, or SysCache2. If you were previously hosting on a single instance, that’s not a problem. But now that you’re trying to spread the load across multiple instances, you may start seeing really odd caching patterns. The cache might be updated in one instance but not others. Maybe your application begins hitting your database more than expected because each instance starts with a cold cache.

This is a single example, but you’ll want to be knowledgable about the third party libraries your application uses, what features you’re using, and if that’s going to cause trouble when trying to scale your application.

Sticky Sessions

When load balancers say they can do sticky sessions, that means that the load balancer will do its best to ensure that all requests for that user’s session go to the same backend instance. This is often done by injecting a cookie in the first response for that user that the load balancer can then read back on subsequent requests to route the request to the same backend instance that serviced the first request.

At first glance, this solves the issue of user specific data being on a single instance. Users will be stuck to the instance that has their data, great! But in a way, it kicks the problem down the road and begs new questions.

What happens when you deploy new code and the instance comes down for updates? What happens if the instance crashes for any reason? You can’t garuntee that an instance will be available for the duration of a user’s session. Because of that, you still have to consider situations where requests for the same user’s session go to different instances.

I don’t think using sticky sessions is always a bad thing, however it would be a last resort option. There are some advanced situations where you might want to ensure a user gets pinned to a specific instance. You could do this to ensure the instance has a hot cache for user specific, often accessed, difficult to compute data. However, I would only go that route after having ruled out denormalizing that data in the main datastore or caching the data in something like redis where any instance would have access.

Installing OpenBSD

My laptop doesn’t have a supported wireless adapter, so I’m unable to download the file sets during the installation process. Because of that, I need to make sure I have the file sets included on the disk image. For my installation, I downloaded the installXX.fs disk image which includes the file sets. If your wireless adapter is supported and you have internet access during the installation process, you could use minirootXX.fs and download the file sets during installation.

I created a bootable USB flash drive with Rufus. Then, I booted my laptop up with the flash drive in UEFI mode. When prompted, I opted for the (S)hell insetad of starting the installer so I could prepare the a special EFI system parittion where the UEFI bootloader would be copied after installation.

I installed to sd0 so I ran the following command to initialize the partition table.

1

fdisk -i -b 960 sd0

After this, I ran install to start the installer. When I got to the portion about disk layout, I chose the OpenBSD option.

After installation, when it prompted to reboot, I went back into the (S)hell and ran the following commands to format the partition and copy the UEFI bootloader.

1
2
3
4

/mnt/sbin/newfs_msdos sd0i
mount /dev/sd0i /mnt2
mkdir -p /mnt2/efi/boot
cp /mnt/usr/mdec/BOOTX64.EFI /mnt2/efi/boot

I then rebooted the machine and everything came up without an issue.

Setting up doas

You’ll want to setup doas so you can run commands with root permissions without having to be logged in as root. This will also allow you to skip having to enter a password. doas is OpenBSD’s version of sudo.

1

# echo 'permit nopass username' > /etc/doas.conf

Improving Disk Performance

To increase disk performance, there are a couple of options we can enable in /etc/fstab.

The noatime option will stop updating the time that files are accessed. This means that reading a file won’t also include a write to update the access time, so it can reduce disk activity.

The softdep option makes metadata stop being written immediately and instead will write it “in an ordered fasion to keep the on-disk state of the file system consistent.” It can result in significant speedups for file create/delete operations. This can only be used with partitions formatted with the Fast File System (FFS).

To apply these changes, replace any rw in /etc/fstab with rw,softdep,noatime. Make a backup to /etc/fstab.bak incase anything goes wrong, you can go back to the old version without any trouble.

1

# sed -i.bak 's/rw/rw,softdep,noatime/' /etc/fstab

Reboot after this to apply the changes when the file systems are mounted again.

Installing firmware for USB Wireless Adapter

As I mentioned above, my laptop’s built in wireless adapter (Broadcom BCM4313) isn’t supported at all by OpenBSD. In order to get an internet connection, I bought an Edimax EW-7811Un for $10 off of Amazon which is supported by the urtwn firmware. The connection is a bit lackluster, I’m maxing out at around 7Mpbs down and 500Kbps up, however it’s very small and doesn’t have a huge antenna sticking out.

In order to get the firmware, I had to download it from the OpenBSD firmware server and save it to a flash drive on another computer. Once I got the firmware on a flash drive, I popped it in, figured out which parition I had written it to, mounted it, and installed it.

When you insert your flash drive, the name of the device will show up in xconsole. It will look similar to this:

1
2

sd1 at scsibus4 targ 1 lun 0: <Samsung, Flash Drive, 1100>
sd1: 30594MB, 512 bytes/sector, 62656641 sectors

After seeing this, I could tell that my USB flash drive was labeled sd1.

I then needed to figure out which partition I had written it to. I’ve heard you can assume i, but I like to double check.

1
2
3
4

# disklabel sd1
#        size       offset   fstype
  c:   ######            0   unused
  i:   ######         ####    MSDOS

From this I could tell that my information was on the i partition, because it’s formatted using MSDOS.

I then mounted and installed the firmware.

1
2
3

# mkdir -p /mnt/usb
# mount /dev/sd1i /mnt/usb
# fw_update -p /mnt/usb urtwn

Setting up the Wireless Connection

OpenBSD 6.4 introduced support to auto-join wireless networks. What this means is that OpenBSD can remember all of the networks you want to connect to along with all of their security settings. It will then decide which network to connect to and automatically switch when that network is no longer available and another is in range.

According to Peter Hessler, the developer that worked on auto-join:

It basically uses the Apple algorithm that is used on iPhones. As long the signal strength is good enough: Strongest security, then 5GHz, then 11n vs not-n, then pure signal strength.
You can also force it to choose a different one with “nwid foo”. The auto-join algorithm will take the saved security settings for “foo” and apply them when it attempts to connect.

We want our network connection to automatically come up when we boot. In order to do this, we’ll need to create a /etc/hostname.if file. You’ll replace the extension if with your wireless interface name. For me, the file is /etc/hostname.urtwn0. When I was first setting up my wireless connection, I thought that hostname needed to be replaced with the actual hostname of my machine. That is NOT the case, my file is literally named /etc/hostname.urtwn0.

To use auto-join, we’ll use the join option followed by the network id and any necessary wpakey or nwkey arguments.

1
2
3
4
5
6

join NETWORKID wpakey PASSWORD
join coffee-shop
join "wepnetwork" nwkey "12345"
dhcp
inet6 autoconf
up

You can list as many join statements as you’d like and OpenBSD will switch between them as the networks disappear and become available.

Overriding DNS Servers

The wireless router provided by my ISP doesn’t allow me to set my DNS servers that are broadcast by its DHCP server. Since I don’t want to use my ISP’s DNS servers, I need to tell dhclient not to write the DNS servers it gets when establishing my network connection.

Create a /etc/dhclient.conf file and enter the following:

1
2

supersede domain-name-servers 1.1.1.1, 1.0.0.1;
ignore domain-name;

This will replace the DNS servers that dhclient gets from the network’s DHCP server with the servers you specify, Cloudflare’s DNS in this case. My ISP also tries to set a search domain, which I’m telling dhclient to ignore.

You may want to use prepend insetad of supersede for the DNS servers. Doing this would make dhclient prefer the DNS servers you specify, but fall back to the DNS servers it got via DHCP.

Setting up the Install URL

Now that we have our internet connection setup, we’re going to want to install system patches and add packages. Before we can do that, though, we’ll want to make sure we have a mirror set in /etc/installurl. This tells the OpenBSD tools where it should attempt to download packages and patches. This is setup by default in 6.4, but if yours is empty for some reason, set it.

I chose to use the CDN so I don’t have to worry about which mirror is closest. This is also the default in 6.4.

1

# echo 'https://cdn.openbsd.org/pub/OpenBSD' > /etc/installurl

Installing System Patches

To update your system with the latest patches, run syspatch. This will install patches for issues that have been fixed since the release of the version you’re installing. If there are no patches to install, this will do nothing.

You can check which patches will be installed by looking over the errata.

1

# syspatch

Install Firmware

We manually downloaded and installed the firmware for our wireless adapter because we didn’t already have an internet connection. Now that we have a connection, we can download the rest of the firmware that our computer might need.

1

# fw_udpate

Configuring Power Management

If you’re running on a laptop, you may want to enable the Advanced Power Management daemon or apmd. This will automatically tune your performance to help conserve battery and will also automatically hibernate or suspend your machine if your battery drops below the specified percentage.

With these commands we’re telling rc to start apmd when the system starts, setting the flags for rc to pass apmd when it starts, and starting it manually.

The flags we’re telling rc to pass to apmd are:

• -A to start in automatic performance adjustment mode
• -z 7 to automatically suspend the system if the battery is at or below 7% battery, and the system is currently not plugged in.

Check man apmd for more options.

1
2
3
4

# rcctl enable apmd
# rcctl set apmd flags -A -z 7
# rcctl start apmd
apmd(ok)

References

While I was setting up my machine, I found and used several guides. I’ve decided to merge them into a single post for myself, and anyone else that might find this, to reference later.

• Derek Sivers
• Jasper Lievisse Adriaanse
• OpenBSD Journal
• Roman Zolotarev

Also, the OpenBSD man pages are very thorough and accessible. For more information on any of the steps in this post, check out the man pages.

1
2
3
4
5
6
7
8
9
10
11
12
13

# man fdisk
# man doas
# man doas.conf
# man fstab
# man mount
# man disklabel
# man fw_update
# man ifconfig
# man hostname.if
# man dhclient.conf
# man syspatch
# man apmd
# man rcctl

After thinking about it a little more, I was asking myself, why I should even have to care that a package I want to take a dependency on is relying on something else? Why should I need to setup assembly bindings to try to redirect dependent assemblies to higher or lower versions based on what the rest of my application is running?

Then the idea hit me to ditch the nuget package all together. I decided to grab the assembly I wanted to use, and the version of Newtonsoft.Json that it depends on and merge them into one. This allows me to have a single assembly without having to worry about whether or not it’s dependencies are going to play nice with the rest of the application.

To do this, I put the two assemblies I wanted to merge into a folder, renamed the original assembly to <assembly>.old.dll and ran the following command.

ILMerge.exe /out:<assembly>.dll /internalize /target:library /targetplatform:v4,C:\Windows\Microsoft.net\Framework64\v4.0.30319 .\<assembly>.old.dll .\Newtonsoft.Json.dll

Here’s a breakdown of what that command does:

• /out:<assembly>.dll outputs the result to <assembly>.dll.
• /internalize marks all assemblies that are being merged into the first specified assembly as internal. This is important, as it makes sure we don’t have duplicate namespaces with our other reference to Newtonsoft.Json.
• /target:library tells ILMerge that we’re merging assemblies, you can also use /target:exe if you’re merging into an executable.
• /targetplatform:v4,C:\Windows\Microsoft.net\Framework64\v4.0.30319 lets ILMerge know that the new assembly should target .NET 4.
• .\<assembly>.old.dll this is the first assembly that we specify, so it’s going to be the one that’s not marked as internal. This should always be the main dependency that you want access to from your application.
• .\Newtonsoft.Json.dll this is the assembly you want to merge in.
• .\<another_assembly>.dll You can tack on as many assemblies at the end as you want. It will merge them all into a single dll.

After the merge was complete, I was able to add a reference to the produced dll. This worked just like the nuget package version, except I didn’t have to worry about the Newtonsoft.Json dependency, at all.

In the near future, I’m planning on submitting a pull request to the repository of the nuget package that I had issues with. Hopefully if it’s accepted the nuget package will no longer have any dependencies and will be a little easier to work with.

On the surface, this seems like a great way to deal with dependencies of nuget packages. However, I feel like since it’s not wide-spread and we’re all still dealing with these upgrade issues that there’s a catch I’m not seeing. Let me know on twitter or by email what I’m missing.

I wanted to use RabbitMQ because I’ve been hearing a lot of great things about it. It has a really nice web interface you can use to check on the status of your queues and see how many messages are passing through. Also, since I had used MassTransit in the past with MSMQ, and MassTransit now supports RabbitMQ, I figured it’d be a breeze to setup.

RabbitMQ was very easy to get up and running, along with the plugin for the web interface. It turns out I don’t remember as much as I thought I did about MassTransit, but Joshua Arnold was able to help me get setup pretty quick and I had messages flowing through RabbitMQ in what seemed like no time at all.

The message rate is very slow… I realized that I’m only able to publish about 3,000 messages per second to the message queue. After taking MassTransit out of the mix and publishing directly to RabbitMQ, that number raises to about 10,000 messages per second. If I don’t publish any messages at all and only parse the data from the file, I can parse about 450,000 messages per second. So, RabbitMQ and MassTransit are causing a bottleneck.

Consuming messages is even slower. I got MassTransit to pull messages off the queue at a top speed of about 1,200 messages per second. Way too slow to keep up with a trading day, where I think I would need to be able to handle at least 20,000 messages per second in order to keep up with bursts of traffic.

After doing a little digging, I found a nice comparison of some different queues. It sounds to me like ZeroMQ would be a perfect fit for this project. If I have some free time I’m going to give it a shot and see if it performs as well as they say.

Take a look at the code and let me know what you think: http://github.com/RexMorgan/Itch

In this post I’m going to explain how FubuMVC allows you to perform these actions. In a multi-tenant application I’m working on, I handle all default requests to many domains with a single action in my FubuMVC application. I want to choose which behavior chain to run, depending on the URL that the user has browsed to.

An example of this, just to make sure I’m explaining this properly, is Tumblr. Browsing to tumblr.com should display the home page for Tumblr (sign up form, information about why Tumblr is great, etc). However, browsing to {username}.tumblr.com should display the posts by that particular user. (I honestly don’t know if this is handled by a single piece of code on Tumblr, but I’d like to mimic this, with a single piece of code, in my project.)

To start, I’m going to create a FrontLoaderEnpoint that all default requests will go through.

In my FrontLoaderEndpoint, I need to check what URL the user is coming from. In order to do this, I have a property called HTTP_HOST on my input model. FubuMVC will automatically fill in the information from the ServerVariables collection._ (I hate to just leave it as this “just works”, but model binding will be the topic of another blog post.)_

Now I’m taking the HTTP_HOST from the input model and attempting to look up the user that the domain belongs to.

If there is a user that is using the domain, then I’m going to go ahead and transfer the request to the endpoint that handles the user specific domains. I tell FubuMVC that I want to transfer the user by returning FubuContinuation.TransferTo. The TransferTo method takes in the input model of the action that you want to call.

If there’s not a user found for the domain, I’m going to redirect the user to the home page (which allows new users to sign up, etc). To redirect the user I return FubuContinuation.RedirectTo and, just like the TransferTo method, pass in the input model of the action I want to redirect the user to.

public class FrontLoaderRequestModel{    public string HTTP_HOST { get; set; }}public class FrontLoaderEndpoint{    private readonly IUserRepository _userRepository;        public FrontLoaderEndpoint(IUserRepository userRepository)    {        _userRepository = userRepository;    }    public FubuContinuation Get(FrontLoaderRequestModel input)    {        var user = _userRepository.GetByDomain(input.HTTP_HOST);                if(user != null)        {            return FubuContinuation.TransferTo(new UserSpecificIndexRequestModel                                                    {                                                        User = user                                                    });        }        return FubuContinuation.RedirectTo(new HomeRequestModel());    }}

How does it work? 

The way this works is RedirectTo and TransferTo are both static methods on the FubuContinuation class, which return a FubuContinuation object. In the constructor of the FubuContinuation object, it takes in the ContinuationType (Redirect, Transfer, or NextBehavior) and an action that should be called on the IContinuationDirector.

The IContinuationDirector is what actually does all of the work, by calling RedirectToUrl on the IOutputWriter if you’re doing a redirect (just like I did in Step 2 of FubuMVC: Authentication.), or building a partial from the IPartialFactory and invoking it, if you’re doing a transfer. The action to call is resolved using the input model that you provided when you called FubuContinuation.RedirectTo / FubuContinuation.TransferTo. Since we’re using the thunderdome pattern, each of our actions are uniquely defined by the type of the input model.

Internally, FubuMVC has a built-in convention which gets run. This convention checks for any actions that have a FubuContinuation as an output type. If it finds one, it adds an internal behavior called ContinuationHandler directly after the action call.

When the ContinuationHandler gets called, it pulls the FubuContinuation that was set in my action call from the IFubuRequest and calls Process on it, passing into it, “this” (the ContinuationHandler being called.) The Process method calls the action that was passed into the FubuContinuation constructor and passes int he ContinuationHandler that’s being run. (Note: ContinuationHandler implements IContinuationDirector.)

Bonus!

If you want to redirect the user to a URL of an outside site, just pass the URL directly into FubuContinuation.RedirectTo. The ContinuationHandler has a mechanism in place to redirect directly to a URL if it’s provided as a string.

Origins

From the articles I can find online, the thunderdome pattern was created as a way to increase testability of your actions. By only allowing a single model in, it’s very easy to setup the context of the test. It also removes the need to rely on the HttpContext inside the actions. In FubuMVC, if information is needed from the HttpContext, a property can be added to the input model and it’s the responsibility of model binding to set that property to the corresponding value in the HttpContext._ (Model Binding will be the topic of another post.)_

Benefits

Once you decide to use the thunderdome pattern, it’s not a big step to make each of the actions take a unique input model. If each behavior chain has a unique input model, then each behavior chain can be identified by its input type. This is a great way, in my opinion, to take advantage of static typing and make it work for you.

In FubuMVC, this is the most common way to identify behavior chains. Since each behavior chain is associated to a route, it’s the most common way to build URLs, also.

Other Patterns

It’s important to note that the thunderdome pattern is not the only way to use FubuMVC. All of the combinations of One/Zero model in One/Zero model out patterns are supported. I can see using a one model in, zero model out for use of services where you only care about the HTTP Response code. (If you want to do this with the thunderdome pattern, you can just return an HttpStatusCode from your action. There’s a built in convention in FubuMVC to handle this return type.)

I don’t use either of the patterns which do not have an input model. If I have an action that doesn’t have any input, then I typically have it accept an empty “marker” input model, anyway. This gives me the ability to uniquely identify it if I ever need to create a link to it, or for any other reason.

In this post, I’ll be going over how to write a custom authorization rule to keep users from being able to edit another user’s blog post in a simple blogging application. I’ll do this by plugging into the authorization facilities built into FubuMVC.

Overview

1. Come up with a convention to identify which action calls need authorization, and how to access the information we need from the input models
2. Do the heavy lifting by writing an authorization policy to check and see if the user is authorized to do what they’re trying to do
3. Teach FubuMVC about the convention
4. Tell FubuMVC to use the convention

Step 1: Come up with a convention

In order to figure out which routes/action calls need authorization, I’m going to implement an interface on my input models. This will not only mark them so I can look them up later, but also provide me with a generic way of accessing the properties that I’m going to be running my authorization code against. In this case, all I need from the models are the post id, so that’s all that’s required on the interface. It’s also worth noting here that I have two input models. I use EditPostRequestModel for the http get action call (to get the post in order to display it for the user to edit), and the EditPostInputModel for the http post action call (which handles the saving of the post after it’s been edited by the user.)

public interface IPostModel{    int PostId { get; }}public class EditPostInputModel : IPostModel{    public int PostId { get; set; }    public string Title { get; set; }    public string Body { get; set; }    public string Slug { get; set; }}public class EditPostRequestModel : IPostModel{    public int PostId { get; set; }    public string Title { get; set; }    public string Body { get; set; }    public string Slug { get; set; }}

Step 2: Do the heavy lifting

Now that I’ve marked which actions need authorization, I’m going to write an authorization policy so I can specify how that authorization needs to be done. In this case I want to verify that the post being requested belongs to the user that is requesting it. This is a simple example, but you can do any sort of complex checking here that you wanted (e.g. If it were possible that your users could be editors and edit other user’s posts, that check would go here.)

For my simple case, we can just check that the user property on the requested post, is the same user as the user that’s currently logged in. The CurrentUser dependency is what I use to get the currently logged in user. Use whatever your convention is to do that here, instead.

public class PostAuthorizationPolicy<TModel> : IAuthorizationPolicy    where TModel : class, IPostModel{    private readonly IPostRepository _postRepository;    private readonly CurrentUser _currentUser;    public PostAuthorizationPolicy(IPostRepository postRepository, CurrentUser currentUser)    {        _postRepository = postRepository;        _currentUser = currentUser;    }    public AuthorizationRight RightsFor(IFubuRequest request)    {        var model = request.Get<TModel>();        if (model == null)        {            return AuthorizationRight.Deny;        }        var post = _postRepository.GetById(model.PostId);        if (post == null)        {            return AuthorizationRight.Deny;        }        return post.User.Id == _currentUser.UserId                    ? AuthorizationRight.Allow                    : AuthorizationRight.Deny;    }}

Step 3: Teach FubuMVC about the convention

So, I have my action calls setup that need authorization, and I’ve created a way to do that authorization, the next step is to tie the two together and tell FubuMVC how to apply my authorization policy.

FubuMVC has a DSL to do this, which can be accessed through the Authorization property on the behavior chain. The way this works is inside FubuMVC, after it has applied all of your conventions, it will check to see if there have been any policies added to the Authorization property on the behavior chain. If it finds that there has been, it will wrap the chain with an internal behavior called AuthorizationBehavior.

The way the AuthorizationBehavior works is by calling the authorization policies for the behavior and checking the return value of them. If any of the policies return AuthorizationRight.Deny, then the chain is stopped and IAuthorizationFailureHandler is called on to handle the erred request.

It’s very important that FubuMVC sets this convention up after it sets up all of the custom conventions. This ensures that the AuthenticationBehavior gets run before anything else in the behavior chain.

What I want to do is add a policy to the Authorization property for all action calls which have an input type that implements my IPostModel interface.

Since I made the policy an open generic, I’ll close that generic with the type that the action call is using. This is what allows the authorization policy to get the model out of the IFubuRequest (since things are keyed by type), which means I can check values specific to that particular request.

public class PostAuthorizationConvention : IConfigurationAction{    public void Configure(BehaviorGraph graph)    {        graph            .Behaviors            .Where(c => typeof (IPostModel).IsAssignableFrom(c.InputType()))            .Each(chain => chain                                .Authorization                                .AddPolicy(typeof (PostAuthorizationPolicy<>).MakeGenericType(chain.InputType())));    }}

Step 4: Tell FubuMVC to use the convention

Now that everything is all setup and I’ve defined how my convention works, I just have to tell FubuMVC to use the convention. To do this, in my FubuRegistry, I just add the following line.

Policies.Add<PostAuthorizationConvention>();

Now when I start up the application and browse to /post/edit/:id, I get a 403 forbidden message if the id is for a post that isn’t mine. If the post is mine, I’m allowed to pass right through to the rest of the chain.

Bonus!

What if I don’t want to return a 403 forbidden message? I want to do something unique and special!

Remember when I said that the AuthorizationBehavior will call on IAuthorizationFailureHandler if any of the policies go wrong in order to handle the authorization error? Well, all you have to do is implement your own IAuthorizationFailureHandler and tell FubuMVC to replace the default implementation with your custom one, in your FubuRegistry.

public class CustomAuthorizationFailureHandler : IAuthorizationFailureHandler{    private readonly IOutputWriter _writer;    private readonly IUrlRegistry _urlRegistry;    public CustomAuthorizationFailureHandler(IOutputWriter writer, IUrlRegistry urlRegistry)    {        _writer = writer;        _urlRegistry = urlRegistry;    }    public void Handle()    {        // Get the url to the login page, and redirect the user there!        var url = _urlRegistry.UrlFor(new LoginRequestModel());        _writer.RedirectToUrl(url);    }}// In the registryServices(x => { x.ReplaceService<IAuthorizationFailureHandler, CustomAuthorizationFailureHandler>(); });

Now when I attempt to browse to /post/edit/:id, if I don’t own the post, I get redirected to the login screen.

I’m going to write an authentication convention to block access to certain actions from unauthenticated users.

Overview

1. Come up with a convention to determine which action calls require the user to be authenticated
2. Write a behavior to redirect a user if they’re not authenticated
3. Teach FubuMVC about the convention
4. Tell FubuMVC to use the convention
5. Let FubuMVC know when someone has logged in or out

Step 1: Come up with a convention

For this example, my convention is going to be any action call marked with a [Secured] attribute, will require an authenticated user in order to execute. As you’ll see, this can be adapted to match whatever convention you want to use.

To start, I’ll just create a simple marker attribute and throw it on the action calls that I want to be secured.

public class SecuredAttribute : Attribute{}public class DashboardEndpoint{    [Secured]    public DashboardRequestModel Get(DashboardRequestModel input)    {        return new DashboardRequestModel();    }}

Since we’ve marked the action calls that we want to secure, we’ll be able to pick them out later when we want to teach FubuMVC about our convention.

Step 2: Write a behavior

In order to do the actual work of checking to see if the user is logged in, and redirecting them if they’re not, I’ll need to create a behavior. If you’re unfamiliar with behaviors, I’d highly recommend reading these articles about them.

The behavior will depend on the ISecurityContext provided by FubuMVC, so I can check if the user has been authenticated. If the user has not been authenticated, I’ll just redirect them to the login page.

It’s important to note that, by default, the ISecurityContext is a wrapper around the current HttpContext. This means that FubuMVC is really just using standard ASP.NET forms authentication.

When FubuMVC calls the behavior, it will look at the result coming from the performInvoke() method. If the method returns DoNext.Continue, then the next behavior in the chain will be called. However, if it returns DoNext.Stop, then it will not call the next behavior in the chain and execution of the request stops. (It actually doesn’t just stop, if you’ve been through any behaviors that wrap the authentication behavior, you will begin to start calling the afterInsideBehavior method on these.

public class AuthenticationRequiredBehavior : BasicBehavior{    private readonly ISecurityContext _securityContext;    private readonly IUrlRegistry _urlRegistry;    private readonly IOutputWriter _outputWriter;    public AuthenticationRequiredBehavior(ISecurityContext securityContext, IUrlRegistry urlRegistry, IOutputWriter outputWriter)        : base(PartialBehavior.Ignored)    {        _securityContext = securityContext;        _urlRegistry = urlRegistry;        _outputWriter = outputWriter;    }    protected override DoNext performInvoke()    {        if(_securityContext.IsAuthenticated())        {            return DoNext.Continue;        }        var url = _urlRegistry.UrlFor(new LoginRequestModel());        _outputWriter.RedirectToUrl(url);        return DoNext.Stop;    }}

Step 3: Teach FubuMVC about the convention

So I’ve setup our action calls to use the convention and the behavior to kick unauthorized people out. Now I just need to teach FubuMVC what that convention is, and how it should be implemented. In order to do that, I’ll need to create an implementation of the IConfigurationAction interface (these are typically called conventions.) My convention will modify the graph and wrap all action calls that have the Secured attribute with our behavior.

In the convention, I have access to all of the Actions that FubuMVC knows about. I’m able to filter those actions to only get those which implement the SecuredAttribute, and then wrap those with the behavior I just created.

public class AuthenticationConvention : IConfigurationAction{    public void Configure(BehaviorGraph graph)    {        graph            .Actions()            .Where(c => c.HasAttribute<SecuredAttribute>())            .Each(c => c.WrapWith<AuthenticationRequiredBehavior>());    }}

This is where I could change it up and use another convention if I wanted to. Instead of filtering the actions based on attributes, I can check for anything. If I wanted to filter for all actions with an input type that starts with “Add” or “Edit”, that’s possible by using this convention.

graph    .Actions()    .Where(c => c.HasInput && c.InputType().Name.StartsWith("Add") || c.InputType().Name.StartsWith("Edit"))    .Each(c => c.WrapWith<AuthenticationRequiredBehavior>());

Step 4: Tell FubuMVC to use the convention

In order to tell FubuMVC to apply the convention, I need to call this method from the FubuRegistry.

ApplyConvention<AuthenticationConvention>();

Now, if I run my project and attempt to browse to an action that has been locked down, I get redirected to the login page, which is exactly what I wanted it to do.

Step 5: Let FubuMVC know when someone has logged in or out

In order to tell FubuMVC that a user has been logged in, I need to depend on IAuthenticationContext in the action that logs users in. Once I’ve verified the user’s credentials are correct, I can call the ThisUserHasBeenAuthenticated method on IAuthenticationContext to let FubuMVC know.

When I want to log a user out, call SignOut on the IAuthenticationContext interface.

Gotcha!

As I stated earlier, the default authentication in FubuMVC is really just a wrapper for forms authentication in ASP.NET. So, in order to use the ISecurityContext, you’ll need to turn on forms authentication in your web.config, otherwise the ISecurityContext will always say that the user is authenticated.

<system.web>    <authentication mode="Forms">        <forms loginUrl="~/login" timeout="25" slidingExpiration="true" />    </authentication></system.web>

To put the rest of the article into context, it’s important to know that Groupon works by selling coupons for a business’s service. The business agrees to give a discount of at least 50% and also agrees to give Groupon 50% of the revenue they take in from the coupons. This means that the business gets 25% of the list price for their product or service. At least, that’s how I understand it.

I’m not a business owner, but it’s hard for me to rationalize why any business would give up 50% of their, already cut in half revenue, providing their product or service for 25¢ on the dollar of their normal prices.

It’s hard to believe that you would actually turn over loyal customers and instead it seems like you’d get plenty of people coming to get a good deal, then never coming back. As Jay Ehret puts it:

The thought process goes like this: I get a new customer by giving them a discount: 50% off. They will appreciate the discount, see how great we are, and become a new customer. But that’s not how the customer thinks. They get their coupon, buy your stuff, and they like it. Then you ask them to buy again, but now you’ve doubled the price!
At the same time, you’re alienating your current customers by giving deep discounts to new customers, and offering nothing to the loyal customers that have been keeping you in business up until then.

I’m sure this isn’t a new idea, but I would like to see tools that allow your current customers to tap into their own social network. Reward both the current customer and the new customers they’re able to bring to your business. Provide coupons to both. If you’re not giving a middle-man 50% of the reduced profits, you might even be able to offer discounts comparable to Groupon, without going out of business.

The way we’re going to be doing our partials is by having the concept of an action extension which can be called by our partial action. It’s a little difficult to explain, so let’s get right into the code. I’ll be emphasizing all of the gotchas that I ran into, to hopefully help explain things a little better.

With all of the generics, things can get a little confusing. The generic parameter in all of these classes is going to be the model that you’re working with. What we’re really building here is a very maintainable “model modifier”.

To start off, let’s create our partial action. We’ll be using a generic action that we’re calling PartialAction. It is important to note that this is the action that’s going to get called when you call your partials. Since it’s generic, we’re going be calling it for all of our partial views.

public class PartialAction<T>    where T : class{    private readonly IPartialActionExtensionGraph<T> _graph;    public PartialAction(IPartialActionExtensionGraph<T> graph)    {        _graph = graph;    }    public T Execute(T input)    {        return _graph.Modify(input);    }}

As you can see, we have a dependency on and IPartialActionExtensionGraph. That’s a simple interface that has a single method, Modify. Since we’re going to be calling Modify on our Graph the same way as we call Modify on a single action extension, they share a common interface.

public interface IPartialActionExtensionGraph<T> : IPartialActionExtension<T>     where T : class{}public interface IPartialActionExtension<T>    where T : class{    T Modify(T model);}

Now we’re going to create a generic implementation for the action extension graph. We’ll want to call the Modify method on all of the action extensions that close the interface with the same type. We’re going to use our IoC container to keep track of all our implementations, in this case we’re using StructureMap, but you could probably use this with any dependency injection tool.

public class PartialActionExtensionGraph<T> : IPartialActionExtensionGraph<T>    where T : class{    private readonly IContainer _container;    public PartialActionExtensionGraph(IContainer container)    {        _container = container;    }    public T Modify(T model)    {        _container.GetAllInstances<IPartialActionExtension<T>>()            .Each(extension => model = extension.Modify(model));        return model;    }}

To load up StructureMap with all our action extensions, we’ll want to use this registry & registry convention while we bootstrap StructureMap. This awesome piece of code is from Josh, so please go thank him. It will search through our entire assembly and find any types that close the interface IPartialActionExtension<>, that is not an interface, and is not abstract. Please note that the Closes and FindInterfaceThatCloses extension methods are part of FubuCore.

public class PartialActionExtensionsRegistry : Registry{    public PartialActionExtensionsRegistry()    {        Scan(x =>        {            x.TheCallingAssembly();            x.Include(type => type.Closes(typeof(IPartialActionExtension<>)));            x.Exclude(type => type.IsInterface);            x.Exclude(type => type.IsAbstract);            x.With(new PartialActionExtensionsConvention());        });    }}public class PartialActionExtensionsConvention : IRegistrationConvention{    public void Process(Type type, Registry registry)    {        var extensionType = type.FindInterfaceThatCloses(typeof(IPartialActionExtension<>));        if(extensionType == null)        {            return;        }        registry            .For(extensionType)            .Add(type);    }}

Now that our action is setup, we’ll build our model. Until this point, we’ve been dealing with the plumbing to get the partial views to work. So I’ll explain what we’re about to write. On our master page, we want to see either a “Login” link if the user has not logged in, yet or a “Logout” link if the user is already logged in. Pretty simple. As you can see from the PartialAction class, our input and output model will be the same. So we just need to write the model that will be used by the view.

[PartialModel]public class MasterLoginLogoutModel{    public bool IsAuthenticated { get; set; }}

Note the PartialModel attribute. This is very important, because this is what we’ll use to tell FubuMVC to link it up to the PartialAction class.

In order for FubuMVC to know what to do, we’ll need to setup our behavior chains for the input model that we just built. This is where things get a little more complicated, but we’ll go through it step-by-step. We need to create action calls for each of our models, so let’s create an action source.

Our action source will be fairly simple. We’ll find all our classes that are marked with the PartialModel attribute, close the PartialAction<> action with this type, and create an action call for it. Please note that the GetExecuteMethod method is a Type extension method which just returns a MethodInfo instance of the method to call. In this case it will be the Execute method.

public class PartialActionsSource: IActionSource{    public IEnumerable<ActionCall> FindActions(TypePool types)    {        return types            .TypesMatching(t => t.HasAttribute<PartialModelAttribute>())            .Select(m =>                        {                            var actionType = typeof(PartialAction<>).MakeGenericType(m);                            return new ActionCall(actionType, actionType.GetExecuteMethod());                        });    }}

We’ll create the view real quick, nothing too fancy about it.

<%@ Page Language="C#" CodeBehind="MasterLoginLogout.aspx.cs" Inherits="Project.Web.Shared.Partials.Views.MasterLoginLogout" %><%@ Import Namespace="Project.Web.Models.Users" %><% if (Model.IsAuthenticated) {%>        Logout    <% } else { %>        Login    <%} %>public class MasterLoginLogout : FubuPage<MasterLoginLogoutModel>{}

Now, we can call the partial view from our master page very easily. It will look something like this.

<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site.master.cs" Inherits="Project.Web.Shared.Master.Site" %><%@ Import Namespace="FubuCore" %><%@ Import Namespace="Project.Web.Shared.Partials.Models" %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml">    <head>        <title>Project Master Page</title>    </head>    <body>        <% this.Partial<MasterLoginLogoutModel>(); %>    </body></html>public class Site : FubuMasterPage{}

When we call our page, we’ll see that it almost works. It’s just that it will always say “Login” because we never set the IsAuthenticated property on our model. To do this, we just want to create an action extension (remember that base interface we made way up there?).

public class MasterLoginLogoutPartialActionExtension : IPartialActionExtension<MasterLoginLogoutModel>{    private readonly IAuthenticationManager _authenticationManager;    public MasterLoginLogoutPartialActionExtension(IAuthenticationManager authenticationManager)    {        _authenticationManager = authenticationManager;    }    public MasterLoginLogoutModel Modify(MasterLoginLogoutModel model)    {        model.IsAuthenticated = _authenticationManager.LoggedIn;        return model;    }}

Also, just for completeness, here are the parts of our FubuMVC Registry which pertains to these partials.

public class ProjectFubuRegistry : FubuRegistry{    public ProjectFubuRegistry()    {        Applies.ToThisAssembly();        Actions.FindWith<PartialActionsSource>();        Views.TryToAttach(findViews =>                                    {                                        findViews.by_ViewModel_and_Namespace_and_MethodName();                                        findViews.by_ViewModel_and_Namespace();                                        findViews.by_ViewModel();                                    }    }}

Step-by-step, what happens when we call the partial from the master page?

1. FubuMVC looks for the action call setup to accept that input type.2. FubuMVC then calls the action call and passes a blank model to the PartialAction’s Execute method that was created while bootstrapping. In this case, it’s an instance of PartialAction, closed with MasterLoginLogoutModel.3. When this instance of PartialAction is instantiated, it depends on an IPartialActionExtensionGraph. When we call Modify on this, StructureMap will have already found our MasterLoginLogoutPartialActionExtension class (since it implements IPartialActionExtension and closes it with MasterLoginLogoutModel), and we will have a graph with this single action extension. If you had two classes that close this interface with MasterLoginLogoutModel, then they would both be in the graph.4. The PartialAction, then calls modify on the graph, which loops through all of the action extensions and calls the Modify method, resetting the model to the return value for each call.5. The model is then returned from the PartialAction, and is passed to the view.

Now, whenever we want to create a new partial view, we can just follow these steps:

1. Create the model for the view, be sure to mark it with the PartialModel attribute.2. Create as many implementations of IPartialActionExtension as we need (normally only one). Be sure it closes the interface with the model we’ve just setup.3. Create a view that uses the model. FubuMVC will be smart enough to figure out that’s the view we want to use, as long as we tell FubuMVC to match views by view models.

It’s my understanding that most of this plumbing will be in a future release of FubuMVC. Until then, you can do this, instead. I’ll write another post when these features are native to Fubu.