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

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

3 голосов
/ 09 января 2012

Мое веб-приложение 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 - неверный запрос. Это означает, что есть проблема с URL, который я не вижу.

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

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

URL выглядят так: 

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

и они прекрасно работают ...

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

1 Ответ

4 голосов
/ 09 января 2012

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

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

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

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

...