2009-06-02 17 views
2

Ich habe eine MVC-Route wie diese www.example.com/Find?Key= mit dem Schlüssel ist eine Base64-Zeichenfolge. Das Problem ist, dass die Base64-Zeichenfolge manchmal ein nachstehendes Gleichheitszeichen (=) wie "huhsdfjbsdf2394 =" hat.C# MVC: Trailing Gleichheitszeichen in URL nicht Route

Wenn das passiert, wird meine Route aus irgendeinem Grund nicht mehr getroffen.

Was soll ich tun, um dies zu beheben?

Meine Route:

routes.MapRoute(
    "FindByKeyRoute", 
    "Find", 
    new { controller = "Search", action = "FindByKey" } 
    ); 

Wenn ich http://www.example.com/Find?Key=bla haben, dann funktioniert es.

Wenn ich http://www.example.com/Find?Key=bla= habe, dann funktioniert es nicht mehr.

wichtige Ergänzung: Ich schreibe gegen eine IIS7 Instanz, dass nicht% oder ähnliche Codierung zulässt. Aus diesem Grund habe ich UrlEncode nicht verwendet.

+0

Was ist Ihr 'RouteCollection' aussehen? –

+0

Hinzugefügt in meiner Frage. – Alex

+0

Ich möchte immer noch wissen, wo Sie einen IIS gefunden haben, der keine Standard-URI-Codierung für Querystring-Parameter akzeptiert? –

Antwort

3

EDIT: Original-Vorschlag, die offenbar nicht

Ich bin sicher, dass der Grund dafür ist, dass es denkt, es ist ein Abfrageparameter Key genannt funktioniert. Könnten Sie es zu einem Parameter machen, wobei dieser Teil der Wert ist, z.

www.example.com/Find?Route=Key= 

ich erwarten, die funktionieren würde (wie der Parser für eine & suchen würde, um den nächsten Parameter zu starten), aber es ist möglich, es Dinge noch verwirren werden.

Anregung, die ich glaube, arbeitet

Alternativ ersetzen „=“ in der Base64-codierten Wert mit etwas anderes auf dem Weg nach draußen und wieder ersetzt sie auf dem Weg zurück in, wenn Sie sehen, was Ich meine. Verwenden Sie grundsätzlich ein anderes base64 decodabet.

Alternativvorschlag, die

Vor dem Hinzufügen von base64 an die URL funktionieren sollte:

private static readonly char[] Base64Padding = new char[] { '=' }; 
... 
base64 = base64.TrimEnd(Base64Padding); 

Dann Convert.FromBase64String() vor dem Aufruf (das ist, was ich nehme an, Sie tun) auf dem eingehenden Anfrage:

// Round up to a multiple of 4 characters. 
int paddingLength = (4 - (base64.Length % 4)) % 4; 
base64 = base64.PadRight(base64.Length + paddingLength, '='); 
+0

Das ist was ich auch though (in Bezug auf den Parser auf der Suche nach & = anstelle von nur = von sich selbst) ... Das saugt Ich möchte nicht gezwungen werden, zusätzliche Komplexität ohne wirklichen Grund einzuführen. Duh – Alex

+0

Könnten Sie eine Erklärung hinzufügen, was Ihr Code für alternative Vorschläge macht? Danke :) – Alex

+0

sollte es base64 = base64.PadRight sein (base64.Length + paddedLength, '='); – Alex

1

UrlEncode den verschlüsselten (es ist verschlüsselt, richtig?) Parameter.

Wenn es sich um eine verschlüsselte Zeichenfolge handelt, achten Sie darauf, dass Leerzeichen und das Zeichen + ebenfalls in Ihre Richtung gelangen.


OK, so dass IIS 7 einige Sonderzeichen nicht als Teil Ihres Pfades zulassen wird. Es würde ihnen jedoch erlauben, wenn sie Teil der Querystring wären.

Es ist anscheinend möglich, dies mit einem reg Hack zu ändern, aber ich würde das nicht empfehlen.

Ich würde dann vorschlagen, ein alternatives Token zu verwenden, wie von Mr. Skeet vorgeschlagen, oder einfach nicht in Ihrem Pfad verwenden, verwenden Sie es als Querystring, wo Sie es codieren können.

Wenn es sich um eine verschlüsselte Zeichenfolge handelt, die Sie nicht verifiziert haben oder nicht, können Sie in einigen Fällen andere "ungültige" Zeichen erhalten. Querystring wäre wirklich der richtige Weg.


Nur Ihre Probe zeigt es als Querystring ... Also was gibt? Wo haben Sie einen IIS gefunden, der keine standardmäßige URI-Kodierung als Teil der Querystring-Anweisung zulässt?


Ok dann. Danke für das Update.

RequestFiltering? Ich verstehe. Immer noch erwähnt das doppelt codierte Werte, die es blockiert. Jemand hat eine URL-Sequenz erstellt, um Anfragen mit den Zeichen "%" zu verweigern. An diesem Punkt möchten Sie vielleicht die verschlüsselte Zeichenfolge überhaupt nicht verwenden, sondern eine GUID oder etwas anderes generieren, das garantiert keine Sonderzeichen enthält, aber nicht einfach zu erraten ist.

+0

Ich habe den Base64-String bereits "url friendly" gemacht, indem ich "+" durch "-" und "/" durch "_" ersetzt habe. Base64 codiert nicht in Leerzeichen. – Alex

+0

eine URL-Codierung würde teh = zu% 3D – Venr

+1

Genau. URL kodieren. Mach es nicht selbst. Sie werden nie alles bei Ihren ersten Versuchen erwischen. –