Project description

CarTrackr is a sample application for the ASP.NET MVC framework using the repository pattern and dependency injection using the Unity application block. It was written for various demos in presentations done by Maarten Balliauw.

CarTrackr is an online software application designed to help you understand and track your fuel usage and kilometers driven.

You will have a record on when you filled up on fuel, how many kilometers you got in a given tank, how much you spent and how much liters of fuel you are using per 100 kilometer.

CarTrackr will enable you to improve your fuel economy and save money as well as conserve fuel. Fuel economy and conservation is becoming an important way to control your finances with the current high price.

Source code

Latest version: CarTrackr (ASP.NET MVC 1.0 version)

Author blog feed

 Maarten Balliauw {blog} News Feed 
Friday, May 31, 2013  |  From Maarten Balliauw {blog}

One of the services provided by the Windows Azure cloud computing platform is the Windows Azure Access Control Service (ACS). It is a service that provides federated authentication and rules-driven, claims-based authorization. It has some social providers like Microsoft Account, Google Account, Yahoo! and Facebook. But what about the other social identity providers out there? For example the newly introduced Login with Amazon, or LinkedIn? As they are OAuth2 implementations they don’t really fit into ACS.


Meet SocialSTS.com. It’s a service I created which does a protocol conversion and allows integrating ACS with other social identities. Currently it has support for integrating ACS with Twitter, GitHub, LinkedIn, BitBucket, StackExchange and Amazon. Let’s see how this works. There are 2 steps we have to take:


  • Link SocialSTS with the social identity provider
  • Link our ACS namespace with SocialSTS

Link SocialSTS with the social identity provider


Once an account has been created through www.socialsts.com, we are presented with a dashboard in which we can configure the social identities. Most of them require that you register your application with them and in turn, you will receive some identifiers which will allow integration.


SocialSTS - Register social identity provider


As you can see, instructions for registering with the social identity provider are listed on the configuration page. For Amazon, we have to register an application with Amazon and configure the following:

If we do this, Amazon will give us a client ID and client secret in return, which we can enter in the SocialSTS dashboard.


Amazon Login with Access Control on Windows Azure


That’s basically all configuration there is to it. We can now add our Amazon, LinkedIn, Twitter or GitHub login page to Windows Azure Access Control Service!

Link our ACS namespace with SocialSTS


In the Windows Azure Access Control Service management dashboard, we can register SocialSTS as an identity provider. SocialSTS will provide us with a FederationMetadata.xml URL which we can copy into ACS:


Add LinkedIn to ACS


We can now save this new identity provider, add some claims transformation rules through the rule groups (important!) and then start using it in our application:


Windows Identity Foundation claims from Amazon,LinkedIn and so on


Enjoy! And let me know your thoughts on this service.

Tuesday, May 28, 2013  |  From Maarten Balliauw {blog}

Many API’s out there, such as GitHub’s API, have a concept called “rate limiting” or “throttling” in place. Rate limiting is used to prevent clients from issuing too many requests over a short amount of time to your API. For example, we can limit anonymous API clients to a maximum of 60 requests per hour whereas we can allow more requests to authenticated clients. But how can we implement this?

Intercepting API calls to enforce throttling

Just like ASP.NET MVC, ASP.NET Web API allows us to write action filters. An action filter is an attribute that you can apply to a controller action, an entire controller and even to all controllers in a project. The attribute modifies the way in which the action is executed by intercepting calls to it. Sound like a great approach, right?

Well… yes! Implementing throttling as an action filter would make sense, although in my opinion it has some disadvantages:

  • We have to implement it as an IAuthorizationFilter to make sure it hooks into the pipeline before most other action filters. This feels kind of dirty but it would do the trick as throttling is some sort of “authorization” to make a number of requests to the API.
  • It gets executed quite late in the overall ASP.NET Web API pipeline. While not a big problem, perhaps we want to skip executing certain portions of code whenever throttling occurs.

So while it makes sense to implement throttling as an action filter, I would prefer plugging it earlier in the pipeline. Luckily for us, ASP.NET Web API also provides the concept of message handlers. They accept an HTTP request and return an HTTP response and plug into the pipeline quite early. Here’s a sample throttling message handler:

1 public class ThrottlingHandler
2 : DelegatingHandler
3 {
4 protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
5 {
6 var identifier = request.GetClientIpAddress();
7
8 long currentRequests = 1;
9 long maxRequestsPerHour = 60;
10
11 if (HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] != null)
12 {
13 currentRequests = (long)System.Web.HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] + 1;
14 HttpContext.Current.Cache[string.Format("throttling_{0}", identifier)] = currentRequests;
15 }
16 else
17 {
18 HttpContext.Current.Cache.Add(string.Format("throttling_{0}", identifier), currentRequests,
19 null, Cache.NoAbsoluteExpiration, TimeSpan.FromHours(1),
20 CacheItemPriority.Low, null);
21 }
22
23 Task<HttpResponseMessage> response = null;
24 if (currentRequests > maxRequestsPerHour)
25 {
26 response = CreateResponse(request, HttpStatusCode.Conflict, "You are being throttled.");
27 }
28 else
29 {
30 response = base.SendAsync(request, cancellationToken);
31 }
32
33 return response;
34 }
35
36 protected Task<HttpResponseMessage> CreateResponse(HttpRequestMessage request, HttpStatusCode statusCode, string message)
37 {
38 var tsc = new TaskCompletionSource<HttpResponseMessage>();
39 var response = request.CreateResponse(statusCode);
40 response.ReasonPhrase = message;
41 response.Content = new StringContent(message);
42 tsc.SetResult(response);
43 return tsc.Task;
44 }
45 }


We have to register it as well, which we can do when our application starts:



1 config.MessageHandlers.Add(new ThrottlingHandler());


The throttling handler above isn’t ideal. It’s not very extensible nor does it allow scaling out on a web farm. And it’s bound to being hosted in ASP.NET on IIS. It’s bad! Since there’s already a great project called WebApiContrib, I decided to contribute a better throttling handler to it.


Using the WebApiContrib ThrottlingHandler



One word of warning: at the time of writing this post, the ThrottlingHandler pull request was not accepted yet. If you want it now, please find it in my fork on GitHub.



The easiest way of using the ThrottlingHandler is by registering it using simple parameters like the following, which throttles every user at 60 requests per hour:



1 config.MessageHandlers.Add(new ThrottlingHandler(
2 new InMemoryThrottleStore(),
3 id => 60,
4 TimeSpan.FromHours(1)));


The IThrottleStore interface stores id + current number of requests. There’s only an in-memory store available but you can easily extend it to write this in a distributed cache or a database.



What’s interesting is we can change how our ThrottlingHandler behaves quite easily. Let’s give a specific IP address a better rate limit:



1 config.MessageHandlers.Add(new ThrottlingHandler(
2 new InMemoryThrottleStore(),
3 id =>
4 {
5 if (id == "10.0.0.1")
6 {
7 return 5000;
8 }
9 return 60;
10 },
11 TimeSpan.FromHours(1)));


Wait… Are you telling me this is all IP based? Well yes, by default. But overriding the ThrottlingHandler allows you to do funky things! Here’s a wireframe:



1 public class MyThrottlingHandler : ThrottlingHandler
2 {
3 // ...
4
5 protected override string GetUserIdentifier(HttpRequestMessage request)
6 {
7 // your user id generation logic here
8 }
9 }


By implementing the GetUserIdentifier method, we can for example return an IP address for unauthenticated users and their username for authenticated users. We can then decide on the throttling quota based on username.



Once using it, the ThrottlingHandler will inject two HTTP headers in every response, informing the client about the rate limit:



image



It’s a first version, I do hope the pull request gets in. In the meanwhile, enjoy! And do checkout WebApiContrib, it contains almost all extensions to ASP.NET Web API you will ever need!

 Maarten Balliauw {blog} News Feed 

Last edited Oct 15, 2008 at 7:15 AM by maartenba, version 4