C # MVC: конечный знак равенства в URL не попадает в маршрут

Question

У меня есть маршрут MVC, подобный этому www.example.com/Find?Key=, где ключом является строка Base64. Проблема в том, что строка Base64 иногда имеет завершающий знак равенства (=), такой как:

huhsdfjbsdf2394 =

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

Что я должен сделать, чтобы решить эту проблему?

Мой маршрут:

routes.MapRoute(
    "FindByKeyRoute", 
    "Find",
    new { controller = "Search", action = "FindByKey" }
);

Если у меня есть http://www.example.com/Find?Key=bla, тогда это работает.

Если у меня http://www.example.com/Find?Key=bla=, он больше не работает.

Важное дополнение :
Я пишу против экземпляра IIS7, что не разрешает% или подобное кодирование . Вот почему я не использовал UrlEncode для начала.

Answer 1

РЕДАКТИРОВАТЬ: оригинальное предложение, которое, очевидно, не работает

Я уверен, что причина в том, что он считает, что это параметр запроса с именем Key. Не могли бы вы сделать это параметром, причем эта часть является значением, например,

www.example.com/Find?Route=Key=

Я ожидаю, что будет работать (так как парсер будет искать & для запуска следующего параметра), но возможно, что он все еще запутает.

Предложение, которое, как я считаю, сработает

В качестве альтернативы, замените «=» в закодированном значении base64 на что-то другое при выходе и повторно замените его на обратном пути, если вы понимаете, о чем я. В основном используйте другой dec64abet base64.

Альтернативное предложение, которое должно работать

Перед добавлением base64 к URL:

private static readonly char[] Base64Padding = new char[] { '=' };
...
base64 = base64.TrimEnd(Base64Padding);

Затем перед вызовом Convert.FromBase64String() (что, как я полагаю, вы делаете) для входящего запроса:

// Round up to a multiple of 4 characters.
int paddingLength = (4 - (base64.Length % 4)) % 4; 
base64 = base64.PadRight(base64.Length + paddingLength, '=');

Answer 2

Если вы передаете данные в URL, вам, вероятно, следует указать URL. Закодируйте его, чтобы позаботиться о конце =.

http://www.albionresearch.com/misc/urlencode.php

Answer 3

UrlEncode зашифрованный (он зашифрован, верно?) Параметр.

Если это зашифрованная строка, помните, что пробелы и символ + также будут мешать вам.

---

Хорошо, поэтому IIS 7 не позволяет использовать некоторые специальные символы в качестве части вашего пути. Однако это позволило бы им, если бы они были частью строки запроса.

По-видимому, возможно изменить это с помощью обычного хака, но я бы не рекомендовал этого.

В таком случае я бы предложил использовать альтернативный токен, как это было предложено г-ном Скитом, или просто не использовать его на своем пути, использовать его как строку запроса, где вы МОЖЕТЕ url кодировать его.

Если это зашифрованная строка, вы не убедились, что она есть или нет, в некоторых случаях вы можете получить другие «незаконные» символы. Querystring действительно будет путь.

---

За исключением того, что ваш пример показывает его как строку запроса ... Так что же дает? Где вы нашли IIS, который не разрешает стандартное кодирование URI как часть строки запроса?

---

Хорошо, тогда. Спасибо за обновление.

RequestFiltering ? Понимаю. Тем не менее, он упоминает двойные значения, которые он блокирует. Кто-то создал последовательность URL, чтобы отклонить любой запрос с символами «%»? В этот момент вы можете вообще не использовать зашифрованную строку, а генерировать GUID или что-то еще, что гарантированно не будет содержать специальных символов, но не будет легко догадаться.