Une valeur Request.Path potentiellement dangereuse a été détectée par le client (*)

Je reçois l’erreur plutôt explicite:

Une valeur Request.Path potentiellement dangereuse a été détectée par le client (*).

Le problème est dû à * dans l’URL de la demande:

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

Cette URL est utilisée pour renseigner une page de recherche où «test *» est le terme recherché et le rest de l’URL concerne divers autres filtres.

Existe-t-il un moyen facile d’autoriser ces caractères spéciaux dans l’URL? J’ai essayé de modifier le web.config , en vain.

Dois-je encoder / décoder manuellement les caractères spéciaux? Ou existe-t-il une bonne pratique pour ce faire, je voudrais éviter d’utiliser des chaînes de requête. – mais cela peut être une option.

L’application elle-même est une application c# asp.net webforms qui utilise le routage pour produire la bonne URL ci-dessus.

    Le caractère * n’est pas autorisé dans le chemin de l’URL, mais il n’y a aucun problème à l’utiliser dans la chaîne de requête:

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

    Ce n’est pas un problème d’encodage, le caractère * n’a pas de signification particulière dans une URL, donc peu importe si votre URL le code ou non. Vous devrez l’encoder en utilisant un schéma différent, puis le décoder.

    Par exemple, utiliser un caractère arbitraire comme caractère d’échappement:

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

    Et décodage:

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

    Si vous utilisez .NET 4.0, vous devriez pouvoir autoriser ces URL via le fichier web.config

        

    Notez que je viens de supprimer l’astérisque (*), la chaîne par défaut d’origine est:

      

    Voir cette question pour plus de détails.

    Vous devez encoder la valeur de la route, puis (si nécessaire) décoder la valeur avant la recherche.

    En ce qui concerne les URL (Uniform Resource Locator), il existe certaines normes de syntaxe , dans cette situation particulière, nous traitons des caractères réservés .

    Comme pour la RFC 3986 , les caractères réservés peuvent être (ou non) définis comme des délimiteurs par la syntaxe générique, par chaque syntaxe spécifique au système ou par la syntaxe spécifique à l’implémentation de l’algorithme de déréférencement de l’URI; Et l’astérisque (*) est un caractère réservé.

    La meilleure pratique consiste à utiliser des caractères non réservés dans les URL ou vous pouvez essayer de les encoder avec java.net.URLEncoder .

    Continue à creuser :

    • Codage de l’URL Java des parameters de la chaîne de requête
    • Référence d’encodage d’URL HTML (w3schools)
    • Quand encoder ou décoder (RFC 3986)
    • Comment extraire les parameters d’une URL donnée

    Pour moi, je travaille sur .net 4.5.2 avec web api 2.0, j’ai la même erreur, je l’ai définie en ajoutant requestPathInvalidCharacters = “” dans requestPathInvalidCharacters, vous devez définir des caractères non autorisés sinon vous devez supprimer des caractères qui provoquer ce problème.

         ....    

    ** Notez que ce n’est pas une bonne pratique, peut être un post avec ce paramètre car l’atsortingbut d’un object est mieux ou essayez d’encoder le caractère spécial. – Après avoir recherché les meilleures pratiques pour concevoir des API de repos, j’ai trouvé que dans la recherche, le sorting et la pagination, nous devons gérer le paramètre de requête comme celui-ci.

     /companies?search=Digital%26Mckinsey 

    et cela résout le problème lorsque nous encodons & et le remplaçons sur l’URL par% 26 de toute façon, sur le serveur nous recevons le paramètre correct Digital & Mckinsey

    ce lien peut aider sur la meilleure pratique de la conception des applications web restantes https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

    Cette exception s’est produite dans ma demande et était plutôt trompeuse.

    Il a été lancé lorsque j’appelais une méthode Web de page .aspx à l’aide d’un appel de méthode ajax, en passant un object de tableau JSON. La signature de méthode de la page Web contenait un tableau d’un object .NET fortement typé, OrderDetails. La propriété Actual_Qty a été définie en tant que int et la propriété Actual_Qty de l’object JSON contenait “4” (caractère d’espace supplémentaire). Après avoir supprimé l’espace supplémentaire, la conversion a été rendue possible, la méthode de la page Web a été atteinte avec succès par l’appel ajax.

    Essayez de définir la propriété du serveur du projet Web en tant qu’IIS local s’il s’agit d’IIS Express. Assurez-vous que l’URL du projet est correcte et créez un répertoire virtuel.