От клиента было обнаружено потенциально опасное значение Request.Path (*)

Question

Я получаю довольно очевидную ошибку:

Потенциально опасное значение Request.Path обнаружено клиентом (*).

Проблема связана с * в URL запроса:

https://stackoverflow.com/Search/test*/0/1/10/1

Этот URL-адрес используется для заполнения страницы поиска, где 'test *' является поисковым термином, а остальная часть URL-адреса относится к различным другим фильтрам.

Есть ли простой способ разрешить использование этих специальных символов в URL? Я пытался изменить web.config, но безрезультатно.

Должен ли я вручную кодировать / декодировать специальные символы? Или есть лучший способ сделать это, я хотел бы избежать использования строк запроса. - но это может быть вариант.

Само приложение является c# asp.net приложением веб-форм, которое использует маршрутизацию для создания приведенного выше симпатичного URL.

Answer 1

Если вы используете .NET 4.0, вы можете разрешить эти URL через web.config

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

Обратите внимание, я только что удалил звездочку (*), исходная строка по умолчанию:

<httpRuntime 
          requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?" />

См. этот вопрос для более подробной информации.

Answer 2

Символ * недопустим в пути URL, но нет проблем с его использованием в строке запроса:

http://localhost:3286/Search/?q=test*

Это не проблема кодирования, символ * не имеет особого значения в URL, поэтому не имеет значения, кодируете ли вы его URL или нет. Вам нужно будет закодировать его по другой схеме, а затем декодировать.

Например, используя произвольный символ в качестве escape-символа:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

И расшифровка:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

Answer 3

Вы должны кодировать значение маршрута и затем (если требуется) декодировать значение перед поиском.

Answer 4

Для меня, я работаю на .net 4.5.2 с веб-API 2.0, у меня та же ошибка, я установил ее, просто добавив requestPathInvalidCharacters = "" в requestPathInvalidCharacters, вы должны установить недопустимые символы, иначе вы должныудалить символы, которые вызывают эту проблему.

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

** Обратите внимание, что это не очень хорошая практика, возможно, это публикация с этим параметром, так как атрибут объекта лучше, или попытка закодировать специальный символ.- После поиска лучших рекомендаций по созданию остальных API-интерфейсов я обнаружил, что при поиске, сортировке и разбивке на страницы мы должны обрабатывать параметр запроса, подобный этому

/companies?search=Digital%26Mckinsey

, и это решает проблему, когда мы кодируем & ипоменяйте его на URL на% 26 любым способом, на сервере мы получим правильный параметр Digital & Mckinsey

, эта ссылка может помочь в наилучшей практике проектирования остальных веб-API https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

Answer 5

Попробуйте установить сервер веб-проекта как локальный IIS, если это IIS Express.Убедитесь в правильности URL проекта и создайте виртуальный каталог.

Answer 6

При работе с Uniform Resource Locator (URL) существуют определенные стандарты синтаксиса , в этой конкретной ситуации мы имеем дело с зарезервированными символами .

Начиная с RFC 3986 , зарезервированные символы могут (или не могут) быть определены как разделители по общему синтаксису, по каждому синтаксису схемы или по специфическому для реализации синтаксису разыменования URI алгоритм; А звездочка (*) является зарезервированным символом.

Рекомендуется использовать незарезервированные символы в URL-адресах, или вы можете попробовать закодировать его.

Продолжай копать:

• Справочник по кодированию HTML-URL (w3schools)
• Когда кодировать или декодировать (RFC 3986)

Answer 7

Это исключение возникло в моем приложении и вводило в заблуждение.

Это было вызвано, когда я вызывал веб-метод страницы .aspx с использованием вызова метода ajax, передавая объект массива JSON.Подпись метода Web Page содержит массив строго типизированного объекта .NET, OrderDetails.Свойство Actual_Qty было определено как int, а свойство Actual_Qty объекта JSON содержало «4» (дополнительный пробел).После удаления лишнего пробела преобразование стало возможным, метод веб-страницы был успешно достигнут вызовом ajax.