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

218

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

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

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

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

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

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

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

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

— samdd
источник

1

Ваша страница ValidateRequest=falseвверху?

— Нил Найт

Я не знаю, по какой причине веб-сайт внутренне пытался перенаправить, который создавал URL-адрес типа « localhost /: // localhost / myWebsiteName », который выдавал мне ту же ошибку. Я не знаю, почему конвейер ASP.net считает это опасным URL запроса.

— RBT

97

Символ *не разрешен в пути 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");

— Guffa
источник

15

Игра "xxx", "xxy", "xyy" довольно умная. Возможно, вы захотите уточнить логику этого, чтобы не запутать читателей.

— SimpleVar

2

Запрос был использовать его в PATHстроке, а не в строке запроса.

— Хьюго Делсинг

Я столкнулся с тем же сценарием, где одним из моих параметров был URL. Даже при правильном кодировании URL я получу эту ошибку. Я, наконец, просто base64 закодировал параметр (и декодировал в моем API), что было гораздо проще, чем пытаться выяснить, что происходит. Вероятно, лучший выбор, который также реализует вашу собственную процедуру замены.

— SpokaneDJ

1

Разве вы не можете использовать aa<=> aи ab<=> *в качестве более простой схемы кодирования?

— Слова,

Пока это меня спасло, спасибо, но в свое время я хочу проверить этот совет: stackoverflow.com/a/603962/1830909 и я буду рад, если услышу вашу мысль.

— QMaster

316

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

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

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

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

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

— Дэйв Трансом
источник

5

Любой способ сделать это с помощью атрибута mvc в действии, чтобы мне не пришлось отключать это для всего приложения? Аналогично этому ответу здесь: stackoverflow.com/a/1540976/298758

— Longda

4

@longda: возможно, попробуйте обернуть его элементом <location path = "my / path"> для нужного вам URL. Использование отражения было бы достаточно простым с глобальной точки зрения, но я не уверен в том, чтобы установить его для каждого контроллера / действия. Может быть, начать вопрос?

— Дэйв Трансом

Он просто не работает над проектом ASP.net MVC, получая процесс запуска для определения макета в viewStart, получая эту ошибку: Недопустимый символ в пути.

— QMaster

7

Для меня, я работаю на .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

— МНФ
источник

6

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

— Tejs
источник

Спасибо за ваш ответ. Вы имеете в виду, что effectivley выполняет замену таких элементов, как *, а затем заменяет их обратно, когда вы читаете это?

Можете ли вы показать пример кода кодирования и декодирования значений?

— Кьяран Галлахер

1

Для меня при вводе URL пользователь случайно использовал / вместо? запустить параметры запроса

например:

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

который должен был быть:

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value

— trykyn
источник

Да, даже то же самое для меня url.com/endpoint¶meter=SomeValue&otherparameter=AnotherValue

— Конда,

0

Это исключение произошло в моем заявлении и было довольно обманчивым.

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

— Берта
источник

0

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

— Берк
источник

0

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

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

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

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

— Рошана Питигала
источник

1

Эта ошибка также возникает, если зарезервированный символ в URL-адресе кодируется в процентах, например %25вместо %, поэтому IIS может вернуть эту ошибку для совершенно корректного URL-адреса.

— Флориан, зима,