Erlaubte Origins für das Widget verwalten

Was die Liste erlaubter Origins steuert

Erlaubte Origins legen fest, welche Websites das Reslify-Buchungs-Widget einbetten und mit dem Buchungsablauf kommunizieren dürfen. Das Widget-SDK verwendet die Einstellung zur Iframe-Hostvalidierung und für die postMessage-Kommunikation.

Sie können die Liste über Einstellungen / Portal / Portaleinstellungen / Allgemein / Laufzeit verwalten.

Bevor Sie die Liste ändern

Bestätigen Sie zunächst den Betriebszustand:

• Der Portalzugriffsmodus sollte Öffentlich sein, wenn Gäste das Widget von der Restaurant-Website verwenden müssen.
• Wenn der Zugriff Eingeschränkt ist, werden öffentliche Seiten und eingebettete Installationen für Besucher ohne Mitarbeiterstart als „Nicht gefunden“ angezeigt. Mitarbeiter können die Panel-Vorschau weiterhin für Kontrollen nutzen.
• Wenn der Zugriff Deaktiviert ist, werden Seiten-, Einbettungs- und Designerstarts blockiert, bis der Zugriff wieder aktiviert wird.
• Kennen Sie jede Website-Umgebung, in der das Widget ausgeführt werden muss, einschließlich Produktions-, www-, Staging- und CMS-Vorschau-Hosts.

Durch die Änderung zulässiger Ursprünge werden die Buchungsverfügbarkeit, bestehende Reservierungen oder der Zugriff auf das Personalpanel nicht geändert. Es betrifft die Website-Embed-Bridge. Vorhandene geladene Website-Seiten müssen nach dem Speichern aktualisiert werden.

Origin-Format

Ein Ursprung umfasst das Protokoll, den Hostnamen und den optionalen Port. Es enthält keinen Pfad.

Verwenden Sie Werte wie:

• https://restaurant.example
• https://www.restaurant.example
• https://staging.restaurant.example
• https://restaurant.example:8443

Behandeln Sie diese als separate Ursprünge, wenn sie separat verwendet werden:

• https://restaurant.example und https://www.restaurant.example
• http://restaurant.example und https://restaurant.example
• Produktions-, Staging- und Vorschaudomänen

Geben Sie keine Seitenpfade wie https://restaurant.example/reservations ein. Der Seitenpfad ist nicht Teil des Ursprungs und die Portallaufzeit liest nur den Ursprungsteil gültiger URLs.

Ursprünge hinzufügen oder aktualisieren

1. Öffnen Sie Einstellungen / Portal.
2. Öffnen Sie in den Portaleinstellungen die Registerkarte Allgemein.
3. Scrollen Sie zu Laufzeit.
4. Fügen Sie unter Erlaubte Origins einen Ursprung pro Zeile hinzu.
5. Schließen Sie jeden Host ein, auf dem das Widget ausgeführt werden soll.
6. Wählen Sie Portaleinstellungen speichern.
7. Aktualisieren Sie die Website-Seite und testen Sie das Widget in jeder Umgebung.

Gespeicherte Werte werden gekürzt und doppelte Zeilen werden reduziert. Sie müssen kein neues Modal-, Drawer- oder Inline-Skript kopieren, nur weil sich diese Zulassungsliste geändert hat. Das Widget ruft gespeicherte Portaleinstellungen ab, wenn die Seite geladen wird.

Wenn Erlaubte Origins leer ist, ist jeder Host zulässig und das SDK verwendet den aktuellen Website-Ursprung für postMessage. Bei einer Live-Website lassen sich explizite Ursprünge einfacher prüfen und Fehler beheben.

Gemeinsame Ursprungsliste

Die meisten Restaurants benötigen mindestens:

• die Domäne der Produktionswebsite
• die Version www, wenn sie separat verwendet wird
• die vom Website-Team verwendete Staging- oder Vorschau-Domain

Wenn das Restaurant später Website-Anbieter, Domain-Namen oder Vorschau-URLs ändert, aktualisieren Sie diese Liste, bevor Sie die neue Website testen. Behalten Sie den Produktionsursprung in der Liste beim Hinzufügen von Staging- oder Vorschauursprüngen bei, damit die Live-Website weiterhin funktioniert.

Auswirkungen auf Gäste und Mitarbeiter

Wenn der Website-Ursprung nicht zulässig ist, kann die eigenständige Buchungsseite weiterhin funktionieren, und die Personalvorschauen im Panel können weiterhin funktionieren, wenn der Portalzugriff dies zulässt. Die Einbettung der Restaurant-Website ist die betroffene Oberfläche.

Gäste sehen möglicherweise den Launcher oder den Iframe, aber das Einbettungsverhalten kann fehlschlagen, weil das SDK die erwartete Brücke mit der Hostseite nicht herstellen kann. Zu den Symptomen gehören fehlendes Größenänderungsverhalten, Schließaktionen, die nicht sauber zur Website zurückkehren, hostgesteuerte Meldungen, die nicht angewendet werden, oder eine Browserkonsolenwarnung wie Reslify embed: current origin is not allowlisted for postMessage.

Fehlerbehebung

Wenn das Widget angezeigt wird, aber nicht richtig geladen wird oder wenn in den Meldungen der Browserkonsole die Validierung von Ursprung, Host, Iframe, postMessage oder Reslify embed erwähnt wird:

1. Überprüfen Sie auf der Website-Seite den window.location.origin-Wert des Browsers.
2. Bestätigen Sie, dass der genaue Wert unter Erlaubte Origins aufgeführt ist, einschließlich Protokoll, www und Port, falls vorhanden.
3. Überprüfen Sie, ob die Site zwischen www und Nicht-www umleitet.
4. Schließen Sie den Staging- oder Vorschau-Host ein, wenn Sie außerhalb der Produktion testen.
5. Bestätigen Sie, dass der Portalzugriffsmodus für Gast-Website-Tests Öffentlich ist.
6. Wählen Sie erneut Portaleinstellungen speichern und aktualisieren Sie dann die Website-Seite.

Wenn Portal öffnen funktioniert und Einbettungsvorschau öffnen funktioniert, das Restaurant-Website-Widget jedoch immer noch nicht funktioniert, konzentrieren Sie sich auf die Website-Installation, zulässige Ursprünge, Skriptblocker oder die Platzierung des Website-Themas.