Sites und Aliase im Jitterbit App Builder

Übersicht

Bei einer Standardinstallation App Builder akzeptiert und beantwortet HTTP-Anfragen unabhängig von der URL. Das ist am Anfang praktisch, kann aber später zu Problemen führen. Probleme entstehen durch die unterschiedliche Behandlung von URLs.

HTTP-Cookies können auf einen bestimmten Pfad beschränkt werden, zB /App Builder. Der Webbrowser des Clients berücksichtigt bei Cookie-Pfaden die Groß- und Kleinschreibung. Beim Webserver ist dies möglicherweise nicht der Fall.
Ebenso können externe Authentifizierungsanbieter bei der Validierung von Umleitungs-URLs zwischen Groß- und Kleinschreibung unterscheiden, wie z. B. https://example.com/App Builder/signin-SAML.
Darüber hinaus lässt der Client-Webbrowser nicht zu, dass der Anwendungsserver ein unsicheres Cookie durch ein sicheres Cookie überschreibt.

Um diese und andere Probleme zu vermeiden, sollten Administratoren Schritte unternehmen, um die URL zu kanonisieren. Dies kann zwar durch Umschreiberegeln für Webserver erreicht werden, App Builder bietet Unterstützung für die URL Kanonisierung über die Funktion „Sites und Aliase“.

Seiten

Eine Site definiert eine kanonische URL. Eine Standardinstallation umfasst eine einzelne Site. Die Site hat keine bestimmte URL. Stattdessen wird die URL aus der HTTP-Anforderung abgeleitet.

Es ist möglich, mehrere Sites und damit mehrere kanonische URLs zu definieren. Dies kann beispielsweise beim Framing nützlich sein an App Builder Anwendung. Siehe Framing unten.

Es kann nur eine Site als „Standard“-Site konfiguriert werden. Die Standard-Site wird zur Ermittlung der kanonischen URL verwendet. Siehe Matching weiter unten.

Aliase

Eine Site kann null oder mehr Aliase haben. Ein Alias ist eine alternative, nicht-kanonische URL, die für den Zugriff auf die App Builder Instanz.

Zum Beispiel die App Builder Instanz wurde möglicherweise auf der internen Adresse veröffentlicht https://machinename/App Builder bevor es auf der externen Adresse veröffentlicht wurde https://example.com/App Builder. Die interne Adresse kann als Alias für die externe Adresse konfiguriert werden. Wenn die Option Umleitung aktiviert ist, App Builder leitet Client-Browser automatisch von der internen Adresse zur externen Adresse um.

Konfiguration

Um Sites und Aliase zu verwalten, melden Sie sich zunächst an bei App Builder als Administrator, dann:

Wechseln Sie zu App Builder IDE-Anwendung.
Klicken Sie im Bereich Verbinden auf die Schaltfläche Mit Ihrem Unternehmen verbinden.
Klicken Sie im Menü links auf die Schaltfläche Sicherheitsanbieter.
Klicken Sie im Bereich Konfiguration auf die Schaltfläche Sites verwalten.

Standorte bestehen aus den folgenden Eigenschaften:

URL - Vollständig qualifizierte, kanonische URL. Beispiel: https://example.com/App Builder.
Standard - Gibt an, ob die Site als Standardsite behandelt wird, wenn eine HTTP-Anforderung einer Site zugeordnet wird. Siehe Zuordnung unten.
Umleitung - Gibt an, dass App Builder sollte Client-Browser umleiten, wenn eine HTTP-Anforderung mit der Site (oder einem der Aliase der Site) übereinstimmt, aber nicht mit der kanonischen URL. Siehe Umleitung unten.
Aliase - Liste alternativer URLs, die mit der Site verknüpft sind. Diese werden verwendet, um eine HTTP-Anfrage einer Site zuzuordnen. Siehe Abgleich unten.

Um eine Site zur „Standardsite“ zu machen, klicken Sie auf die Schaltfläche Als Standard festlegen. Beachten Sie, dass diese Schaltfläche nur sichtbar ist, wenn die Site nicht bereits die Standardsite ist.

Kanonisierung

Die Kanonisierung besteht aus zwei Schritten. Erstens: App Builder ordnet die HTTP-Anfrage einer Site zu. Dann App Builder leitet den Client-Webbrowser bei Bedarf zur kanonischen URL weiter.

Dazu passend

Wann App Builder eine HTTP-Anforderung empfängt, versucht es, die URL einer Site oder einem Alias zuzuordnen. App Builder beginnt mit der Durchführung eines „losen“ Matches. Ein loses Match berücksichtigt die folgenden Kriterien:

