Ich habe seit etlichen Jahren die Gewohnheit, für bekannte Websites
(Home-Banking, Bahn, ...) ein individuelles Frontend zum normalen
Frontend zu programmieren und auf einen Server platzieren.
D.h. wenn ich z.B. eine Bahnfahrkarte buchen will, dann gehe ich nicht
auf bahn.de, sondern auf meinem Server
myserver.de/cgi-bin/bahn.php
dieser hat ein ganz einfaches minimalistisches Interface, und kennt
schon viele Voreinstellungen.
Dieser Server bedient dann die bahn.de Webseiten bis zur Buchung.
Das hatte den Grund, weil vor etlichen Jahren die mobile Netzverbindung
sehr teuer war und Volumen-begrenzt und HSDPA nicht überall verfügbar.
Mit EDGE oder gar GPRS einen normalen Webdienst zu bedienen war grausam.
Für eine bahn.de Buchung mit Firefox muss man mit ca 1MB rechnen
(NoScript aktiv bis auf notwendige Ausnahmen).
In der Arbeit ist auch praktischer, dass man nicht sofort sieht wenn man
privat surft. :-)
Das war gar nicht schwer mit PHP und socket-handling und HTML parsen.
Es gibt ja einige Bibliotheken.
Allerdings kommt immer mehr Javascript in die Webseiten mit rein.
Einfaches Javascript (z.B. url-redirect) habe ich selber geparst.
Bei schwierigen Sachen bin ich teilweise umgezogen auf meine heimische
Fritzbox. Da läuft SpiderMonkey, der mir Javascript parsen kann.
Wie kann man das Problem mit Javascript anders lösen (mit PHP auf
normalen Webhoster)?
Der Hammer ist bei bahn.de.
Bei Zugverbindungen gab es immer eine table, wo die Uhrzeiten (Abfahrt,
Ankunft), Preis, ... als Matrix drin.
Das ist nicht mehr der Fall. Die bauen sich die Struktur komplett in
Javascript auf, z.B.
1
...
2
reiseabschnitt.ziel.typ="Haltestelle";
3
reiseabschnitt.ziel.land="DEU";
4
reiseabschnitt.produktklassen=newObject();
5
reiseabschnitt.produktklassen.ICE=0;
6
reiseabschnitt.produktklassen.IC_EC=0;
7
reiseabschnitt.produktklassen.IR=0;
8
reiseabschnitt.produktklassen.RE_RB=0;
9
reiseabschnitt.produktklassen.S=0;
10
reiseabschnitt.produktklassen.Bus=0;
11
reiseabschnitt.produktklassen.Schiff=0;
12
reiseabschnitt.produktklassen.U=0;
13
reiseabschnitt.produktklassen.Tram=0;
14
reiseabschnitt.produktklassen.AST=0;
15
reiseabschnitt.produktklassen.RE_RB=1;
16
reiseabschnitt.aufenthaltszeit="00:25";
17
reiseabschnitt.abfahrt="2017-08-28T17:35";
18
reiseabschnitt.ankunft="2017-08-28T18:55";
19
...
Das ist ja total verrückt. Die ganze Webseite besteht fast nur aus JS.
Warum macht man sowas?
PHP-Fan schrieb:> Die ganze Webseite besteht fast nur aus JS.> Warum macht man sowas?
Kundenunfreundlichkeit gehört doch schon seit Jahren zur Bahn. Warum
wunderst du dich nun darüber?
T.roll schrieb:> Kundenunfreundlichkeit gehört doch schon seit Jahren zur Bahn.
Find ich jetzt nicht unbedingt.
> Warum wunderst du dich nun darüber?
Wenn Website-Betreiber wollen, dass ihre Sites nicht automatisiert
betrieben werden (Robots), dann gibt es wirsame Mittel (Captcha).
Wollen die Robots vermeiden durch viel JS?
Für richtige Robot-Experten (ich bin keiner) wäre JS auch kein großes
Hinderniss mehr. Captcha schon.
PHP-Fan schrieb:> Die ganze Webseite besteht fast nur aus JS. Warum macht man sowas?
1. Weil es hip ist.
2. Weil man so nur ein Backend für alle Websites, Apps etc. braucht.
3. Weil man so mit den Daten im Browser arbeiten kann, und nicht für
alles einen serverseitigen Request braucht.
PHP-Fan schrieb:> Das hatte den Grund, weil vor etlichen Jahren die mobile Netzverbindung> sehr teuer war und Volumen-begrenzt und HSDPA nicht überall verfügbar.> Mit EDGE oder gar GPRS einen normalen Webdienst zu bedienen war grausam.> Für eine bahn.de Buchung mit Firefox muss man mit ca 1MB rechnen> (NoScript aktiv bis auf notwendige Ausnahmen).
Lösung: Schon bevor bevor es (in Deutschland) überhaupt EDGE gab, hatte
die Bahn bereits eine mobile Version ihres Angebots. Jetzt noch das
Laden von Grafiken im Browser deaktivieren und man hat ein zwar
hässliches aber äußerst leichtgewichtiges Fahrplan- und Buchungsportal.
Damit habe ich vor 10+ Jahren Buchungen mit ein paar Dutzend kB und
kurzen Ladezeiten bei miesem Netz durchgeführt. Wie sich das heute
verhalten würde, weiß ich nicht - die Frage stellt sich ja nur noch sehr
eingeschränkt.
Es macht Spaß, sich selbst solche Lösungen zu stricken, wie du es
machst. Außerdem kann man dabei einiges lernen. Es ist aber objektiv
betrachtet weder notwendig noch sinnvoll und außerdem ein direkter
Verstoß gegen die Nutzungsbedingungen der Bahn und nahezu jedes anderen
solchen Angebots. Was du hier machst, kann daher keinesfalls der Maßstab
dafür sein, was "total verrückt" ist.
PHP-Fan schrieb:> Die ganze Webseite besteht fast nur aus JS.> Warum macht man sowas?
Weil jemand in entscheidender Position zur Erkenntnis gelangt ist, dass
es das richtige Werkzeug für die Aufgabe ist. (Echt jetzt? ;)
> Damit habe ich vor 10+ Jahren Buchungen mit ein paar Dutzend kB und> kurzen Ladezeiten bei miesem Netz durchgeführt.
bei mir war es mehr, ohne Download der pdf-Fahrkarte.
Die akuten Probleme hatte ich 2013, weswegen ich das mit dem neuen
frontend machte.
Bahn.de hat ja auch eine schlanke mobile Version. Nur die kann man
vergessen, wenn man Papier-Fahrkarten will und keinen DB-Navigator.
> Es macht Spaß, sich selbst solche Lösungen zu stricken, wie du es> machst. Außerdem kann man dabei einiges lernen.
Ja das stimmt.
Mich hat auch interessiert, welche Daten wirklich hin- und her wandern,
welche Cookies angelegt werden usw.
> jemand in entscheidender Position zur Erkenntnis gelangt ist
Bahn.de hat etliches verbessert die letzten Jahre. Z.B. muss man nicht
mehr jedesmal die komplette Zahlungsinformation eingeben, sondern bei
Kreditkarten-Zahlung nur die 3-stellige Prüfziffer.
Trotzdem neige ich dazu, lieber Javascript auszuschalten bei Websiten
mit Bezahlung oder anderen persönlichen Informationen.
NoScript habe ich sowieso immer eingeschaltet, muss aber entsprechende
Ausnahmen genehmigen.
Außer Rhino (Java) und SpiderMonkey scheint es kein Konzept zu geben,
wie man solche Seiten effektiv Parsen kann?
PHP-Fan schrieb:> Außer Rhino (Java) und SpiderMonkey scheint es kein Konzept zu geben,> wie man solche Seiten effektiv Parsen kann?
schon mal versucht die seite mit deaktivierten Javascript zu besuchen,
das scheint soweit zu gehen, ergo kann man es auch parsen.
Unter Python gibt es auch noch einen recht guten weg.
https://impythonist.wordpress.com/2015/01/06/ultimate-guide-for-scraping-javascript-rendered-web-pages/
Der trick Hierbei bei ist es das javascript mit webkit arbeiten zu
lassen und das ergebnis zu parsen sowas wird es sicher auch in andern
Sprachen geben.
PHP-Fan schrieb:> Ich habe seit etlichen Jahren die Gewohnheit, für bekannte Websites> (Home-Banking, Bahn, ...) ein individuelles Frontend zum normalen> Frontend zu programmieren und auf einen Server platzieren.
Home-Banking Seiten die sich scrapen lassen und von deinen
Man-in-the-middle steuern, Das kling gruselig. Wenn ich von jemanden
erwarte das zu verhindern dann sind es Banken und Versicherungen.
> Home-Banking Seiten die sich scrapen lassen und von deinen> Man-in-the-middle steuern, Das kling gruselig. Wenn ich von jemanden> erwarte das zu verhindern dann sind es Banken und Versicherungen.
Das geht mit Standardfunktionen eigentlich sehr leicht (Kontoauszüge
holen, Überweisungen).
Die Frage nach der TAN muss ich natürlich durchreichen.
Automatisiert broken (WP Geschäfte) nicht.
Was soll daran gruselig sein? Hängt davon ab, wo der Server gehostet
ist.
Dass auf einem lokalen Rechner ein Keylogger oder andere Malware
installiert ist, halte ich für das größere Risiko.
Gerade wieder einen Dienst fertiggestellt, der mir das alditalk Konto
ausliesst mit den verbleibenden MB und Gesprächsminuten.
imonbln schrieb:>> schon mal versucht die seite mit deaktivierten Javascript zu besuchen,> das scheint soweit zu gehen, ergo kann man es auch parsen.
Danke, das scheint zu gehen.
Aber aufpassen: es wird gleich eine Fahrkarte für 5 Erwachsene gebucht,
die Personen 2-5 müssen erst deaktiviert werden.
Der Javascript-Code steht noch drin, aber auch die normale table.
PHP-Fan schrieb:> Was soll daran gruselig sein? Hängt davon ab, wo der Server gehostet> ist.
das sagen wir mal Moralisch nicht gefestigter Mensch die Webseite
nachbauen kann und alle Interaktionen durch reicht mit Erfolg. Bis zu
denn Punkt wo es um eine Überweisung geht, diese geht an ein anderes
Konto als geplant und du hast den Spaß der Bank zu erklären warum die
Überweisung falsch war trotz gültiger TAN etc.
Sicher deine Anwendung ist Spielerei und erstmals Harmlos aber sie zeigt
das Dinge möglich sind, welche Kriminell nutzen könnten um Oma eine
gefakte Webseite zu liefern und Überweisungen abzugreifen.
An die Aufbereitung von haufiger genutzten Seiten hab ich auch schon
gedacht. Aber die Betreiber aendern doch staendig etwas, dann rennt man
immer hinterher, d.h. das bleibt nicht beim einmaligen Aufwand.
Naja, äußerlich ändert sich was, aber die Namen für die Form-Controls
bleiben fast immer gleich.
Bei bahn.de z.B.
tariffTravellerReductionClass.1, tariffTravellerType.2
ist schon seit Jahrzehnten gleich.
Als blau.de von Telefonica übernommen wurde, hat sich viel geändert.
Aber mit ein bischen Übung hat man das schnell wieder laufend.
Die meiste Arbeit ist das formatieren: Die wichtigste Information
herausholen und eine einfache minimalistische Ausgabe generieren.
Verschicken von form-posts ist relativ schnell gemacht.
PHP-Fan schrieb:> Der Hammer ist bei bahn.de.> Bei Zugverbindungen gab es immer eine table, wo die Uhrzeiten (Abfahrt,> Ankunft), Preis, ... als Matrix drin.> Das ist nicht mehr der Fall. Die bauen sich die Struktur komplett in> Javascript auf, z.B.
Das macht bei grösseren Projekten schon Sinn, denn "heutzutage" trennt
man das Design von den Daten. An ein Designelement kann man dann zur
Anzeige der Daten einfach einen Datensatz per "binding" anbinden.
Es gibt verschiedene Modelle dafür, z.B. das MVVM (Model View
ViewModel):
https://de.wikipedia.org/wiki/Model_View_ViewModel
Wie gesagt, eignet es sich vorallem für umfangreichere Projekte, da dann
einzelne Projektteile besser auf verschiedene Leute und Teams aufgeteilt
werden können und Aufgaben besser gekapselt werden können.
Ja, es macht auch Sinn, wenn man manche Verbindungsvorschläge aufklappen
will (d.h. Zwischenstationen zum umsteigen) oder alle Zwischenstationen
anschauen will.
Das ist der Vorteil von JS: man muss nichts zum Server schicken, sondern
kann die Darstellung "flüssig" anpassen.
... im Firefox Browser funktioniert das mit Greasemonkey und Java Script
ganz gut. Ich habe einige Webseiten um Export-Funktionen "erweitert",
ein extra Button erzeugt jetzt eine CSV-Textdatei mit dem Inhalt des
Warenkorbes, der dann wieder in ein Bestellsystem importiert wird zur
"eigentlichen" Bestellung - das System läuft mit SAP und hat zum Glück
eine Importschnittstelle ....
phantomjs+casperjs benutzen. Das ist ein headless browser der dir die
seite so zurückliefert als würde sie im browser gerendert (wird sie ja
auch nur eben headless), dort kannst du dann per js schalten und walten
wie du willst, mit casperjs geht das dann nochmal nen Tick einfacher für
gängige Tasks. Ist eigentlich zum Frontendtestautomatisierung geht aber
auch wunderbar zum scrappen von webseiten, mit einigen Einschränkungen.
Aber das was du vor hast sollte es funktionieren.
Hört sich interessant an.
Kommt halt drauf an, wie robust und fehlertolerant das ist.
Die Html-Code von vielen professionellen Sites (z.B. bahn.de) enthält
fehler!
da gibt es tags <a xref="xxx"name="asdf"> oder <br />>
(xref ersetzen, die forensoftware mag das wort nicht)
Der bekannte "SAX"-parser (unter Java) scheitert oft.
Ich denke, viele Websites-Betreiber machen das absichtlich, um scrapper
abzuschrecken.
Die bekannten Browser (Firefox, Chrome) hingegen sind sehr
fehlertolerant.
Imonbln schrieb:> das sagen wir mal Moralisch nicht gefestigter Mensch die Webseite> nachbauen kann und alle Interaktionen durch reicht mit Erfolg. Bis zu> denn Punkt wo es um eine Überweisung geht, diese geht an ein anderes> Konto als geplant und du hast den Spaß der Bank zu erklären warum die> Überweisung falsch war trotz gültiger TAN etc.
Deshalb ist (i)TAN auch schon länger obsolet. Mit mTAN bekomme ich nicht
nur TAN, sondern auch Zielkontonummer und Betrag aufs Handy.
Natürlich gibt es auch hier Angriffsvektoren, aber die vorgeschaltete
Seite bringt den Kriminellen nicht mehr so viel.
PHP-Fan schrieb:> Die bekannten Browser (Firefox, Chrome) hingegen sind sehr> fehlertolerant.
Die lassen sich auch 'headless' betreiben, insbesondere Chrome bietet
sich hierfür an.
Jan H. schrieb:> Deshalb ist (i)TAN auch schon länger obsolet. Mit mTAN bekomme ich nicht> nur TAN, sondern auch Zielkontonummer und Betrag aufs Handy.> Natürlich gibt es auch hier Angriffsvektoren, aber die vorgeschaltete> Seite bringt den Kriminellen nicht mehr so viel.
doch mTan ist viel angreifbarer. Man hat keinen 2. Übertragungsweg. Wie
schon mehrfach geschehen kann man die SMS Umleitung oder abfangen.
(Google -> ss7 )
Bei iTan muss ich als Anwender aktiv werden, mit mTAN kann mein Konto
ohne meine "mithilfe" geplündert werden.
PHP-Fan schrieb:> Ich denke, viele Websites-Betreiber machen das absichtlich, um scrapper> abzuschrecken.> Die bekannten Browser (Firefox, Chrome) hingegen sind sehr> fehlertolerant.
phantomjs + casperjs IST ein Browser, nur eben ohne GUI und besser
scriptbar, das ist der Clou dahinter. Die gerenderte Seite (kannst
Screenshots machen, Auflösung deines "Monitors" vorher festlegen) ist
identisch zu der des jeweiligen Browsers. phantomjs nutzt die
Webkit-Engine, ist nur immer ein bischen in den Versionen hinterher aber
recht aktuell.
Thread beobachten
Seitenaufteilung abschalten