Restricting routes in ASP.NET MVC

One of the really useful things about the extensibility of ASP.NET MVC is the ability to impose restrictions and write your own restrictions for your routes. I tend to think that adding restricted routes (when possible) is a great practice. Why when non-valid route values ​​are passed to your application to not allow the ASP.NET MVC framework and route module to do the validation itself?


Route restrictions

Using route constraints in ASP.NET MVC is part of the route mapping process itself. Take as an example an online store that uses product IDs in its routes to display products in the catalog. Because The ID must be an integer in this case and can consist of only 1-5 digits, let's indicate this as a restriction of the route, so that only valid ID-sniki are accepted in the route:
')

routes.MapRoute( "Product" , "Product/{id}" ,
new { controller = "Products" , action = "Details" },
new { id = @"\d{1,5}" }); // Constraint

* This source code was highlighted with Source Code Highlighter .

Notice how easy it is to indicate that id is a range from 1 to 5 digits using the regular expression "\ d {1,5}". Now, if someone enters the wrong route, such as:

/ Product / abc

It will receive a page with an error (if its own error page is not specified - the standard “resource not found” / “the resource cannot be found.”).

Custom Route Constraints

Even cooler than using route constraints in ASP.NET MVC is the ability to create your own constraints. To create your own route constraint, all you need to do is create a class that implements IRouteConstraint , for which you need to implement just one method - Match .

Let's create a simple route constraint that checks the names of employees that are transmitted in a part of the route. The route looks like this:

routes.MapRoute( "Employee" , "Employee/{name}" ,
new { controller = "Employees" , action= "Details" },
new { name = new ExpectedValuesConstraint( "john" , "jane" , "tom" ) });

* This source code was highlighted with Source Code Highlighter .

Notice the addition of a native route constraint class called ExpectedValuesConstraint with the list of names that are expected as the {name} field in the route.

The ExpectedValuesConstraint class looks like this:

public class ExpectedValuesConstraint : IRouteConstraint
{
private readonly string [] _values;

public ExpectedValuesConstraint( params string [] values)
{
_values = values;
}

public bool Match(HttpContextBase httpContext, Route route,
string parameterName, RouteValueDictionary values,
RouteDirection routeDirection)
{
return _values.Contains(values[parameterName].ToString(),
StringComparer.InvariantCultureIgnoreCase);
}
}

* This source code was highlighted with Source Code Highlighter .

In this case, the parameterName will be "name", and then we simply take the name value from RouteValueDictionary and check whether the name is in the list of values ​​passed to the constructor when the route was mapped. If the name transferred to the route is not equal to “john”, “jane”, or “tom” - in this case the user will be sent to the default error page “the resource cannot be found").

Conclusion

Whenever you can add a route limit to your routes - add. Allow the route engine to help validate the input data for your application and return errors if they do not meet the expectations. Note that you can create sufficiently comprehensive routes when you want to handle fake route values ​​in the application. This time everything.