Sites und Aliase im Jitterbit App Builder

Übersicht

Bei einer Standardinstallation akzeptiert und beantwortet der App Builder HTTP-Anfragen unabhängig von der URL. Dies ist praktisch für den Einstieg, kann jedoch 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, z. B. /Vinyl. Der Client-Webbrowser behandelt Cookie-Pfade als case-sensitive; der Webserver möglicherweise nicht.
Ähnlich können externe Authentifizierungsanbieter den Pfad als case-sensitive behandeln, wenn sie Umleitungs-URLs wie https://example.com/Vinyl/signin-SAML validieren.
Darüber hinaus erlaubt der Client-Webbrowser dem Anwendungsserver nicht, ein unsicheres Cookie durch ein sicheres Cookie zu überschreiben.

Um diese und andere Probleme zu vermeiden, sollten Administratoren Schritte unternehmen, um die URL zu kanonisieren. Obwohl dies durch Rewrite-Regeln des Webservers erreicht werden kann, bietet der App Builder Unterstützung für die URL-Kanonisierung über die Funktion Sites und Aliase.

Sites

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

Es ist möglich, mehrere Sites und damit mehrere kanonische URLs zu definieren. Dies kann nützlich sein, zum Beispiel beim Einbetten einer App Builder-Anwendung. Siehe Einbetten unten.

Es kann nur eine Site als "Standard"-Site konfiguriert werden. Die Standard-Site wird verwendet, um die kanonische URL zu bestimmen. Siehe Übereinstimmung unten.

Aliase

Eine Site kann null oder mehr Aliase haben. Ein Alias ist eine alternative, nicht-kanonische URL, die verwendet werden kann, um auf die App Builder-Instanz zuzugreifen.

Zum Beispiel könnte die App Builder-Instanz zuvor unter der internen Adresse https://machinename/Vinyl veröffentlicht worden sein, bevor sie unter der externen Adresse https://example.com/Vinyl veröffentlicht wurde. Die interne Adresse kann als Alias für die externe Adresse konfiguriert werden. Wenn die Option Weiterleitung aktiviert ist, leitet der App Builder die Client-Browser automatisch von der internen Adresse zur externen Adresse um.

Konfiguration

Um Sites und Aliase zu verwalten, melden Sie sich zunächst als Administrator im App Builder an und gehen Sie dann wie folgt vor:

Wechseln Sie zur App Builder IDE-Anwendung.
Klicken Sie im Connect-Panel auf die Schaltfläche Security Providers.
Klicken Sie im Configuration-Panel auf die Schaltfläche Manage Sites.

Sites bestehen aus den folgenden Eigenschaften:

URL - Vollständig qualifizierte, kanonische URL. Beispiel: https://example.com/Vinyl.
Standard - Gibt an, ob die Site als Standard-Site behandelt wird, wenn eine HTTP-Anfrage mit einer Site übereinstimmt. Siehe Matching unten.
Weiterleitung - Gibt an, dass der App Builder die Client-Browser umleiten soll, wenn eine HTTP-Anfrage mit der Site (oder einem der Aliase der Site) übereinstimmt, aber nicht mit der kanonischen URL. Siehe Redirect unten.
Aliases - Liste von alternativen URLs, die mit der Site verbunden sind. Diese werden verwendet, um eine HTTP-Anfrage mit einer Site abzugleichen. Siehe Matching unten.

Um eine Site zur "Standard"-Site zu machen, klicken Sie auf die Schaltfläche Make Default. Beachten Sie, dass diese Schaltfläche nur sichtbar ist, wenn die Site noch nicht die Standard-Site ist.

Kanonisierung

Die Kanonisierung besteht aus zwei Schritten. Zuerst gleicht der App Builder die HTTP-Anfrage mit einer Site ab. Dann leitet der App Builder den Client-Webbrowser bei Bedarf zur kanonischen URL weiter.

Abgleich

