Navigation/Header von anderer Sub-Domain laden?

[Simon]

Hallo zusammen,

ich habe eine Website unter www.example.org und eine unter der Subdomain test.example.org. Ich möchte aber die Navigation inkl. Style von www.example.org auf test.example.org einbinden/spiegeln, ohne sie 1:1 nachbauen zu müssen.

• Integration via iFrame - eher nicht
• Nachladen via JavaScript: Vermutlich am ehesten, aber problematisch dürfte sein, dass auch der Style geladen werden muss (geht das überhaupt?)

Gibt es vielleicht noch eine andere Lösung, die ich nicht sehe?

Die nötigen CORS-Header werden natürlich gesetzt, das sollte kein Problem sein.

Für Anregungen wäre ich dankbar...

Viele Grüße, Simon

[Rolf B]

Hallo Simon,

Stylesheets sollten kein Problem sein, Scripte laden kann man auch, nur Fetch-Operationen (XMLHttpRequest / Fetch-API) sind ohne CORS Header schwierig. Mit Header geht auch das.

Generell gilt, dass JavaScript-Code nur auf den Origin (Protokoll+Host+Port) Fetch-Zugriffe machen darf, von dem er geladen wurde. Zugriffe auf Fremd-Origins werden - meine ich - zwar ausgeführt, die Antwort ist aber "opak", d.h. du bekommst die Daten nicht.

Wenn Du generell einen Redirect von http auf https drin hat, kannst Du einfach URLs wie https://test.example.org/css/mystyles.css verwenden. Der Redirect empfiehlt sich ohnehin. Ohne diesen könntest Du einfach in den Ressourcen-URLs das Protokoll weglassen, dann übernimmt der Browser das Protokoll, mit dem die Hauptseite geladen wurde.

Wenn beide Domains auf dem gleichen Server liegen und Du hinreichende Rechte hast, kannst Du das Cross-Origin Problem aber auch serverseitig angehen. Wenn test.example.org in /var/www/example/test liegt und www.example.org in /var/www/example/www, dann könnstest Du mit dem ln Befehl im www Ordner einen Symlink shared erzeugen, der auf ../test/shared verweist (oder andersrum, oder du erzeugst in beiden einen Symlink auf einen gemeinsamen dritten Ordner). Auf diese Weise können beide Webs den gleichen Ordner nutzen, und dort legst Du HTML, CSS und JS hinein, das beide Domains verwenden sollen.

Wenn Du PHP auf deinem Server nutzen kannst, könntest Du auch PHP als Include-Engine nutzen, wie wir es in unserem Wiki unter PHP Templates beschreiben. Dafür muss man nicht mit PHP programmieren können. Symlinks brauchst Du dann nicht unbedingt.

Eine Alternative sind Server-Side Includes (SSI), die unterstützt aber nicht jeder Hoster. Nachladen vom Client per AJAX-Technik ist aus meiner Sicht die schlechteste Alternative und nur dann die erste Wahl, wenn man die ganze Seite ohnehin per JavaScript aufbaut (z.B. mit Angular oder React).

Rolf

[PHP-Freund]

Moin,

Kann man das nicht auf dem Server mit PHP oder SSI regeln?

Wieso muss da erst der Client involviert werden und damit der Traffic und die Anzahl der Requests in die Höhe getrieben werden?

Ciao
PHP-Freund

[Auge]

Hallo

Kann man das nicht auf dem Server mit PHP oder SSI regeln?

Natürlich kann man das.

Was die Styles betrifft, binde sie einfach ein.

<link rel="stylesheet" href="anderesubdomain.example.com/data/style.css" media="all">

Wenn du HTML-Fragmente über (Sub)-Domaingrenzen hinweg benutzen willst, kommt es ein wenig darauf an, ob die Domains auf einem gemeinsamen Webspace/Server betrieben werden oder nicht und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.

Wenn alles auf einem Webspace/Server betrieben wird, kannst du üblicherweise mit lokalen Pfadangaben arbeiten, um (zum Beispiel mit PHP) ein HTML-Template für die Navigation sowohl auf Subdomain A als auch auf Subdomain B einzubinden. Dazu braucht man also keineswegs JavaScript uund somit muss man dazu auch nicht den Browser des Besuchers bemühen.

Ich frag mich nur, warum man auf verschiedenen Subdomains mit der selben Navigation arbeiten kann. Sind die Inhalte so gleichartig, dass die Navigation überall passt oder ist das nur ein Teil der Navigation, der auf allen Subdomains, quasi als Teil der Corporate Identity, eingebunden wird?

Tschö, Auge

[Der Martin]

n'Abend,

ich muss da dringend mal mischen - und zwar mich ein.

Was die Styles betrifft, binde sie einfach ein.

<link rel="stylesheet" href="anderesubdomain.example.com/data/style.css" media="all">

Ja, aber nicht so. Bitte nicht den führenden doppelten Slash vergessen:

<link rel="stylesheet" href="//anderesubdomain.example.com/data/style.css" media="all">

Denn sonst wird vom aktuellen Pfad aus relativ adressiert, und das führt wieder zu neuen überraschenden Problemen. Aber nicht über Domaingrenzen hinweg.

Einen schönen Tag noch
 Martin

[PHP-Freund]

Hallo

Wenn du HTML-Fragmente über (Sub)-Domaingrenzen hinweg benutzen willst, kommt es ein wenig darauf an, ob die Domains auf einem gemeinsamen Webspace/Server betrieben werden oder nicht und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.

Das trifft aber nur dann zu, wenn man direkt über ein CommonFileSystem zugreifen will.

Man kann auch auf einer Domain ein Interface zur Verfügung stellen, über das man dann vom anderen Server aus z. B. per HTTPS zugreift. Mit einem HTTPS-POST von einem Server zum anderen geht das auch abgesichert. Die Antwort kann man dann in das Dokument einbauen. Da sind der Phantasie keine Grenzen gesetzt.

Ich will damit nur sagen, dass es auf den Servern (wenn es denn unterschiedliche sind) saubere Möglichkeiten zur Syndification gibt. Davon müssen die Clients dann gar nichts mitbekommen.

Buona Sera
PHP-Freund

[Auge]

Hallo

Wenn du HTML-Fragmente über (Sub)-Domaingrenzen hinweg benutzen willst, kommt es ein wenig darauf an, ob die Domains auf einem gemeinsamen Webspace/Server betrieben werden oder nicht und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.

Das trifft aber nur dann zu, wenn man direkt über ein CommonFileSystem zugreifen will.

Man kann auch auf einer Domain ein Interface zur Verfügung stellen, über das man dann vom anderen Server aus z. B. per HTTPS zugreift.

Ich schrieb ja weder umsonst noch aus Jux und Dallerei „… und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.“ Man kann nämlich an Hoster geraten, die alle Kommunikation von serverseitigen Skripten nach außen abseits von HTTP unterbinden … und natürlich auf andere, die diese Möglichkeit auf verschiedensten Wegen anbieten. Und die sollte man kennen, bevor man entscheidet, wie man vorgeht.

Tschö, Auge

[PHP-Freund]

Hallo,

Das trifft aber nur dann zu, wenn man direkt über ein CommonFileSystem zugreifen will.

Man kann auch auf einer Domain ein Interface zur Verfügung stellen, über das man dann vom anderen Server aus z. B. per HTTPS zugreift.

Ich schrieb ja weder umsonst noch aus Jux und Dallerei „… und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.“ Man kann nämlich an Hoster geraten, die alle Kommunikation von serverseitigen Skripten nach außen abseits von HTTP unterbinden …

Genau! Diese bösen Hoster. Darum hatte ich HTTP/s als Protokoll vorgeschlagen

Es lässt es sich aber tatsächlich (ohne Firewallregeln) mit PHP-Einstellungen verhindern, dass ein Skript per HTTP-POST auf einen anderen Server zugreift:

• allow_url_fopen = FALSE -> Keine Protokoll-Wrapper erlaubt
• disable_functions('fsockopen') -> keine Low-Level-Zugriffe auf Ports
• Was ist mit den CURL-Funktionen?
• [...]
• Was leistet der 'safe_mode' hier?

Gibt es (bei PHP) noch weitere Möglichkeiten, die Zugriffe auf andere Server zu unterbinden?

Könnten wir das bitte weiter konkretisieren?
Das ergibt dann eine gute Information für die Tipps-Sammlungen. ;-)

Freu mich auf Vervollständigung
PHP-Freund

[Auge]

Hallo

Das trifft aber nur dann zu, wenn man direkt über ein CommonFileSystem zugreifen will.

Man kann auch auf einer Domain ein Interface zur Verfügung stellen, über das man dann vom anderen Server aus z. B. per HTTPS zugreift.

Ich schrieb ja weder umsonst noch aus Jux und Dallerei „… und wenn nicht, ob und wie dir die Konfiguration der verfügbaren Sprache (PHP, Python, was auch immer) den Zugriff über Server hinweg ermöglicht.“ Man kann nämlich an Hoster geraten, die alle Kommunikation von serverseitigen Skripten nach außen abseits von HTTP unterbinden …

Genau! Diese bösen Hoster. Darum hatte ich HTTP/s als Protokoll vorgeschlagen

Da hatte ich mich auch ungenau ausgedrückt, weil …

Es lässt es sich aber tatsächlich (ohne Firewallregeln) mit PHP-Einstellungen verhindern, dass ein Skript per HTTP-POST auf einen anderen Server zugreift:

… bei dem nämlichen Hoster selbst das deaktiviert war.

• allow_url_fopen = FALSE -> Keine Protokoll-Wrapper erlaubt
• disable_functions('fsockopen') -> keine Low-Level-Zugriffe auf Ports

… wie gesagt …

• Was ist mit den CURL-Funktionen?

… cURL war installiert, aber für Verbindungen nach außen ebenfalls deaktiviert.

Gibt es (bei PHP) noch weitere Möglichkeiten, die Zugriffe auf andere Server zu unterbinden?

Ich kenne aus der Lameng keine, aber bin mir sicher, dass es sie gibt.

Tschö, Auge

[Raketenwilli]

Gibt es (bei PHP) noch weitere Möglichkeiten, die Zugriffe auf andere Server zu unterbinden?

Indirekt. Ein findiger Benutzer könnte nämlich womöglich verfügbare Systembefehle wie wget oder curl, ssh, sshfs, ftp,scp, netcat, ... nutzen.

Also müssen, um Erfolg zu haben:

• exec
• passthru
• proc_​open
• shell_​exec
• system

mit abgeschaltet werden.

https://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpini-disable-functions/

Ich würde kündigen. Warum soll ich darunter leiden, dass andere Mist bauen oder etwas wie Wordpress installieren (und keine Updates machen)?

[Raketenwilli]

Ich möchte aber die Navigation inkl. Style von www.example.org auf test.example.org einbinden/

Hm. Beide auf dem selben Server? Wird oder kann eine serverseitige Technologie verwendet werden (PHP, SSI, CGI)? Spielt ein CMS eine Rolle? In welcher Form liegt die Navigation vor?