fragen stichworte

F5 Networks iRule / Tcl - Escape-Sequenzen von UNICODE mit 6 Zeichen, so dass sie als 6-Zeichen-Sequenz verarbeitet und erneut eingefügt werden?

Wir versuchen, dass eine F5 BIG-IP LTM-iRule ordnungsgemäß mit SharePoint 2007 als SSL-Beendigungsrolle verwendet wird. Diese Architektur entlastet die gesamte SSL-Verarbeitung auf dem F5, und der F5 leitet interaktive Anfragen/Antworten nur über HTTP (über ein sicheres Netzwerk) an die SharePoint-Front-End-Server weiter.

Für die Zwecke dieser Diskussion werden iRules von einem Tcl-Interpretationsmodul auf dem BIG-IP-Gerät von F5 Networks analysiert.

Der F5 tut also zwei Dinge für den Verkehr, der ihn durchläuft:

  1. Leitet alle Anfragen an Port 80 (HTTP) an Port 443 (HTTPS) über HTTP 302-Weiterleitungen und URL-Überschreiben um.
  2. Schreibt jede Antwort an den Browser um, um in den HTML-Code eingebettete URLs so umzuschreiben, dass sie an Port 443 (HTTPS) gelangen. Dadurch wird verhindert, dass die 302 Weiterleitungen die von SharePoint generierte DHTML beschädigen.

Teil 1 funktioniert gut.

Das Hauptproblem bei Teil 2 besteht darin, dass in der Antwort aufgrund von XML-Namespaces und anderen ähnlichen Problemen nicht alle Übereinstimmungen für "http:" in "https:" geändert werden können. Einige müssen "http:" bleiben. Darüber hinaus sind einige der URLs "http:" schwierig, da sie in von SharePoint generiertem JavaScript leben und ihre Schrägstriche (d. H. "/") Im HTML-Code durch die UNICODE-Zeichenfolge "\ u002f" dargestellt werden.

Im Falle dieser kniffligen Beispiele lautet die Literal-Zeichenfolge im ausgehenden HTML-Code:

http:\u002f\u002fservername.company.com\u002f

Und sollte geändert werden in:

https:\u002f\u002fservername.company.com\u002f

Derzeit können wir noch nicht einmal herausfinden, wie Sie eine Übereinstimmung in einem Such-/Ersetzungsausdruck für diese UNICODE-Sequenzzeichenfolgenliterale erhalten. Es scheint, dass der Tcl-Interpreter, egal wie wir ihn schneiden, die Zeichenfolge "\ u002f" in die Übersetzung "/" interpretiert, bevor er etwas anderes tut.

Wir haben verschiedene Kombinationen von Tcl-Escape-Methoden ausprobiert, die wir kennen (hauptsächlich doppelte Anführungszeichen und ein zusätzliches "\" verwenden, um das "\" in der UNICODE-Zeichenfolge zu umgehen), suchen jedoch nach mehr, vorzugsweise funktionierenden Methoden .

Hat jemand irgendwelche Ideen oder Hinweise darauf, wo wir uns effektiv selbst erziehen können?

Vielen Dank im Voraus.

antworten

@JD, ich hätte wahrscheinlich folgendes hinzufügen sollen:

Die betreffende SharePoint-Webanwendung wird derzeit auf einem physischen Server und einer SharePoint-Farm gehostet, die (in andere Webanwendungen) in SQL Server 2005 Reporting Services (SSRS) und PerformancePoint 2007 (PPS) integriert ist. Beide Produkte unterstützen keine alternativen Zugriffszuordnungen (AAM).

Auch wenn die Webanwendung, mit der wir die oben genannten Anwendungen ausführen möchten, nicht in SSRS oder PPS integriert ist, möchten unser Architekt und unsere technischen Mitarbeiter den Einsatz von AAM in dieser Umgebung möglichst vermeiden, wenn dies überhaupt möglich ist.

Ich stimme Ihrer Antwort zwar grundsätzlich zu, in diesem Fall bitte ich jedoch um eine besondere Ausnahme und frage nach der Flucht von Tcl und UNICODE, insbesondere weil ich und unsere anderen technischen Strategen glauben, dass dies die richtige Antwort ist besondere Situation.

Was Sie versuchen, wird mit SharePoint nicht empfohlen.

Die empfohlene Vorgehensweise ist die Verwendung alternativer Zugriffskarten in SharePoint. Sie erstellen eine öffentliche URL von https://und haben einen internen Namen von http://.

Dadurch werden alle URLs auf Ihrer Seite mit https://

erstellt

Möglicherweise möchten Sie dies auf ServerFault http://serverfault.com fragen, wenn Ihnen die Antwort nicht gefällt.

Ich weiß nichts über sharepoint, aber zumindest aus einer reinen Tcl-Perspektive zeigt das Folgende, wie Sie Ihren Literal-String anpassen:

tclsh> set string {http:\\u002f\\u002fservername.company.com\\u002f}
http:\\u002f\\u002fservername.company.com\\u002f
tclsh> regexp {http:\\\\u002f} $string
1

Wichtig ist, dass der Backslash in \\ u002f nicht vom Tcl-Parser interpretiert wird (indem das Muster in {} eingeschlossen wird) und dass auch der Backslash nicht vom Parser für reguläre Ausdrücke interpretiert wird (durch Flucht mit einem Backslash).

Für zukünftige Referenz, da dies in letzter Zeit ebenfalls aufkam ...

Sharepoint Alternate Access Mappings ist die sauberste Lösung.

Für eine BIG-IP iRule können Sie so etwas ausprobieren. Beachten Sie, dass TCL die Unicode-Zeichen interpretieren muss, bevor sie übereinstimmen können.

when HTTP_REQUEST {
    # Disable the stream filter by default
    STREAM::disable
}
when HTTP_RESPONSE {
    if {[HTTP::header value Content-Type] contains "text"}{
        set find_str "http:\\u002f\\u002fservername.company.com\\u002f"
        set replace_str "https:\\u002f\\u002fservername.company.com\\u002f"

        STREAM::expression "@$find_str@$replace_str@"
        STREAM::enable
    }
}

Aaron

Ersetzen Sie \\ 123 \\ abc durch \\ 456 \\ def

STREAM :: Ausdruck {@ \\\\ 123 @ \\ 456 @ @ \\\\ abc @ \\ def @}