Se detectó un valor Request.Path potencialmente peligroso del cliente (*)

Estoy recibiendo el error bastante autoexplicativo:

Se detectó un valor Request.Path potencialmente peligroso del cliente (*).

El problema se debe a *la URL de solicitud:

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

Esta url se usa para completar una página de búsqueda donde 'test *' es el término de búsqueda y el resto de la url se relaciona con otros filtros.

¿Hay alguna manera fácil de permitir estos caracteres especiales en la URL? He intentado modificar el web.config, en vano.

¿Debo codificar / decodificar manualmente los caracteres especiales? O hay una mejor práctica para hacer esto, me gustaría evitar el uso de cadenas de consulta. - Pero puede ser una opción.

La aplicación en sí es una c# asp.netaplicación de formularios web que utiliza el enrutamiento para producir la buena URL anterior.

El *carácter no está permitido en la ruta de la URL, pero no hay ningún problema al usarlo en la cadena de consulta:

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

No es un problema de codificación, el *carácter no tiene un significado especial en una URL, por lo que no importa si la URL la codifica o no. Tendría que codificarlo usando un esquema diferente y luego decodificarlo.

Por ejemplo, utilizando un carácter arbitrario como carácter de escape:

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

Y decodificación:

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

Si está utilizando .NET 4.0, debería permitir estas URL a través de web.config

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

Tenga en cuenta que acabo de eliminar el asterisco (*), la cadena predeterminada original es:

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

Vea esta pregunta para más detalles.

Para mí, estoy trabajando en .net 4.5.2 con la API web 2.0, tengo el mismo error, lo configuré simplemente agregando requestPathInvalidCharacters = "" en requestPathInvalidCharacters, debe establecer caracteres no permitidos, de lo contrario, debe eliminar los caracteres que causar este problema

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

** Tenga en cuenta que no es una buena práctica, puede ser una publicación con este parámetro ya que el atributo de un objeto es mejor o tratar de codificar el carácter especial. - Después de buscar las mejores prácticas para diseñar la API de descanso, descubrí que en la búsqueda, la ordenación y la paginación, tenemos que manejar el parámetro de consulta de esta manera

/companies?search=Digital%26Mckinsey

y esto resuelve el problema cuando codificamos & y lo reubicamos en la url en% 26 de cualquier manera, en el servidor recibimos el parámetro correcto Digital & Mckinsey

este enlace puede ayudar con las mejores prácticas de diseño de la API de web de descanso https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

Debe codificar el valor de la ruta y luego (si es necesario) decodificar el valor antes de buscar.

Para mí, al escribir la url, ¿un usuario usó accidentalmente un / en lugar de un? para iniciar los parámetros de consulta

p.ej:

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

que debería haber sido:

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

Esta excepción ocurrió en mi solicitud y fue bastante engañosa.

Fue lanzado cuando estaba llamando a un método web de página .aspx usando una llamada a método ajax, pasando un objeto de matriz JSON. La firma del método de la página web contenía una matriz de un objeto .NET fuertemente tipado, OrderDetails. La propiedad Actual_Qty se definió como un int, y la propiedad Actual_Qty del objeto JSON contenía "4" (carácter de espacio adicional). Después de eliminar el espacio extra, la conversión fue posible, el método de página web fue alcanzado con éxito por la llamada ajax.

Intente configurar el servidor del proyecto web correctamente como Local IIS si es IIS Express. Asegúrese de que la URL del proyecto sea correcta y cree un directorio virtual.

Cuando se trata de localizadores uniformes de recursos (URL) hay ciertos estándares de sintaxis , en esta situación particular estamos tratando con caracteres reservados .

Hasta RFC 3986 , los caracteres reservados pueden (o no) definirse como delimitadores por la sintaxis genérica, por cada sintaxis específica de esquema o por la sintaxis específica de implementación de un algoritmo de referencia de URI; Y el asterisco (*) es un carácter reservado.

La mejor práctica es utilizar caracteres no reservados en las URL o puede intentar codificarlo.

Sigue cavando :

• Referencia de codificación de URL HTML (w3schools)
• Cuándo codificar o decodificar (RFC 3986)