externe Webpage in Projekt einbinden

christian-juhasz schrieb am 17.02.2018 um 15:57 Uhr

Servus,

ich habe derzeit einProblem mit dem Einbinden einer externen Page in ein WD Projekt.

Das Ziel ist es, dass Kunden, die auf einer Eingabeplattform ihre Auftragsnummer und die Postleitzahl eingeben, auf eine Seite weitergeleitet werden, auf der sie den Status ihrer Reparatur abfragen können. Hierfür habe ich eine kleine HTML Maske gebastelt, die auf eine Datenbank zugreift, in der die Auftragsnummern und Postleitzahlen dem jeweiligen Link zugeordnet sind.

Die Abfrage an sich funktioniert auch problemlos. http://www.rfmservices.de/suche Auftragsnummer zum testen ist RFM112, PLZ: 94315.

Jetzt habe ich mittels iFrame im Body eines Platzhalters die externe Seite im WD eingebunden. Der Platzhalter ist genau so gross, wie im iFrame vordefiniert.

Beim Aufrufen der Statusabfrage (oben in der Kopfzeile) wird zwar wie gewünscht die Eingabemaske aufgerufen, allerdings beim Abschicken der Daten nur auf eine weisse Seite weitergeleitet. www.schulungsaccouts.de

Woran kann das liegen?

Gruss, Chris

Kommentare

BeRo schrieb am 17.02.2018 um 18:48 Uhr

[...] beim Abschicken der Daten nur auf eine weisse Seite weitergeleitet. www.schulungsaccouts.de [...] Woran kann das liegen?

Ohne genauere Infos zur Testumgebung und zum Inhalt der "Suche.php" ist da kaum etwas zu sinnvolles zu sagen. 😞

Da die Suchfunktion in einer PHP Datei "verdrahtet" ist, könnte es sein, dass Du den Test lokal laufen lässt und wenn Du keinen "Apache" installierst hast, wird das nicht vernünftig funktionieren.

-------------------------------------------

Edit 23:02 h

Ich habe gerade mal den von Dir geposteten iframe in eine Seite eingebaut und das Problem zeigt sich schon in der Vorschau mit einem Lösungsvorschlag:

Hintergrund des "Fehlers" ist die Same-Origin-Policy (SOP), die in allen modernen Browsern implementiert ist und die dafür sorgt, dass Cross Domain Browsing unterbleibt.
Besucher Deiner Site müssen sicher sein, dass sie nicht unbemerkt- und ungewollt Seiten einer anderen Domain zu sehen bekommen...

Diese Sicherheitseinstellung lässt sich zwar mit CORS oder JASONP umgehen, dazu sind aber ein paar tiefergehende Eingriffe nötig.

Besser- und einfacher ist es, wenn Du dem Vorschlag der o. a. Fehlermeldung folgst und die RMA Abfrage in einem, neuen Fenster startest.
Dazu ist nur eine kurze Zeile Scriptcode nötig, der in Deinem Fall so aussieht:

<script>
window.location = "http://rfmservices.de/suche/index.html";
</script>

Den Scriptcode baust Du in den HTML Body eines Platzhalters ein, den Du auf einer ansonsten völlig leeren Seite anlegst. Die Größe spielt keine Rolle, da die aufgerufene Seite responsive Eigenschaften hat.

So kann das aussehen:

In der NavBar Deiner "normalen" Site legst Du einen passend beschrifteten Link zu der neuen Seite an...

...der nach einem Klick die RFM Suche öffnet

Der Besucher Deiner Site kann zwar in der Adresszeile des Browsers sehen, dass er auf einer anderen Domain gelandet ist, Nachteile für das Surfen auf Deiner Site hat er durch das Cross Browsing aber nicht.

christian-juhasz schrieb am 18.02.2018 um 13:08 Uhr

Vielen lieben Dank, BeRo,

sowas habe ich mir schon gedacht.

Ich werde jetzt einen ähnlichen Ansatz wählen, den ich vorher schon hatte, den wir allerdings nicht unbedingt haben wollten. Wir haben nach einer Alternative gesucht um die Seite nicht zu verlassen.

Es wird jetzt einfach oben in der Kopfzeile der Link STATUSABFRAGE auf die seite rfmservices.de/suche in einem neuen Tab geöffnet werden. So funktioniert es ja. Wir wollten es zwar intigrieren, aber nun ist es halt so.

Auf zur nächsten Herausforderung .... ;)

Gruss, Chris

marboe schrieb am 24.02.2018 um 08:32 Uhr

Hallo BeRo,

da Christian mit dieser Frage wohl "fertig" ist, möchte ich gerne meine Fragen dazu anschliessen.
Denn in der Tat habe ich einige Seiten, bei denen dieses Problem auftaucht. Dabei handelt es sich um Shopseiten, die in einem Unterordner der Domain gehostet werden und um Newsletter-Skriptdateien, die auf http laufen. Bisher war ich immer davon ausgegangen, dass der Aufruf von http von einer https-Seite das Problem hervorruft.
Deine Antwort gibt mir Hoffnung, dass ich da vielleicht falsch lag.

Warum kann man nicht ein per Platzhalterskript eingebundenes Iframe einfach im WD als _blank oder _parent öffnen lassen? Weißt du hier eine Antwort? Dass es nicht geht, weiß ich bereits durch ausprobieren. Aber warum? Das wäre das Optimum, da ja das Drumherum erhalten bliebe.
Interessant, dass man bei deinem Lösungsvorschlag eine neue Seite im Projekt anlegen muss dafür, obwohl es doch nur den Aufruf einer Seite betrifft.

