Gehe zu deutscher Webseite

ViaThinkSoft CodeLib

This article is in:
CodeLibTroubleshooting

Wir bei ViaThinkSoft wussten fast schon nicht weiter und mir ging erst vor wenigen Minuten ein Licht auf, warum auf unserem Webserver auf einmal mehrere Probleme zeitgleich auftraten.

Dieser Post erläutert, warum manche User vor scheinbar unlösbaren Problemen stehen, wenn es darum geht, dass eingegebene Formulareingaben plötzlich verschwinden.
Diese Beschreibung wirkt auf den ersten Blick etwas abstrakt, doch ich möchte zunächst folgende Praxisbeispiele nennen, die das beschriebene Problem verdeutlichen sollen. Außerdem möchte ich, dass dieser Beitrag von möglichst vielen Menschen gefunden wird, deren Probleme auf diese Thematik zurückzuführen sind:

- Beispiel phpMyAdmin: Beim Erstellen / Editieren von Datenbank-Einträgen erscheint die Fehlermeldung "Warning: Invalid argument supplied for foreach() in /.../phpmyadmin/tbl_replace.php on line ###"
- Beispiel phpBB: Nach erstem erfolgreichen Login ist man wieder ausgeloggt - man muss sich danach erneut einloggen und kann erst dann Beiträge schreiben
- Allgemeines Beispiel: Ich möchte im Internet ein Formular abschicken, doch die Daten kommen nie an!

Dem Hintergrund auf der Spur

Um zu dem Hintergrund des Problems zu gelangen, muss man zunächst die Gemeinsamkeiten der Beispiele erkennen:
Beim Editieren der Datenbank / Einloggen ins Forum - allgemein beim Senden von Formulardaten über das Internet - existieren zwei Möglichkeiten dies zu tun: per GET und per POST (Erläuterungen dazu unter http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Argument.C3.BCbertragung). Häufig wird POST verwendet, damit die eingegebenen Formulardaten nicht in der Adresszeile des Browsers auftauchen und somit eine gewisse Übersicht und Datenschutz gewährleistet ist (die eingegebenen Daten verbleiben nicht in der Verlaufshistorie des Browsers).

Um eine zusätzliche Sicherheit sicherzustellen, prüfen manche Programme wie z.B. phpMyAdmin, ob ein abgeschicktes POST-Formular vom gleichen Server aus abgeschickt wird. Ist dies nicht der Fall, werden die übermittelten Daten nicht verarbeitet.
Forensoftware wie z.B. phpBB ist es meistens egal, woher die Anfrage kommt. Forensoftware speichert die erhaltenen Login-Daten jedoch in Cookies. Cookies sind serverabhängig, das heißt ein fremder Server kann nicht die Cookies eines anderen Servers auslesen.

Die Probleme bestehen aber bei einem ordnungsgemäßen Aufruf der Skripte! Was ist das Problem?

Von außen ordnungsgemäß, genauer betrachtet jedoch nicht - hier muss etwas ausgeholt werden, um das Problem zu verstehen:
Das Problem liegt an der sogenannten "HTTP-Weiterleitung", die alle Domainprovider standardmäßig anbieten. Um die Sache zu vereinfachen, definiere ich hier folgende Ausgangssituation:

Ich habe mir die Domain www.meine-domain.de bei dem Domainprovider Super-Domain eingerichtet, mein Webserver hat die IP (Internet-Adresse) 1.2.3.4, die IP meines Domain-Providers Super-Domain ist 5.6.7.8. Ich logge mich bei Super-Domain ein und richte meine Domain ein:
http://www.meine-domain.de soll auf http://1.2.3.4 weiterleiten - soweit in Ordnung.

Gebe ich nun in meinen Browser www.meine-domain.de ein, wird zunächst eine Anfrage an meinen Domain-Provider gesendet. Ich lande erst auf 5.6.7.8, der dann eine Umleitung auf http://1.2.3.4 macht. Dies erfolgt versteckt, so dass im Browser immer noch www.meine-domain.de angezeigt wird.

Nicht ganz einfach die Geschichte, ich weiß.

phpMyAdmin, phpBB, etc., die auf meinem Server (IP 1.2.3.4) bekommen gar nicht mit, dass der Surfer http://www.meine-domain.de eingetippt hat. Denn diese Information ist in dem Moment verloren gegangen, als mein Domainprovider eine Umleitung auf 1.2.3.4 gemacht hat. Doch der Browser denkt weiterhin, dass er auf www.meine-domain.de ist.

Was passiert nun beim Abschicken eines POST-Formulars?

