ASP.NET Weblogs

IP Throttling in ASP.NET Web API

cibrax — Wed, 22 May 2013 14:43:11 GMT

Some Web APIs use the client IP address to enforce Service Level Agreements such as limit the number of calls in a period of time. The client IP address can be used as a replacement for an authentication key sometimes when a previous registration of client applications is not required.

This is relatively simple to implement in a message handler,

public class IPThrottlingMessageHandler : DelegatingHandler
{
  IIPRepository repository;
  int maxRequestsHour;

  public IPThrottlingMessageHandler(IIPRepository repository, int maxRequestsHour = 150)
            : base()
  {
    this.repository = repository;
    this.maxRequestsHour = maxRequestsHour;
   }

   public IPThrottlingMessageHandler(HttpMessageHandler inner, IIPRepository repository, int maxRequestsHour = 150)
            : base(inner)
  {
     this.repository = repository;
     this.maxRequestsHour = maxRequestsHour;
   }

   protected override System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
  {
     var ip = GetClientIp(request);
            
      if (ip == null)
      {
         return ToResponse(request, HttpStatusCode.Forbidden, "The client ip couldn't be found");
       }

       if(this.repository.Increment(DateTime.Now.Hour, ip) > this.maxRequestsHour)
       {
          return ToResponse(request, HttpStatusCode.Forbidden, "Quota exceeded");
        }
            
       return base.SendAsync(request, cancellationToken);
  }

  private string GetClientIp(HttpRequestMessage request)
  {
     if (request.Properties.ContainsKey("MS_HttpContext"))
     {
        return ((HttpContextWrapper)request.Properties["MS_HttpContext"]).Request.UserHostAddress;
      }
     else if (request.Properties.ContainsKey(RemoteEndpointMessageProperty.Name))
     {
        RemoteEndpointMessageProperty prop;
        prop = (RemoteEndpointMessageProperty)request.Properties[RemoteEndpointMessageProperty.Name];
        return prop.Address;
      }
      else
      {
          return null;
       }
   }

   private static Task<HttpResponseMessage> ToResponse(HttpRequestMessage request, HttpStatusCode code, string message)
   {
       var tsc = new TaskCompletionSource<HttpResponseMessage>();

       var response = request.CreateResponse(code);
       response.ReasonPhrase = message;
       response.Content = new StringContent(message);

       tsc.SetResult(response);

        return tsc.Task;
    }
 }

This handler uses a repository to store the number of calls with a given IP in one hour. If the number of requests per hour exceeds the quota, an error response is returned to the client.

Dynamically Loading Controllers and Views with AngularJS and RequireJS

dwahlin — Wed, 22 May 2013 07:06:32 GMT

New to AngularJS? Check out the AngularJS in 60-ish Minutes video to get a jumpstart on using the framework to build Single Page Applications (SPAs).

Dynamically Loading Controllers and Views

AngularJS provides a simple way to associate a view with a controller and load everything at runtime using the $routeProvider object. Routing code is typically put in a module’s config() function and looks similar to the following:

$routeProvider
     .when('/customers',
        {
            controller: 'CustomersController',
            templateUrl: '/app/views/customers.html'
        })
    .when('/customerorders/:customerID',
        {
            controller: 'CustomerOrdersController',
            templateUrl: '/app/views/customerOrders.html'
        })
    .when('/orders',
        {
            controller: 'OrdersController',
            templateUrl: '/app/views/orders.html'
        })
    .otherwise({ redirectTo: '/customers' });

While this type of code works great for defining routes it requires controller scripts to be loaded upfront in the main shell page by default. That works fine in some scenarios but what if you have a lot of controller scripts and views in a given application and want to dynamically load them on-the-fly at runtime? One way of dealing with that scenario is to define a resolve property on each route and assign it a function that returns a promise. The function can handle dynamically loading the script containing the target controller and resolve the promise once the load is complete. An example of using the resolve property is shown next:

$routeProvider
    .when('/customers',
        {
            templateUrl: '/app/views/customers.html',
            resolve: resolveController('/app/controllers/customersController.js')
        });