Wenn der App Builder eine HTTP-Anfrage erhält, versucht er, die URL mit einer Site oder einem Alias abzugleichen. Der App Builder beginnt mit einem "lockeren" Abgleich. Ein lockerer Abgleich berücksichtigt die folgenden Kriterien:

Host - HTTP-Hostnamen. Beispiel: example.com
Port - HTTP-Portnummer. Beispiel: 80, 443
Pfad - URL-Pfadkomponente. Groß-/Kleinschreibung wird nicht berücksichtigt. Beispiel: /Vinyl.

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

Für die Zwecke eines lockeren Abgleichs werden die folgenden URLs als gleichwertig betrachtet:

http://example.com/vinyl - HTTP-Schema, Kleinbuchstaben-Pfad.
https://example.com/Vinyl - HTTPS-Schema, gemischter Fall im Pfad.

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

https://example.com/Vinyl
https://example.com/Vinyl/Vinyl2

Der App Builder wählt die beste Übereinstimmung mit folgender Priorität:

Wenn die URL mit einer Website übereinstimmt, wird die Website ausgewählt.
Wenn die URL mit einem Alias übereinstimmt, wird die Website des Alias ausgewählt.
Andernfalls wird die Standard-Website ausgewählt.

Redirect

Sobald die Website ausgewählt wurde, bestimmt der App Builder, ob die Anfrage fortgesetzt werden darf oder ob stattdessen eine Weiterleitung ausgegeben werden soll.

Wenn die Redirect-Option deaktiviert ist, darf die Anfrage fortgesetzt werden.
Wenn die Redirect-Option aktiviert ist und die Anfrage-URL nicht mit der Website-URL übereinstimmt, bricht der App Builder die Anfrage ab und antwortet mit einer HTTP-Weiterleitung.

In diesem Stadium führt der App Builder einen "strikten" Abgleich durch. Ein strikter Abgleich unterscheidet sich vom lockeren Abgleich darin, dass:

Der Pfad als groß- und kleinschreibungsempfindlich behandelt wird.
Das Schema berücksichtigt wird.

Für die Zwecke eines strikten Abgleichs werden die folgenden URLs nicht als gleichwertig betrachtet:

http://example.com/vinyl - HTTP-Schema, Kleinbuchstaben-Pfad.
https://example.com/Vinyl - HTTPS-Schema, gemischter Groß- und Kleinbuchstaben-Pfad.

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

Reverse proxies and load balancers

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

Use cases

Require HTTPS

Jede Instanz des App Builders MUSS mit HTTPS gesichert sein. Die sichere Verbindung kann am Webserver oder an einem Reverse Proxy beendet werden. Unabhängig davon werden Administratoren nach der Konfiguration dringend empfohlen, von allen Clients eine Verbindung über HTTPS zu verlangen.

Dies kann mit Websites und Aliasen erreicht werden. Setzen Sie die Website-URL so, dass sie mit der sicheren URL übereinstimmt, z. B. https://example.com/Vinyl, und aktivieren Sie die Redirect-Option.

Überprüfen Sie Informationen zu Reverse Proxies und Load Balancers bei der Verwendung von HTTPS

Framing

Der App Builder ist auf HTTP-Cookies angewiesen. Webbrowser blockieren typischerweise Cookies von Drittanbietern. Dies kann Probleme beim Rendern des App Builders in einem HTML-Frame verursachen.

Wenn die Framing-Website beispielsweise unter folgender URL veröffentlicht wird:

https://registration.example.com/

und der App Builder auf einer anderen Domain veröffentlicht wird:

https://vinyl.example.net/

wird der Webbrowser alle von App Builder gesetzten Cookies als Cookies von Drittanbietern behandeln und entsprechend blockieren. Um dieses Problem zu umgehen, veröffentlichen Sie den App Builder auf einer Subdomain der Domain der Framing-Website.

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

Erstellen Sie eine Website im App Builder mit dieser URL. Machen Sie sie nicht zur Standard-Website. Aktivieren Sie die Weiterleitungs-Option, um HTTPS zu verlangen.