it-swarm.com.de

Ein potenziell gefährlicher Request.Path-Wert wurde vom Client erkannt (*)

Ich erhalte den eher selbsterklärenden Fehler:

Ein potenziell gefährlicher Request.Path-Wert wurde vom Client (*) erkannt.

Das Problem ist auf * in der Anforderungs-URL zurückzuführen:

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

Diese URL wird verwendet, um eine Suchseite auszufüllen, wobei "test *" der Suchbegriff ist und der Rest der URL sich auf verschiedene andere Filter bezieht.

Gibt es eine einfache Möglichkeit, diese Sonderzeichen in der URL zuzulassen? Ich habe versucht, den web.config zu ändern, ohne Erfolg.

Soll ich die Sonderzeichen manuell codieren/decodieren? Oder gibt es eine bewährte Methode, um die Verwendung von Abfragezeichenfolgen zu vermeiden. - aber es kann eine Option sein.

Die Anwendung selbst ist eine c# asp.net-Webforms-Anwendung, die mithilfe von Routing die oben angegebene Nice-URL erstellt.

188
user336245

Das *-Zeichen ist im Pfad der URL nicht zulässig, es ist jedoch kein Problem bei der Verwendung der Abfragezeichenfolge:

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

Es handelt sich nicht um ein Codierungsproblem. Das Zeichen * hat keine besondere Bedeutung in einer URL. Es ist also egal, ob Sie die URL codieren oder nicht. Sie müssten es mit einem anderen Schema codieren und dann decodieren.

Verwenden Sie zum Beispiel ein beliebiges Zeichen als Escape-Zeichen:

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

Und entschlüsseln:

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

Wenn Sie .NET 4.0 verwenden, sollten Sie diese URLs über die web.config zulassen können

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

Hinweis: Ich habe gerade das Sternchen (*) entfernt. Die ursprüngliche Standardzeichenfolge lautet:

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

Siehe diese Frage für weitere Details.

289
Dave Transom

Sie sollten den Routenwert codieren und dann (falls erforderlich) den Wert vor der Suche decodieren. 

4
Tejs

Für mich arbeite ich an .net 4.5.2 mit web api 2.0, Ich habe den gleichen Fehler. Ich habe ihn nur durch das Hinzufügen von requestPathInvalidCharacters = "" "In den requestPathInvalidCharacters festgelegt Sie müssen Zeichen entfernen, die dieses Problem verursachen. 

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

** Beachten Sie, dass dies keine bewährte Methode ist. Möglicherweise handelt es sich dabei um einen Beitrag mit diesem Parameter, da das Attribut eines Objekts besser ist, oder versuchen Sie, das Sonderzeichen zu codieren Bei der Suche, Sortierung und Paginierung müssen wir den Abfrageparameter wie folgt behandeln

/companies?search=Digital%26Mckinsey

und dies löst das Problem, wenn wir es verschlüsseln und von% 26 auf der URL entfernen. Auf dem Server erhalten wir den korrekten Parameter Digital & Mckinsey

dieser Link kann zur bewährten Vorgehensweise beim Entwerfen von Rest-Web-APIs beitragen https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

4
MNF

Beim Umgang mit Uniform Resource Locator (URL) gibt es bestimmte Syntaxstandards . In dieser speziellen Situation handelt es sich um Reserved Characters.

Bis zu RFC 3986 können reservierte Zeichen durch die generische Syntax, durch jede schemaspezifische Syntax oder durch die implementierungsspezifische Syntax des Dereferenzierungsalgorithmus eines URIs als Begrenzer definiert werden; Und Sternchen (*) ist ein reserviertes Zeichen.

Es empfiehlt sich, Nicht reservierte Zeichen in URLs zu verwenden, oder Sie können versuchen, sie zu kodieren.

Graben Sie weiter:

1

Versuchen Sie, die Servereigenschaft des Webprojekts als Local IIS festzulegen, wenn es sich um IIS Express handelt. Stellen Sie sicher, dass die Projekt-URL richtig ist, und erstellen Sie ein virtuelles Verzeichnis.

0
Burk

Diese Ausnahme trat in meiner Bewerbung auf und war eher irreführend.

Es wurde geworfen, als ich eine ASPX-Seiten-Webmethode mit einem Aufruf der Ajax-Methode aufrief und ein JSON-Array-Objekt übergab. Die Webseitenseitensignatur enthielt ein Array eines stark typisierten .NET-Objekts, OrderDetails . Die Actual_Qty-Eigenschaft wurde als int definiert, und das JSON-Objekt Actual_Qty-Eigenschaft enthielt "4" (zusätzliches Leerzeichen). Nachdem der zusätzliche Speicherplatz entfernt wurde, wurde die Konvertierung ermöglicht, und die Web-Page-Methode wurde erfolgreich vom Ajax-Aufruf erreicht.

0
Bertha

Bei der Eingabe der URL hat ein Benutzer versehentlich ein/anstelle eines? um die Abfrageparameter zu starten

z.B.:

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

was hätte sein sollen:

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

0
trykyn