Der Browser schickt die Formulardaten ab - er gibt als Quelle, wo die Daten eingegeben worden sind, die Quelle www.meine-domain.de an.
Jetzt sind zwei Fälle zu unterscheiden:
- phpMyAdmin beispielsweise ist so konfiguriert, dass Formulardaten stets an die ihm erkannte Server-Adresse schicken - die Adresse, wo phpMyAdmin glaubt aktiv zu sein - also 1.2.3.4 (phpMyAdmin weiß ja nichts von www.meine-domain.de!). Somit werden die Daten vom Browser von www.meine-domain.de an 1.2.3.4 geschickt. phpMyAdmin erkennt den Unterschied der Hostnamen und verweigert, die POST-Daten auszuwerten.
- phpBB dagegen ist es zunächst ziemlich egal, auf welchem Server es liegt. Es transferiert also nicht wie phpMyAdmin an http://1.2.3.4/post_auswerten.php sondern einfach an /post_auswerten.php - der Browser leistet den Rest, er denkt, wir sind immer noch auf www.meine-domain.de und vervollständigt so das Ziel der POST-Anfrage zu http://www.meine-domain.de/post_auswerten.php. phpBB wertet die Daten auch ordnungsgemäß aus, speichert sie in einem Cookie auf dem PC des Surfers und zeigt an: "Sie sind eingeloggt!" - doch was nun: Klickt man nun auf irgendeinen Link, um durch das Forum zu navigieren, bedient sich phpBB nun plötzlich doch der selbst-erkannten Server-Adresse - also nicht mehr www.meine-domain.de, denn die kennt ja nur der Browser sondern 1.2.3.4. Wenn man nun auf irgendeinen Link klickt, landet man auf 1.2.3.4 - und von dort aus hat man keinen Zugriff mehr auf das gespeicherte Cookie, das unter der Adresse www.meine-domain.de auf dem PC des Surfers gespeichert ist.

Beides mal fand ein unerwarteter Adresswechsel statt, da die Server-Skripte nichts von der Umleitung mitbekommen haben. Dadurch wurden entweder plötzlich die POST-Daten ungültig oder das Cookie konnte nicht gelesen werden, da es ja von einem anderen Server stammte.

Zusammenfassung

Sendet man Anfragen an www.meine-domain.de landet man in Wirklichkeit auf 5.6.7.8, dem Server vom Domainprovider, der dann eine HTTP-Weiterleitung auf 1.2.3.4 vornimmt. Es existiert von nun an ein Informationsunterschied zwischen dem Browser und den serverseitigen Skripten. Der Browser glaubt, auf der Adresse www.meine-domain.de zu sein und fügt allen relativen Verweisen (Links) die Information http://www.meine-domain.de/... bei. Die Skripte hingegen wissen wegen der HTTP-Umleitung nicht mehr, dass sie sich auf http://www.meine-domain.de laufen und können haben nur die Information "Ich laufe auf 1.2.3.4".
Durch Sicherheitsrichtlinien bzw. durch die Vergabe von Cookies können nach dem weiteren Aufruf einer Seite auf 1.2.3.4 die abgesendeten Daten nicht mehr abgerufen werden und somit verlieren sie sich im Nichts.

Des Rätsels Lösung

Das Problem ist einfacher zu lösen als man denkt.

Benutzen Sie bei Ihrem Domainprovider nicht die Verwendungsart "HTTP-Weiterleitung" sondern geben für Ihre Domain einen sogenannten A-Record an.

Der Unterschied liegt in der Art des Datentransfers.

- Bei der Methode der HTTP-Weiterleitung löst der Hostname meine-domain.de zu 5.6.7.8 auf, der IP-Adresse des Domainproviders. Dort findet dann eine HTTP-Weiterleitung auf 1.2.3.4 statt.
- Bei der Methode mit dem A-Record, löst meine-domain.de zu 1.2.3.4 auf. Somit erkennen auch die serverseitigen Skripte die Verbindung von www.meine-domain.de und 1.2.3.4 - es entstehen von nun an keine Probleme mehr mit verloren gegangen POST-Formularen/Login-Daten.

Tipps um zu erkennen, ob Sie auch von diesem Problem betroffen sind

- Prüfen Sie, wo die Links auf Ihren Webseiten hinzeigen. Zeigen Sie dazu mit der Maus auf einen Link, die Zieladresse wird nun in der Statusleiste Ihres Browsers angezeigt. Unterscheidet sich diese Adresse von der in der Adressleiste ihres Browsers angezeigten Adresse, liegt dieses Problem vor.
- Prüfen Sie, wie Sie Ihre Domain bei Ihrem Domainprovider eingestellt haben. Richten Sie anstatt einer HTTP-Weiterleitung einen A-Record mit der IP-Adresse Ihres Webservers ein, wenn Sie Forensoftware, DB-Software oder sonstige dynamischen Skripte auf Ihrem Webserver verwenden.


Ich hoffe, allen mit diesem Beitrag geholfen zu haben und würde mich über Antworten in Bezug auf dieses Thema freuen.
Victor-Phillip Negoescu
ViaThinkSoft Gründer

Feedback? Problems? Please drop us a message!

Your name (optional):

E-mail address (optional):

Message: