Custom Authorization Filter returns 200 OK during authorization failure in Web API / MVC

This is a very specific and a quick post. In Web APIs sometimes we need to implement custom authorization filter which is extended from AuthorizeAttribute class, this is mainly useful in implementing authorization.

The below code shows how to implement an admin authorization in claims based authentication using ClaimsIdentity

The above code works perfectly in controllers and actions. If you pass ‘true’ to IsAdmin only the authentication requests with the claim IsAdmin true can access the respective controllers or actions.

So when a user who is not an admin tries to access controller / action decorated with the above attribute the client should receive a 401 (Unauthorized) / 403 (Forbidden) reply.

The Problem

But the in Web API you will get a response with status code 200 (OK) with the response body with the following message.

This is not a desirable behavior mainly in APIs because when you make a request from AJAX using any Javascript library, there’s a high probability that they would treat the request as success. You should in cooperate specific client logic to detect this and read the response body JSON message.

And also as API developers we do not prefer this default behavior.

The Solution

The solution is very simple, yet I thought to write a blog on this because in the Internet most of the posts say that this behavior cannot be altered from the API side. But API developers have full control over this behavior. Simply override the HandleUnauthorizedRequest method of the AuthorizeAttribute class.

Now you will get 403 error code as expected with the custom message provided in the Content in the response body.

If it is an MVC application you could do a redirection to the login page.

Advertisement

How to create Cascading Dropdowns in Angular JS using Web API

Angular JS is one of the famous and a ‘WoW’ making Javascript frameworks available. https://angularjs.org/ has plenty of learning resources for Angular JS. This post shows how to create cascading drop downs using Angular JS whilst showing the use of other basic features of Angular JS.

Angular JS relies heavily on angular directives which HTML extended attributes with prefix of ng-

The following sample shows a simple web application developed using Angular JS and Web API. I used the AdventureWorks2012LT database and a Web API 2. UI has two dropdowns, first one shows the product categories and when a category is selected the second one shows the products for that particular category.

http://localhost/ADLTService/api/productcategory – to get the product categories

http://localhost/ADLTService/api/productforcategory/{id} – to get the products for a category id.

Create a simple HTML project and add Angular from NuGet. The below code shows the app script.

thuruinhttp.wordpress.com

The below is my HTML

thuruinhttp.wordpress.com

ng-repeat directive loops through the collection and creates the <options> tag for us. ng-model binds the value to the parameter in ng-change event. Here the name should be identical. The rest Angular knows how to interpret. Cascading drop down simple as that. You can also use ng-options as a directive for the <select> for more details refer this article.

Working Model.

angular cascading drop down

How to enable sessions in Web API

Web API does not support native HTTP sessions. And it’s the nature of Web API, but there might be times you need HTTP sessions which resembles your bad design. Because a service framework should not support HTTP sessions as it should be a stateless element. So why do we need sessions in Web API ? I think you should not use sessions in Web API in production; eliminate HTTP sessions completely.

So the answer for the question why do we need sessions in Web API is, just to show how you can enable them. Silly though but you can use this in developing some POC and quick functional demos. Never use sessions in Web API because Web API is designed to be stateless.

First we should implement a ControllerHandler which is capable of handling sessions. In order make our ControllerHandler handle sessions we should implement IRequiresSessionState interface as well. Look at the below code.

   1: public class SessionableControllerHandler : HttpControllerHandler, IRequiresSessionState

   2: {

   3:     public SessionableControllerHandler(RouteData routeData) 

   4:         : base(routeData)

   5:     {

   6:  

   7:     }

   8: }

The next step is to create a RouteHandler as a wrapper to the ControllerHandler we created, this is because when registering routes in the RouteTable we can pass RouteHandler types not ControllerHandler types. Look at the below code for the custom RouteHandler.

   1: public class SessionStateRouteHandler : IRouteHandler

   2: {

   3:     public IHttpHandler GetHttpHandler(RequestContext requestContext)

   4:     {

   5:         return new SessionableControllerHandler(requestContext.RouteData);

   6:     }

   7: }

Then finally we have to register our RouteHandler in the RouteTable

   1: RouteTable.Routes.MapHttpRoute(

   2:     name: "DefaultApi",

   3:     routeTemplate: "api/{controller}/{id}",

   4:     defaults: new { id = RouteParameter.Optional }

   5: ).RouteHandler = new SessionStateRouteHandler();

In order to make our custom route to be used we need to put it on top of other route registrations.