Обработка URL-адресов с помощью ASP.NET MVC

Question

Мое веб-приложение MVC создает ссылку активации, которая может содержать любой символ (%, +,/и т. Д.). Я URL кодировать строку и сгенерировать ссылку:

new UrlHelper(HttpContext.Current.Request.RequestContext) 
     .RouteUrl("AccountActivation", 
       new { id = HttpContext.Current.Server.UrlEncode(activationString) }; 

затем добавить домен, и это выглядит как:

http://localhost/AccountActivation/asdlkj223%25asd%2Basw3fgasdme 

URL, затем передается пользователю.

Маршрут в этом случае:

routes.MapRoute(
      "ActivateAccount", 
      "AccountActivation/{id}", 
      new { controller = "Account", action = "Activate", id = ""});  

Казалось хорошо для меня, но сервер разработки ASP.NET и IIS дает мне ошибку HTTP 400 - Bad запрос. Это означает, что проблема с URL-адресом, который я не вижу.

Когда избавиться от {ID} в описании маршрута (я также пытался {* идентификатор} без успеха):

routes.MapRoute(
      "ActivateAccount", 
      "AccountActivation", 
      new { controller = "Account", action = "Activate"}); 

URL, выглядит следующим образом:

http://AccountActivation?id=asdlkj223%25asd%2Basw3fgasdme 

и они работа просто отлично ...

Я, хотя эти 2 подхода делают то же самое. В чем разница между ними? Является ли это MVC-движок для чего-то большего для меня, или я что-то пропускаю с кодировкой URL.

Answer 1

Попробуйте UrlPathEncode вместо UrlEncode - некоторые символы являются незаконными в пути, которые являются законными в строке запроса.

Это сказало - я считаю, что анализ того, является ли символ «плохим», выполняется после декодирования пути; и выполняется IIS. Он отклонит некоторые символы из-за того, что URL-адрес сопоставляется с физической файловой системой, и поэтому может разрешить пользователю доступ к вещам, к которым у них действительно не должно быть доступа. В равной степени это делается для предотвращения отправки запросов, которые действительно не должны отправляться.

Обычно, если нет возможности использовать параметр, сопоставленный как параметр маршрута, то не пытайтесь слишком сложно его сопоставить - особенно в этом случае, когда строка может быть чем угодно.

Кстати, если это кодирование двоичных данных; вместо этого вы можете вместо этого использовать шестнадцатеричное кодирование или вместо этого использовать modified base-64 for URLs - что не приведет к ошибкам, если будет отображаться как параметр маршрута.