Ich wüsste gern mehr darüber. Zum Beispiel bin ich bisher nicht fündig geworden, ob es auch Einstellungen auf dem Server gibt oder die Möglichkeiten per htaccess etwas daran zu ändern, dass der Aufruf diverser Inhalte blockiert wird.
Leider ist es nämlich mit meinen Newsletterskript nicht möglich "umzuziehen". Dann würden alle alten php-Einträge verloren gehen. Logisch, weil die Verweise dann alle nicht mehr stimmen.

Erwartungsvoll wie immer - Marboe 😁

Funktioniert, gleiche Domain, auch https bleibt gleich: (leider passwortgeschützt)

<iframe src="https:entfernt" width="100%" height="100%" frameborder="0" scrolling="auto" name="xara_iframe" ><p>Your browser does not support iframes.</p></iframe>
Allerdings nicht beim öffentlichen NL, hier mal die URL des _blank-Aufrufs: https://entfernt/na.php
Beim internen NL wechselt man aktuell also nicht von https nach http. Dann geht es.

Funktioniert leider nicht:

<iframe src="https://entfernt/" width="100%" height="100%" frameborder="0" scrolling="auto" name="xara_iframe" ><p>Your browser does not support iframes.</p></iframe>

Hier noch ein Bild dazu:
URL macht keinen Sinn, aber bitte - nicht verlinkt da nicht funktionsfähig: https://entfernt.htm
Schon die Vorschau meckert natürlich..

BeRo schrieb am 24.02.2018 um 20:06 Uhr

@marboe

[...] Warum kann man nicht ein per Platzhalterskript eingebundenes Iframe einfach im WD als _blank oder _parent öffnen lassen? [...]

Wie genau die Unterdrückung des Cross Domain Browsing in den einzelnen Browsern implementiert wurde, kann ich Dir leider nicht sagen.
Dass es Lösungsansätze zu dem Problem gibt, hatte ich weiter oben ja schon angedeutet (s. CORS, JASONP)

[...] Interessant, dass man bei deinem Lösungsvorschlag eine neue Seite im Projekt anlegen muss [...]

Das Ergebnis ist eigentlich eher dem Zufall geschuldet, weniger einer sachlichen Überlegung. 😌
Ich hatte den iframe Code zum Test auf eine leere Seite verschoben und den dann später durch das JScript ersetzt.
Vermutlich klappt die Lösung auch, mit einem ganz normalen Platzhalter auf einer popup Ebene... 😀

Ich habe mich mit dem Problem "Cross Domain Browsing" bisher auch nur "nebenbei" beschäftigt. So richtig tief stecke ich da auch noch nicht drin. Aber, hier gibt es eine recht ausführliche Erklärung zum Thema "CORS". Eine weiterführende Site, mit Beispielen, findest Du hier.

[...] Ich wüsste gern mehr darüber. [...] ob es auch Einstellungen auf dem Server gibt oder die Möglichkeiten per htaccess etwas daran zu ändern, [...]

Ja, die Möglichkeit gibt es und das ist sogar recht einfach umzusetzen (klick).
Auch auf der weiter oben verlinkten Site findest Du schon Infos zur ".htaccess" Lösung...

Probier's einfach aus. Kaputtmachen kannst Du jedenfalls nichts mit der Technik 😋

Viel Erfolg

marboe schrieb am 26.02.2018 um 09:27 Uhr

Vielen herzlichen Dank für den Input!

Probier's einfach aus. Kaputtmachen kannst Du jedenfalls nichts mit der Technik 😋

Da allerdings bin ich mir absolut nicht sicher 🤓
Deine hilfreichen Links haben mich zum schon bekannte Problem zurückgeführt:
Schon damals, beim ersten Auftauchen des Problems, war ich der Meinung daraus zu lesen, dass der Shop das Einbinden als iframe untersagt.
Durch deine Links habe ich eine Möglichkeit gefunden eine Browsererweiterung zu installieren, die die Response-Header-Angaben ignorieren kann. Und siehe da ...

Mein Problem ist also - zumindest in Bezug auf den Shop - nicht per Webdesigner oder .htaccess Angaben auf der dortigen Domain zu lösen, sondern nur auf der Domain des Shops.
Da ich diesen beim gleichen Anbieter (1&1) hoste, wie auch die Websites, schliesse ich, dass ich evtl in der dortigen htaccess was "ändern" kann.
Diese Shop-htaccess-Datei ist aber extrem umfangreich und ich finde dort nicht den richtigen Eintrag. Ich habe lauter Internel Server Errors produziert 😰.

(kleiner Ausschnitt)

Ich denke mein nächster Schritt wäre das Hinwenden an die Cracks der Shopsoftware bei Modified Shopsoftware. Vielleicht können die helfen.
Mir wird das an diesem Punkt zu heikel. Im Shop sind ja sehr viele Kundendaten und sonstiger Krempel. Ich bin froh, dass die Datenbank läuft (das ist bei den vielen Updates, die da notwendig sind nicht sooo selbstverständlich).

Was den Einbau des Newsletterarchivs angeht, auch php , werde ich demnächst einen neuen Anlauf nehmen.
Vielen Dank auf jeden Fall bis hierhin.
Herzliche Grüße, marboe

BeRo schrieb am 26.02.2018 um 11:28 Uhr

@marboe

[...] mein nächster Schritt wäre das Hinwenden an die Cracks der Shopsoftware [...]

Bei der Komplexität der .htaccess Datei scheint mir das sinnvoll zu sein. Wer sonst soll die tief verschachtelten Kommandos in der ganzen Tragweite mit einem Blick analysieren und Verbesserungsvorschläge machen. 😍

Ich drück' Dir gerne alle Daumen, damit Du auf dem Weg eine funktionsfähige Lösung bekommst...