Host - HTTP- Host. Beispiel: example.com
Port - HTTP Port. Beispiel: 80, 443
Pfad - URL Pfadkomponente. Groß-/Kleinschreibung wird nicht beachtet. Beispiel: /App Builder.

Beachten Sie, dass App Builder berücksichtigt das Schema in diesem Stadium nicht.

Für die Zwecke einer groben Übereinstimmung werden die folgenden URLs als gleichwertig betrachtet:

http://example.com/vinyl- HTTP-Schema, Pfad in Kleinbuchstaben.
https://example.com/App Builder- HTTPS-Schema, Pfad mit gemischter Groß- und Kleinschreibung.

Beachten Sie, dass dieser Algorithmus nicht zulässt, dass App Builder Site, die innerhalb einer anderen existiert. Folgendes wird nicht unterstützt:

https://example.com/App Builder- https://example.com/App Builder/App Builder 2

App Builder wählt die beste Übereinstimmung mit der folgenden Priorität:

Wenn die URL mit einer Site übereinstimmt, wird die Site ausgewählt.
Wenn die URL mit einem Alias übereinstimmt, wird die Site des Alias ausgewählt.
Andernfalls wird die Standardsite ausgewählt.

Umleitung

Sobald der Standort ausgewählt wurde, App Builder legt fest, ob die Anforderung fortgesetzt werden darf oder ob stattdessen eine Umleitung erfolgen soll.

Wenn die Option Umleitung deaktiviert ist, kann die Anfrage fortgesetzt werden.
Wenn die Option Umleitung aktiviert ist und die Anforderungs URL nicht mit der Site URL übereinstimmt, App Builder bricht die Anfrage ab und antwortet mit einer HTTP-Umleitung.

In diesem Stadium App Builder führt eine „strenge“ Übereinstimmung durch. Eine strenge Übereinstimmung unterscheidet sich von der losen Übereinstimmung darin:

Bei der Pfadangabe wird zwischen Groß- und Kleinschreibung unterschieden.
Das Schema wird berücksichtigt.

Für die Zwecke einer strikten Übereinstimmung werden die folgenden URLs nicht als gleichwertig betrachtet:

http://example.com/vinyl- HTTP-Schema, Pfad in Kleinbuchstaben.
https://example.com/App Builder - HTTPS-Schema, Pfad in Groß- und Kleinschreibung.

Wenn die HTTP-Anforderungs URL nicht mit der Site URL übereinstimmt, App Builder antwortet mit einer Weiterleitung.

Reverse-Proxys und Load Balancer

App Builder unterstützt Reverse-Proxys und Load Balancer, die die SSL-Verbindung vor dem Webserver beenden. Diese Umgebungen erfordern zusätzliche Konfiguration. Siehe Reverse-Proxys für weitere Informationen.

Anwendungsfälle

HTTPS erforderlich

Jede Instanz von App Builder MUSS mit HTTPS gesichert werden. Die sichere Verbindung kann am Webserver oder einem Reverseproxy beendet werden. Unabhängig davon wird Administratoren nach der Konfiguration dringend empfohlen, alle Clients zur Verbindung mit HTTPS aufzufordern.

Dies kann mit Sites und Aliasen erreicht werden. Stellen Sie die Site URL so ein, dass sie mit der sicheren URL übereinstimmt, z. B. https://example.com/App Builder, und aktivieren Sie die Option Umleitung.

Lesen Sie die Informationen zu Reverse-Proxys und Load Balancern bei Verwendung von HTTPS

Rahmung

App Builder basiert auf HTTP-Cookies. Webbrowser blockieren normalerweise Cookies von Drittpartei. Dies kann zu Problemen beim Rendern führen App Builder in einem HTML-Frame.

Wenn die Framing-Site beispielsweise unter der folgenden URL veröffentlicht wird:

https://registration.example.com/

Und App Builder wird auf einer anderen Domain veröffentlicht:

https://vinyl.example.net/

Der Webbrowser behandelt alle von ihm gesetzten Cookies App Builder als Cookies von Drittpartei und blockieren Sie sie entsprechend. Um dieses Problem zu umgehen, veröffentlichen App Builder auf einer Subdomäne der Domäne der Framing-Site.

https://vinyl.registration.example.com/

Erstellen Sie eine Site in App Builder mit dieser URL. Machen Sie sie nicht zur Standard-Site. Aktivieren Sie die Option Umleitung, um HTTPS anzufordern.