www.fabiankeil.de/blog-surrogat/2006/05/13/realitaetsabgleich-fuer-oxid-esales-gmbh.html
Da es mich interessiert, wie viele Leser ihren Rechner korrekt konfiguriert haben und wie viele weiterhin unnötige Informationen preisgeben, überfliege ich regelmäßig das Logfile.
Trotz der Existenz von Privoxy und
+hide-referrer{conditional-block}
stelle ich stets fest: noch immer senden weit über fünfzig Prozent der Besucher den Referer
beim Website-Wechsel mit.
Wie dem auch sei, heute fand ich vereinzelte Verweise auf einen amüsanten Thread im OXID eSales User Forum. Es geht um Probleme mit einem mir nicht näher bekannten Shop-System, der erste Beitrag lautet:
Hallo,
in letzter Zeit häufen sich die Rückmeldungen der Kunden, die leider erfolglos versucht haben zu bestellen.
Ein Rückmeldung war, dass beim Klick auf Schritt 3 wieder die Startseite erschien. (SSL-Server down? Wir hosten bei Profihost.)
Ein anderer Kunde sagte, dass er die Meldung bekommen habe: "Vielen Dank für Ihre Bestellung", aber keine Bestätigungsmail. Im Shop ist dieser Kunde registriert, allerdings keine Historie (!!) und ohne das eine Bestellung da wäre.
Oft denke ich auch, dass die Kunden nicht sehen, dass sie die AGB absegnen müssen und dann denken, die Bestellung sei getätigt.
Die Angaben der Kunden sind, wenn man überhaupt von den Problemen erfährt, oft leider auch nicht sehr präzise.
Klar, das sind 3 verschiedene Geschichten............Leider fehlen mir die Möglichkeiten bzw. das Wissen, da mal tiefer nachforschen zu können.
Gibt's denn keine Möglichkeit, sich da einen genaueren Überblick zu verschaffen, was wo genau passiert ist? Die Auswertung der Statistiken im Admin geben da leider auch nichts her. Wann geschah bei welchem Bestellschritt der Abbruch, welche Fehlermeldung wurde ausgegeben?
Weiter unten im Thread ergänzt der selbe Anwender:
..und wieder ein Anruf von einem Kunden, der vor Wochen bestellt hat. Registrierung ist da, Bestellung wurde abgesendet, thankyou.tpl gezeigt, aber keine Bestätigungsmail vom Shop versendet und es ist auch keine Bestellung im Shop vorhanden................
Der verlinkte Thread bietet weitere Berichte über mysteriöse Bestell-Abbrüche.
Den Beiträgen nach scheint es also ein Shop-System zu geben, bei dem einige Kunden meinen bestellt zu haben, aber ohne das sie es bemerkten vom Shop-System rausgekickt wurden. Der Betreiber erfährt von den Abbrüchen, aber nicht den Grund für den Rausschmiss.
Klingt für mich wie eine prima Sache um Kunden zu vertreiben. Klare Kaufempfehlung meinerseits.
Ein anderes Foren-Mitglied verweist zusätzlich auf den Thread Kaufabbrüche im 3er, dem zufolge der Shop-Betreiber die Meldungen des Shop-Systems erst umsortieren soll, damit der Kunde nicht den Überblick verliert. Mein Respekt steigt weiter.
Als unwissender Laie könnte man voreilig auf die Idee kommen, das Shop-System wäre unbrauchbar, da noch im Beta-Stadium und von mehr Bugs bewohnt als Klendathu – doch Administrator Lars Jankowfsky weiß es natürlich besser:
Ich gehe davon aus das so ein Fehler durch fehlerhafte Fremdsoftware oder Einrichtung erzeugt wird. Der einzige andere Weg der mir noch bekannt ist, ist auf der Bestellung absenden solange zu warten bis ein Session timeout kommt. Oder aber eben direkt per "urlhack" auf die thankyou zu gehen aber da hat man dann niemals eine gueltige Bestellnr. etc.
Klingt logisch, wenn das Shop-System eine nicht aufgenommene Bestellung gegenüber dem Kunden bestätigt, wird Fremdsoftware schuldig sein, was sonst?
In Beitrag 27 wird das Problem schließlich in den Zusammenhang mit Privoxy gebracht und eine Kundin mit den Worten:
wir haben verschiedenes ausprobiert, erfolgreich war die Bestellung erst bei Abschalten des Proxy-Servers (Privoxy). Laut Admin verändert aber Privoxy keine Inhalte. Andere Bestellsysteme z.B. Amazon laufen problemlos trotz Proxy ab. Ich nehme an, das das Oxid-Bestellsystem und Privoxy sich irgendwo gegenseitig blockieren.
zitiert. Dass Privoxy keine Inhalte verändert halte ich zwar für ein Gerücht, dass es keine Probleme mit funktionierenden Online-Shops gibt kann ich aber bestätigen.
Eric Jankowfsky (CEO OXID esales) nutzt die Gelegenheit jedenfalls dazu,
das Problem uagen.pl in die Schuhe zu schieben:
Folgendes Problem:
http://www.fabiankeil.de/blog-surrog...generator.html
Solche und ähnliche Dinge geraten derzeit wie es aussieht in Mode:
Siehe auch: http://www.oxid-esales.com/de/forum/...ight=webwasher
Lösungen für renomierte Systeme Beispielsweise wie den Webwasher können ja angegangen werden. Nicht jedoch für jede derartige Software mit 8- 10 Installationen
Zwischen uagen.pl und Abbrüchen bei Shop-Systemen sah ich erst mal keinen
Zusammenhang. Nicht nur weil uagen.pl hier durchgängig läuft, ohne
das es jemals Bestellprobleme gab, sondern auch, weil uagen.pl lediglich
Auswirkungen auf den User-Agent- und den Accept-Language-Header hat.
Und auch das nur, solange die Kommunikation zwischen Browser und Server nicht verschlüsselt
stattfindet.
Und ganz nebenbei: Privoxy ist zum User-Agent-Fälschen nicht auf uagen.pl
angewiesen, die geschätzten 8- 10 Installationen
weichen daher leicht
von der Realität ab. Ich vermute, Privoxy hat deutlich mehr Anwender als der Webwasher.
Ist aber auch uninteressant, denn es gibt hier kein Privoxy- oder Webwasher-Problem, sondern einen fehlerhaften Online-Shop. Anstatt Ausnahmen für Webwasher zu basteln, sollte der Fehler selbst beseitigt werden. Ist weniger Arbeit und alle haben mehr davon.
Wie jeder Online-Shop-Frickler wissen sollte, sind User-Agent
und Accept-Language
vom Benutzer beliebig veränderbar und darüber hinaus optionale Header.
Für Leute, die die Funktion ihres Web-Shops erst vom Inhalt eines optionalen Headers abhängig machen, und bei dadurch verursachten Fehlfunktionen mit dem Finger auf andere zeigen, habe ich nur Mitleid übrig. Mitleid und einen kleinen Realitätsabgleich.
Referer-HeaderIm verlinkten Thread zu den Webwasher-Problemen verkauft OXID Gold Partner urban die Auswertung eines optionalen Headers sogar als Sicherheitsmerkmal:
Nachtrag zum Thema "eine Lösung von Oxid wünschen": Man kann nicht alles haben. Wie Lars schon erläutert hat, ist die Überprüfung des User-Agents wichtig und unverzichtbar. Denn: siehe unten mein Beispiel mit dem Forum. Solche Sachen werden eben gerade unterbunden, indem der Shop den User-Agent überprüft. Ansonsten würde folgendes möglich sein: Jemand suft - eingeloggt - im Shop, geht danach auf eine andere Seite. Im Logfile des anderen Servers steht als Referer der URL des Shops mit Session-ID!. Da braucht der andere Server-Inhaber nur seine Logfiles durchsehen, den URL extrahieren und in den Browser eingeben - und schon ist er ebenfalls eingeloggt - im Account des ersten Users.
Außer Muahaha! habe ich dazu folgendes zu sagen:
Wenn der Shop nicht auf externe Seiten verlinkt, wird beim Website-Wechsel
kein Referer gesetzt, es sei denn, der Browser ist kaputt.
Für den Shop gibt es keinen Grund, während des Bestellvorgangs auf
externe Websites von Bösewichten zu verlinken – Problem gelöst.
Die Session-ID ist im Normalfall nur zeitlich begrenzt gültig, der Bösewicht auf der externen Website muss sein Logfile in Echtzeit analysieren und reagieren, bevor der Nutzer die Bestellung abgeschlossen hat, oder die Gültigkeit der Session-ID abgelaufen ist. Ein ehrgeiziges Vorhaben.
Wenn der Shop-System-Entwickler verhindern will, dass die Session-ID
jemals im Referer auftauchen kann, muss er sie lediglich über POST- statt
über GET-Abfragen übertragen lassen.
Wichtigstes Argument ist jedoch: Den User-Agent des Benutzers kann der fiktive
Angreifer bequem seinem Logfile entnehmen, im Normalfall steht er ein Feld rechts vom
Referer. Da er den Angriff wegen der begrenzten Gültigkeit der
Session-ID eh automatisieren müsste, wäre es für den fiktiven Angreifer
naheliegend, den User-Agent einfach ebenfalls zu übernehmen.
Dass die Idee, den User-Agent als Sicherheitsmerkmal auszuwerten, von anderen
Shop-Systemen nicht aufgegriffen wurde, könnte also damit zusammen hängen, dass
die Idee nichts taugt.
Sie garantiert einen Haufen Probleme, ohne selbst irgendein Problem zu lösen.