This approach works well in cases where you don’t want all of your controller scripts loaded upfront, but it still doesn’t feel quite right – at least to me. I personally don’t like having to define two paths especially if you’ll be working with a lot of routes. If you’ve ever worked with a framework that uses convention over configuration then you’ll know that we can clean up this code by coming up with a standard convention for naming views and controllers. Coming up with a convention can help simplify routes and maintenance of the application over time. The approach that I’ll demonstrate in this post uses the following routing code to define the path, view and controller:

$routeProvider
    .when('/customers', route.resolve('Customers'))
    .when('/customerorders/:customerID', route.resolve('CustomerOrders'))
    .when('/orders', route.resolve('Orders'))
    .otherwise({ redirectTo: '/customers' });

Notice that a single value is passed into the route.resolve() function. Behind the scenes the function will automatically create the path to the view and the path to the controller based on some simple conventions and then load the appropriate files dynamically. You can access a sample (work in progress) project at https://github.com/DanWahlin/CustomerManager. Let’s take a look at how it works.

Dynamically Loading Controllers

The following diagram shows the different players involved in simplifying routes and dynamically loading controllers. RequireJS is used to dynamically load controller JavaScript files and make an application’s main module available to the controllers so that they’re registered properly after they’re loaded.

Here’s how it works:

A file named main.js defines custom scripts that will be loaded using RequireJS. I originally defined 3rd party libraries such as AngularJS in main.js as well but decided there simply wasn’t enough benefit over loading them at the bottom of the initial page using a <script> tag and pulled them out as a result. Only custom scripts are added into main.js in the sample application.
The routeResolver.js script creates an AngularJS provider. It’s loaded by RequireJS and used in app.js within the config() function to define routes and resolve them dynamically at runtime.
The app.js file is loaded by RequireJS. It defines the main AngularJS module used in the application as well as the config for the module. The config section accesses compiler providers (such as $controllerProvider) needed to dynamically load controllers, directives, etc. and also uses the routeResolver to define views and controllers that need to be dynamically loaded (see diagram above). Views and routes are defined using a single name. For example, route.resolve(“Customers”) will cause customers.html to be loaded from the views folder and customersController.js from the controllers folder.
Each controller is passed the AngularJS module created in app.js by RequireJS. This allows the controllers to dynamically register themselves with AngularJS using a $controllerProvider behind the scenes.
At runtime the routes defined in app.js are dynamically resolved using the routeResolver provider that is injected into the config() function located in app.js.

Let’s break down each of the files one by one now that you’ve seen how they integrate with each other.

Defining Scripts in main.js

RequireJS is used to load all of the custom scripts used in the sample application. It’s useful to ensure dependencies are loaded in the proper order and also helps dynamically loaded controllers, directives and other AngularJS objects easily access the application’s module so that they can be properly registered. An example of the main.js file used to configure RequireJS is shown next. All third party scripts are loaded directly in the shell page (index.html) rather than using RequireJS. Services used across multiple controllers are loaded upfront as well as some controllers needed immediately. However, the services could certainly be loaded dynamically if desired with a little more work (that feature isn’t currently implemented).

require.config({
    baseUrl: '/app',
    urlArgs: 'v=1.0'
});

require(
    [
        'app',
        'services/routeResolver',
        'services/config',
        'services/customersBreezeService',
        'services/customersService',
        'services/dataService',
        'controllers/navbarController',
        'controllers/orderChildController'
    ],
    function () {
        angular.bootstrap(document, ['customersApp']);
    });

Since the app.js file is loaded dynamically (it defines the main application module) an ng-app=”customersApp” attribute isn’t hard-coded into the shell page that initially loads as with standard AngularJS applications. Instead, it’s added at runtime by calling angular.bootstrap().

The routeResolver.js File

The routeResolver.js file handles creating an AngularJS module and provider that can dynamically load views and controllers. AngularJS already comes with built-in support for loading views dynamically and with a little more work controllers can be loaded dynamically as well. Loading controller scripts can be done by assigning the resolve property mentioned earlier to a function that handles loading the controller. What’s unique about routeResolver is that it doesn’t accept hard-coded paths to the target view or controller. Instead, you define a base name such as “Customers” and the resolver will generate the path to the appropriate view and controller based on a standard convention.

Here’s the complete code for the routeResolver provider as well as a routeConfig object used to configure view and controller directories. The code starts by defining a new AngularJS module named routeResolverServices. A provider was chosen (as opposed to a service or factory) because the routeResolver needs to be injected into the config() function of a given application’s module (in app.js for example). The config() function uses the routeResolver to define the routes based on the conventions mentioned earlier.

