ASP.Net MVC - обработка неверных параметров URL

Question

Как лучше всего обработать посетителя, создав его собственный URL и заменив тем, что мы ожидаем, в качестве идентификатора на что угодно?

Например:

ASP.Net MVC - обработка неверных параметров URL

Но пользователь может также легко заменить URL-адрес на:

https://stackoverflow.com/questions/foo

Я думал о том, чтобы сделать каждый параметр функции контроллера String и использовать для них Integer.TryParse() - если это пройдет, у меня будет идентификатор и я смогу продолжить, в противном случае я могу перенаправить пользователя на неизвестный / не- найдено или проиндексировано.

Stack Overflow прекрасно с этим справляется, и мне бы тоже хотелось - как вы это сделаете или что бы вы предложили?

Answer 1

Вот пример маршрута, подобного вашему, с ограничением на число:

routes.MapRoute(
    "Question",
    "questions/{questionID}",
    new { controller = "StackOverflow", action = "Question" },
    new { questionID = @"\d+" } //Regex constraint specifying that it must be a number.
);

Здесь мы устанавливаем, чтобы идентификатор вопроса имел хотя бы одно число. Это также блокирует любые URL-адреса, содержащие что-либо, кроме целого числа, а также предотвращает необходимость использования значения NULL.

Примечание: Это не учитывает числа, которые превышают диапазон Int32 (-2147483647 - +2147483647). Я оставляю это как упражнение пользователю, чтобы решить. :)

Если пользователь вводит URL «questions / foo», он не будет нажимать на действие Question и провалится через него, потому что он не соответствует ограничению параметра. Вы можете обработать его дальше вниз по маршруту «перехват» / «по умолчанию», если хотите:

routes.MapRoute(
    "Catchall",
    "{*catchall}", // This is a wildcard routes
    new { controller = "Home", action = "Lost" }
);

Это отправит пользователя к действию Lost в контроллере Home. Более подробную информацию о подстановочном знаке можно найти здесь .

NB. Catchall должен находиться в качестве ПОСЛЕДНЕГО маршрута. Размещение его дальше по цепочке будет означать, что он будет обрабатывать все остальные ниже него, учитывая ленивый характер маршрутов в ASP.NET MVC.

Answer 2

Вот некоторая полезная информация, которая может помочь. Если у вас есть метод действия

public ActionResult Edit(int? id)
{}

тогда, если кто-то наберет

/Home/Edit/23

идентификатор параметра будет 23. однако, если кто-то наберет

/Home/Edit/Junk

тогда id будет нулевым, что довольно круто. Я думал, что это вызовет ошибку приведения или что-то в этом роде. Это означает, что если id не является нулевым значением, то оно является допустимым целым числом и может быть передано вашим службам и т. Д. Для взаимодействия с БД.

Надеюсь, это даст вам некоторую информацию, которую я нашел во время тестирования.

Answer 3

В ASP.NET MVC вы можете определить фильтр, реализующий интерфейс IActionFilter. Вы сможете украсить свое действие этим атрибутом, чтобы оно выполнялось до, после или после вашего действия.

В вашем случае вы определите, что это должно быть выполнено "до" вашего действия. Таким образом, вы сможете отменить его, если в переданных параметрах будет ошибка. Ключевое преимущество здесь в том, что вы пишете только тот код, который проверяет переданные параметры один раз (т. Е. Вы определяете его в своем фильтре) и используете его везде, где хотите в действиях вашего контроллера.

Подробнее о фильтрах MVC читайте здесь: http://haacked.com/archive/2008/08/14/aspnetmvc-filters.aspx

Answer 4

Вы можете указать ограничения как регулярные выражения или определить пользовательские ограничения. Загляните в этот блог для получения дополнительной информации:

http://weblogs.asp.net/stephenwalther/archive/2008/08/06/asp-net-mvc-tip-30-create-custom-route-constraints.aspx

Вам все равно придется иметь дело с ситуацией, когда id 43243 не сопоставляется ни с чем, что может рассматриваться как IActionFilter или непосредственно в вашем контроллере.

Answer 5

Проблема этого подхода заключается в том, что они могут передавать целое число, которое не отображается на странице. Просто верните 404, если они это сделают, так же, как вы это сделали бы с «foo». Не о чем беспокоиться, если у вас нет явных последствий для безопасности.