Potencjalnie niebezpieczna wartość Request.Path została wykryta przez klienta (*)

Otrzymuję raczej oczywisty błąd:

Potencjalnie niebezpieczna wartość Request.Path została wykryta przez klienta (*).

Problem wynika *z adresu URL żądania:

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

Ten adres URL jest używany do wypełnienia strony wyszukiwania, gdzie „test *” jest wyszukiwanym terminem, a reszta adresu dotyczy różnych innych filtrów.

Czy istnieje prosty sposób, aby zezwolić na te znaki specjalne w adresie URL? Próbowałem zmienić web.config, ale bezskutecznie.

Czy powinienem ręcznie kodować / dekodować znaki specjalne? Czy jest to najlepsza praktyka w tym zakresie, chciałbym unikać używania ciągów zapytań. - ale może to być opcja.

Sama aplikacja jest c# asp.netaplikacją internetową, która używa routingu do utworzenia powyższego ładnego adresu URL.

*Postać nie jest dozwolone w ścieżce URL, ale nie ma problemu z wykorzystaniem go w ciągu zapytania:

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

To nie jest problem z kodowaniem, *znak nie ma specjalnego znaczenia w adresie URL, więc nie ma znaczenia, czy kodujesz go, czy nie. Musisz zakodować go przy użyciu innego schematu, a następnie odkodować.

Na przykład użycie dowolnego znaku jako znaku zmiany znaczenia:

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

I dekodowanie:

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

Jeśli korzystasz z .NET 4.0, powinieneś być w stanie zezwolić na te adresy URL poprzez web.config

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

Uwaga, właśnie usunąłem gwiazdkę (*), oryginalny domyślny ciąg to:

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

Zobacz to pytanie, aby uzyskać więcej informacji.

Dla mnie, pracuję nad .net 4.5.2 z web api 2.0, mam ten sam błąd, ustawiłem go, dodając requestPathInvalidCharacters = "" w requestPathInvalidCharacters, które musisz ustawić niedozwolone znaki, w przeciwnym razie musisz usunąć znaki, które powodować ten problem.

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

** Pamiętaj, że nie jest to dobra praktyka, może być postem z tym parametrem, ponieważ atrybut obiektu jest lepszy lub spróbuj zakodować znak specjalny. - Po wyszukaniu najlepszych praktyk dotyczących projektowania interfejsu API spoczynku odkryłem, że w wyszukiwaniu, sortowaniu i paginacji musimy obsługiwać parametr zapytania w ten sposób

/companies?search=Digital%26Mckinsey

i to rozwiązuje problem, gdy kodujemy i przemieszczamy go na adres URL o% 26 w jakikolwiek sposób, na serwerze otrzymujemy poprawny parametr Digital & Mckinsey

ten link może pomóc w najlepszych praktykach projektowania interfejsu API pozostałej strony https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

Powinieneś zakodować wartość trasy, a następnie (jeśli to konieczne) zdekodować wartość przed wyszukiwaniem.

Dla mnie, wpisując adres URL, użytkownik przypadkowo użył / zamiast? aby uruchomić parametry zapytania

na przykład:

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

który powinien być:

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

Ten wyjątek wystąpił w mojej aplikacji i był raczej mylący.

Został zgłoszony, gdy wywoływałem metodę WWW strony .aspx za pomocą wywołania metody ajax, przekazując obiekt tablicy JSON. Podpis metody strony internetowej zawiera tablicę silnie typowanego obiektu .NET, OrderDetails. Właściwość Actual_Qty została zdefiniowana jako int, a właściwość Actual_Qty obiektu JSON zawierała „4” (znak spacji). Po usunięciu dodatkowego miejsca konwersja była możliwa, metoda strony WWW została pomyślnie osiągnięta przez wywołanie ajax.

Spróbuj ustawić właściwość serwera projektu WWW jako Lokalny IIS, jeśli jest to IIS Express. Upewnij się, czy adres projektu jest poprawny i utwórz katalog wirtualny.

W przypadku Uniform Resource Locator (URL) istnieją pewne standardy składniowe , w tej konkretnej sytuacji mamy do czynienia z zarezerwowanymi znakami .

Podobnie jak w przypadku RFC 3986 , Znaki Zarezerwowane mogą (lub nie muszą) być zdefiniowane jako ograniczniki przez ogólną składnię, każdą składnię specyficzną dla schematu lub przez składnię specyficzną dla implementacji algorytmu dereferencji URI; Gwiazdka (*) jest postacią zarezerwowaną.

Najlepszą praktyką jest używanie niezarezerwowanych znaków w adresach URL lub możesz spróbować je zakodować.

Kop dalej :

• Dokumentacja kodowania URL HTML (w3schools)
• Kiedy kodować lub dekodować (RFC 3986)