'use strict';

define([], function () {

    var services = angular.module('routeResolverServices', []);

    //Must be a provider since it will be injected into module.config()    
    services.provider('routeResolver', function () {

        this.$get = function () {
            return this;
        };

        this.routeConfig = function () {
            var viewsDirectory = '/app/views/',
                controllersDirectory = '/app/controllers/',

            setBaseDirectories = function (viewsDir, controllersDir) {
                viewsDirectory = viewsDir;
                controllersDirectory = controllersDir;
            },

            getViewsDirectory = function () {
                return viewsDirectory;
            },

            getControllersDirectory = function () {
                return controllersDirectory;
            };

            return {
                setBaseDirectories: setBaseDirectories,
                getControllersDirectory: getControllersDirectory,
                getViewsDirectory: getViewsDirectory
            };
        }();

        this.route = function (routeConfig) {

            var resolve = function (baseName) {
                var routeDef = {};
                routeDef.templateUrl = routeConfig.getViewsDirectory() + baseName + '.html';
                routeDef.controller = baseName + 'Controller';
                routeDef.resolve = {
                    load: ['$q', '$rootScope', function ($q, $rootScope) {
                        var dependencies = [routeConfig.getControllersDirectory() + baseName + 'Controller.js'];
                        return resolveDependencies($q, $rootScope, dependencies);
                    }]
                };

                return routeDef;
            },

            resolveDependencies = function ($q, $rootScope, dependencies) {
                var defer = $q.defer();
                require(dependencies, function () {
                    defer.resolve();
                    $rootScope.$apply()
                });

                return defer.promise;
            };

            return {
                resolve: resolve
            }
        }(this.routeConfig);
    });

});

Looking through the code you can see that a routeConfig object is defined that allows the views and controllers directory to be set using code similar to the following (this code goes in the module.config() function that’ll be shown later):

//Change default views and controllers directory using the following:
routeResolverProvider.routeConfig.setBaseDirectories('/app/myViews', '/app/myControllers');

The routeConfig object defaults to the following directories:

Views: /app/views

Controllers: /app/controllers

In addition to routeConfig you’ll also find a route object with a resolve() function that handles dynamically loading controller scripts. It handles setting the templateUrl and controller name for a given route. It also takes advantage of AngularJS’s resolve property to dynamically load the target controller script using RequireJS. The resolve() function shown above delegates loading controller scripts to another function named resolveDependencies() which handles getting a deferral, returning a promise, and resolving the deferral once the controller script loads.

Defining Routes in app.js

The app.js file defines the application’s main module and also handles configuring routes. It’s wrapped with a define() call to RequireJS to ensure that the routeResolver is loaded and available. The customersApp module defined in app.js requires routeResolverServices.

The config() function has several different providers injected into it including the routeResolver provider (note that the actual name of the provider is routeResolver but that you must add “Provider” on the end of the name for it to work properly when injecting it). The AngularJS providers that are injected into config() are used to dynamically register controllers, directives, filters and more after a given script is dynamically loaded.

Notice that within the config() function an object literal is assigned to app.register (app represents the application’s module). The object literal contains properties that can be used to dynamically register a controller and other AngularJS objects that are downloaded on-the-fly (thanks to Mateusz Bilski for the initial code that started me thinking about this more). You’ll learn more about that process in a moment. Application routes are defined using the routeResolver provider’s route.resolve() function which accepts the base name to use to lookup views and controllers as mentioned earlier based on conventions.

'use strict';

define(['services/routeResolver'], function () {

    var app = angular.module('customersApp', ['routeResolverServices']);

    app.config(['$routeProvider', 'routeResolverProvider', '$controllerProvider', '$compileProvider', '$filterProvider', '$provide',
        function ($routeProvider, routeResolverProvider, $controllerProvider, $compileProvider, $filterProvider, $provide) {

            //Change default views and controllers directory using the following:
            //routeResolverProvider.routeConfig.setBaseDirectories('/app/views', '/app/controllers');

            app.register =
            {
                controller: $controllerProvider.register,
                directive: $compileProvider.directive,
                filter: $filterProvider.register,
                factory: $provide.factory,
                service: $provide.service
            };

            //Define routes - controllers will be loaded dynamically
            var route = routeResolverProvider.route;

            $routeProvider
                .when('/customers', route.resolve('Customers'))
                .when('/customerorders/:customerID', route.resolve('CustomerOrders'))
                .when('/orders', route.resolve('Orders'))
                .otherwise({ redirectTo: '/customers' });

                }]);

            return app;
});

Defining Controllers

Controllers in the application rely on RequireJS to access the object representing the application’s module and then access the register property shown earlier to register a controller script with AngularJS. This type of registration is required since using the standard angular.module(“ModuleName”).controller() code won’t work properly with dynamically loaded controller scripts (at least at the current time). An example of a controller named customersController.js is shown next. Notice that it uses RequireJS’s define() function to get to the app object and then uses it to register the controller. The app.register.controller() function points to AngularJS’s $controllerProvider.register() function behind the scenes as shown earlier with app.js. All of the controllers in the application follow this pattern.

'use strict';

define(['app'], function (app) {

    //This controller retrieves data from the customersService and associates it with the $scope
    //The $scope is ultimately bound to the customers view
    app.register.controller('CustomersController', ['$scope', 'config', 'dataService', function ($scope, config, dataService) {

        //Controller code goes here

    }]);
});

What about Directives, Filters and other Types?

The current routeResolver implementation only supports dynamically loading controllers. However, all of the necessary plumbing is in place so I may add that functionality at some point in the future.

Summary

If you’re new to AngularJS this may seem like a lot of code to perform a simple task like dynamically downloading a controller script. However, once you get the main.js and app.js scripts in place the rest takes care of itself if you follow the pattern outlined above for defining controllers.

The word on the street is that AngularJS will eventually provide a built-in way to dynamically load controllers and other scripts. I’ll certainly welcome that feature when it’s available but until then the routeResolver and RequireJS functionality shown here gets the job done. Although I’ve been through several iterations and variations of this code I expect it’ll change as I use it more and get feedback. Access the sample (work in progress) project that shows all of this in action at https://github.com/DanWahlin/CustomerManager.

The holy grail: Automatically diagnose IIS + ASP.NET website hangs

The Official Microsoft IIS Site — Tue, 21 May 2013 14:17:52 GMT

We finally did it. LeanSentry now automatically detects and diagnoses IIS and ASP.NET hangs! Read More......( read more ) Read More......(read more)

The powerful .NETMF on your wrist! Meet the Agent

Chris Hammond — Tue, 21 May 2013 12:16:00 GMT

So if you've been under a rock lately, you might have missed this little phenom known as KickStarter. Well today you're going to want to check it out. Secret Labs, the folks who brought you Netduino (hey, I'm wearing a Netduino t-shirt today, what a coincidence) have teamed up with a watch maker in New York City (SL is based there as well) to bring you Agent! http://www.agentwatches.com/ So what is Agent? I could write this whole long blog post about it, but you'd be better off just reading the KickStarter...(read more)

Tricky issue with HTML5 drag and drop

bipinjoshi — Tue, 21 May 2013 07:41:00 GMT

Recently a reader asked about a tricky issue with HTML5 drag and drop. The issue is this:

HTML5 supports native drag and drop through draggable property and several events such as dragstart, drag, dragenter, dragleave, dragover and drop. Normally dragstart event handler is where you set the data that is to be transferred between the drag source and drop target. The drop event handler is where you handle the drop of a drag source, access the data transferred and process it further. Now, in this particular case only the dragstart and drop events were handled. And the drop event handler never used to get called. In other words dragging operation was successful but dropping operation was not.

http://www.bipinjoshi.net/articles/9ce78d52-7927-4fce-9dbc-d0d3f2bd6f70.aspx

Everyone else is doing it (incorrectly)!

Jeff — Sat, 18 May 2013 20:51:12 GMT

[This is actually a repost from my personal blog, but I think the technical audience might “dig” it as well.]

Innovation is hard. You can definitely foster it, but you can't really force it. It's completely fascinating when people innovate in a massively disruptive way. While you can't make innovation happen, it's something I try to strive for. There are certain ways that I've had a great deal of success innovating, and others where I haven't. Professionally, it's easy to get into the rut of doing things a certain way, because everyone else does it that way. The first step to doing it in a better way often requires questioning the establishment. While my inner rebel is all about that, it's also an exhausting practice.

Coaching volleyball is one of those scenarios where the questioning comes easy. For example, before a match, you're given several minutes of court time to warm up (the actual time depends on the governing organization). Since I was in high school, that time was always used by coaches to send perfectly tossed balls into the air for hitting, while your one or two short defensive specialists tried to dig those hit balls. This results in a lot of "whoo-hoo's" and pleasure on the part of your athletes, but I wasn't sure if it was constructive.

Attacking the ball is always step three in volleyball. Someone has to expertly pass the ball first, then someone has to set it for the hitter. Without those two things, there is no hitting. So after a season or two, I thought, why am I wasting time on this, especially when my kids can't pass to save their lives? So despite the protest of the kids (and parents, who always have the answers), I ditched the hitting lines. I put six kids on the other side of the net, and tossed balls in for them to pass, set and hit. I rotated them around. This exercised all of the skills necessary to score, including the ever important transition on and off the net. It was real, core to the game, and made a huge difference. It also happened to be noisy and menacing in appearance, which freaked out the other team, so that was a plus.

I tossed out what everyone else was doing, and tried something that seemed to better serve the scenario. I try to do this with all things in life. And yes, it can be exhausting questioning everything, especially if you end up where you started, and "everyone" had it right.

It's a lot harder to innovate your way out of the norm in my line of work. In terms of the actual computer science, sure, there are a lot of things that have been thought to death and they're good ideas. It tends to be the process and the associated people issues that are harder to change. There is an important parallel though to the volleyball warm-up. It turns out that process is almost always wrought with wasted time for things that don't matter, that don't get to something real and valuable. Even in celebrated (capital "A") Agile practices, teams have a hard time identifying the things they do that aren't adding value, let alone innovating.

Innovation isn't easy, but you can get practice at it. It starts when you stop accepting sheep behavior and ask if there's a better way.

modern.ie

dotneteer — Fri, 17 May 2013 01:33:21 GMT

We are planning to update our very old web application so that it works better with modern web browsers. I have heard of modern.ie in the past and decided to give it a try. The site has a scanner that can scan a URL entered by a user. Unfortunately, our site requires log-in before getting to the page we want to scan. Fortunately, the site also offers a downloadable scanner that we can use in our local development environment.

I downloaded the scanner. It is packaged as a zip file. I unzipped the package and open the readme file. The tools requires node.js to work. Fortunately, it is fairly easy to setup the tool following the instructions. Firstly, download and install node.js; accept all defaults. The setup will add Node.js to the path. Although Node.js is known for hosting asynchronous web applications, it is actually just a javascript executing environment. Next, I open the command prompt, change to the directory that I unzipped the modern.ie tool and run “node lib/service.js”. A node hosted web server is listening on port 1337 so we just need to open a web browser and points to http://localhost:1337/. We can then enter the URL of a web page to scan. The scanner submits the data to modern.ie and a report is generated. The report is very good and it offers many suggestions and links that helps us to improve the page.

Red Gate Is Looking For Feedback On Its ASP.NET MVC Web Development Education Website

Paulo Morgado — Thu, 16 May 2013 22:43:00 GMT

Red Gate is looking for feedback on its ASP.NET Web Development Education website.

Visit their website and answer the survey.

70-484 exam: Essentials of Developing Windows Store Apps using C#

pluginbaby — Wed, 15 May 2013 19:20:05 GMT

Just got this one! Here is a little tip for you:

While studying a new exam the first thing to do is to consult the “Skills Measured” section of the official page of Microsoft Learning website:
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-484

Better than that, Vitor Ciaramella, put together this nice sheet with direct hyperlinks to MSDN resources for each topics covered by the exam:
http://www.vic.ms/microsoft/windows-8/exam-70-484-essentials-of-developing-windows-store-apps-using-c/

Come support us at TechEd 2013 and get awesome stuff!

The Official Microsoft IIS Site — Wed, 15 May 2013 18:00:38 GMT

Are you going to TechEd this year? Be sure to come see us, and get some awesome stuff - including an exclusive LeanSentry discount, and a chance to win a Microsoft Surface! We've been working hard to to bring better monitoring and production troubleshooting Read More......( read more ) Read More......(read more)