Unterschied zwischen Submit und "Seitenaufruf"

[Filiz]

Hallo,

ich hoffe mein Betreff drückt die Problematik aus.
Es geht um folgendes:
ich habe ein Programm in VB2010 geschrieben, welches ein WebbrowserControl verwendet. Wenn ich richtig informiert bin, wird bei diesem Element eine IE Engine verwendet.

Das Programm soll mir eine Form ausfüllen und diese anschließend mit submit abschicken.Genauer gesagt soll der Benutzer in einem autmoatisierten Seitenaufruf ein Captcha eintragen, welches dann übermittelt wird.
Da die mitgelieferten Lösungen zum Absenden einer Form nicht den gewünschten Effekt hatten, habe ich den Traffic mit Wireshark gecaptured um zu schauen was auf Protokollebene passiert. Dabei ist mir aufgefallen, dass alle Submit-Varianten im wesentlichen die gleichen Aufrufe beinhalteten:

in den wireshark logs wurden gleiche(!) und unrelevante teile durch [ausdruck] ersetzt oder geloescht:

manueller click (funktioniert):
GET /sorry/Captcha?continue=[host][q=...].%26aq%3Df&id=1098191381004534661&captcha=helfe HTTP/1.1\r\n

absenden durch sendkeys(enter) (funktioniert):
GET /sorry/Captcha?continue=[host][q=...].%26aq%3Df&id=14967334177981689414&captcha=nopro&submit=Ich+bin+ein+Mensch. HTTP/1.1

absenden mit der invokemembers-methode (funktioniert nicht):
GET /sorry/Captcha?continue=[host][q=...].%26aq%3Df&id=5120600837596171139&captcha=dablear&submit=Ich+bin+ein+Mensch. HTTP/1.1\r\n

parsen des form-quelltextes und nachbilden des links. anschließend ein webbrowser.navigate(mylink)(funktioniert nicht):
GET /sorry/Captcha?continue=[host][q=...]&aq=f&id=11063732305888676684&captcha=pasive HTTP/1.1

meine frage ist also, worin die unterschiede liegen. auf unterster ebene laufen ja scheinbar die gleichen befehle ab. erst dachte ich es würde an dem "submit=Ich+bin+ein+Mensch" zusatz liegen. da die enter-variante jedoch die gleiche request erzeugt und funktioniert, fällt diese lösung weg.

kann es sein, dass beim klick auf submit zusaetzliche informationen im cookie gespeichert werden? wo kann ich weitersuchen?

[LX]

Der Name "submit" für Formularfelder ist eine ziemlich dumme Idee - weil form.submit normalerweise die submit-Methode des Formulars darstellt und daher möglicherweise nicht ausgelesen werden kann.

Gruß, LX

[suit]

meine frage ist also, worin die unterschiede liegen.

Es gibt keine.

Ob du das Zeug in die Adresszeile schreibst und Enter drückst, ob du das Formular asfüllst und mit der Tastatur abschickst oder den Submit-Button klickst kannst du nicht Unterschieden.

Abgesehen von diversen Schindludern, die es komplizierter machen: z.B. einen Grafischen Submitbutton der beim Klick seine Korrordinaten mitschickt oder ein JavaScript das beim Absenden noch schnell einen Wert hinzuschmuggelt.

Aber das fällt schon wieder in die Kategorie Plausiblitätsprüfung.

auf unterster ebene laufen ja scheinbar die gleichen befehle ab.

Ja, entweder GET oder POST - und wie dieser request erzeugt wurde, kannst du nicht nachvollziehen.

fällt diese lösung weg.

Für welches Problem?

[Filiz]

fällt diese lösung weg.

Für welches Problem?

die antwort kam ja wahnsinnig schnell. danke.

das problem ist: das captcha soll geloest werden.
zwei methoden loesen das captcha:
1. man gibt es direkt im browser ein und klickt.
2. man fuellt das input feld mit der eingabe, setzt den fokus auf die form und sendet ein enter

das problem ist, dass bei beiden ein browserfenster zu sehen sein muss, was es nicht soll. in jedem fall kann ich danach weitermachen und seiten aufrufen.

bei den beiden anderen varianten wird zwar das "gleiche" get abgeschickt aber ich krieg immer wieder einen redirect auf die captcha seite.

[MudGuard]

Hi,

das problem ist: das captcha soll geloest werden.
das problem ist, dass bei beiden ein browserfenster zu sehen sein muss, was es nicht soll.

Man soll also ein Captcha lösen, ohne es zu sehen?

cu,
Andreas

[Filiz]

das problem ist: das captcha soll geloest werden.
das problem ist, dass bei beiden ein browserfenster zu sehen sein muss, was es nicht soll.

Man soll also ein Captcha lösen, ohne es zu sehen?

schoen waers ;-) das bild wird dem user separat angezeigt (war ein ganz schoenes gefrickel). dazu gibt es ein input txt feld. der inhalt soll nach eingabe zum loesen benutzt werden

[Der Martin]

Hallo,

Das Programm soll mir eine Form ausfüllen ...

eine Form? Du meinst ein Formular?

in den wireshark logs wurden gleiche(!) und unrelevante teile durch [ausdruck] ersetzt oder geloescht:

Du hast hier zum Vergleichen immer nur die URL-Zeile angegeben. Hast du andere Header überhaupt betrachtet (User-Agent, Referer), vor allem die Cookies?

kann es sein, dass beim klick auf submit zusaetzliche informationen im cookie gespeichert werden?

Jein. Beim Aufruf der Formularseite bekommst du vermutlich ein Cookie untergeschoben, das der Browser beim Absenden des Formulars auch ganz normal wieder vorzeigt - wie bei jedem weiteren Request an eine Domain, für die das Cookie gültig ist. Das musst du bei deiner automatisierten Lösung natürlich auch tun.

Die anderen erwähnten Header *könnten* serverseitig mit auf Plausibilität überprüft werden; bei den Cookies ist es aber sehr wahrscheinlich.

So long,
 Martin

[Filiz]

Hallo,

zunächst einmal danke, für die schnelle rückmeldung.

eine Form? Du meinst ein Formular?

genau das meine ich ;-)

Du hast hier zum Vergleichen immer nur die URL-Zeile angegeben. Hast du andere Header überhaupt betrachtet (User-Agent, Referer), vor allem die Cookies?

das habe ich, die waren jedoch überall identisch:
Referer: [host]/sorry/?continue=[host]/products%3F[q=...].%26aq%3Df\r\n

[truncated] Cookie: PREF=ID=8a1d1b8fb0b8df96:U=f67d1759017db683:FF=0:TM=1294739824:LM=1294739825:S=o5w__keGrTgiPI3b; NID=42=ctsGfFeKVWs8caEuNobbgYOJBqzXZfxMw6DUtlFhrROQkejxrSEayIu6UESGxii81iDi-o2x6QYVZ1GJguIAgHxWEQYj2MjmWom2i-gSsPQapl-QhM1

[truncated] Cookie: PREF=ID=8a1d1b8fb0b8df96:U=f67d1759017db683:FF=0:TM=1294739824:LM=1294739825:S=o5w__keGrTgiPI3b; NID=42=ctsGfFeKVWs8caEuNobbgYOJBqzXZfxMw6DUtlFhrROQkejxrSEayIu6UESGxii81iDi-o2x6QYVZ1GJguIAgHxWEQYj2MjmWom2i-gSsPQapl-QhM1

[truncated] Cookie: PREF=ID=8a1d1b8fb0b8df96:U=f67d1759017db683:FF=0:TM=1294739824:LM=1294739825:S=o5w__keGrTgiPI3b; NID=42=ctsGfFeKVWs8caEuNobbgYOJBqzXZfxMw6DUtlFhrROQkejxrSEayIu6UESGxii81iDi-o2x6QYVZ1GJguIAgHxWEQYj2MjmWom2i-gSsPQapl-QhM1

kann es sein, dass beim klick auf submit zusaetzliche informationen im cookie gespeichert werden?

Jein. Beim Aufruf der Formularseite bekommst du vermutlich ein Cookie untergeschoben, das der Browser beim Absenden des Formulars auch ganz normal wieder vorzeigt - wie bei jedem weiteren Request an eine Domain, für die das Cookie gültig ist. Das musst du bei deiner automatisierten Lösung natürlich auch tun.

Die anderen erwähnten Header *könnten* serverseitig mit auf Plausibilität überprüft werden; bei den Cookies ist es aber sehr wahrscheinlich.

So long,
Martin

die cookies habe ich mir noch nicht im detail angeschaut (weiß grad auch noch nicht, wie ich das am besten mache). du meinst also, dass man da einen blick riskieren sollte? das paradoxe ist ja in der tat, dass alle requests mehr oder weniger gleich sind. bei 2 varianten kommt aber immer ein 302 zurück mit redirect auf eine neue captcha seite.

[Der Martin]

Hi,

Du hast hier zum Vergleichen immer nur die URL-Zeile angegeben. Hast du andere Header überhaupt betrachtet (User-Agent, Referer), vor allem die Cookies?
das habe ich, die waren jedoch überall identisch:

okay, du hast sie nicht erwähnt. Daher dachte ich, du hättest sie vielleicht nicht beachtet.

die cookies habe ich mir noch nicht im detail angeschaut (weiß grad auch noch nicht, wie ich das am besten mache). du meinst also, dass man da einen blick riskieren sollte?

Unbedingt ...

das paradoxe ist ja in der tat, dass alle requests mehr oder weniger gleich sind. bei 2 varianten kommt aber immer ein 302 zurück mit redirect auf eine neue captcha seite.

Naja, du darfst natürlich nicht das Cookie senden, das der Browser beim Vergleichs-Request bekommen hat, sondern dasjenige, das auch zum aktuellen Captcha gehört und mit dem Formular geliefert wurde. Im Cookie-Wert steckt ja normalerweise auf irgendeine Weise der Bezug zum ausgewählten und zu lösenden Captcha.

Ciao,
 Martin

[Filiz]

Naja, du darfst natürlich nicht das Cookie senden, das der Browser beim Vergleichs-Request bekommen hat, sondern dasjenige, das auch zum aktuellen Captcha gehört und mit dem Formular geliefert wurde. Im Cookie-Wert steckt ja normalerweise auf irgendeine Weise der Bezug zum ausgewählten und zu lösenden Captcha.

Ciao,
Martin

Ok, hab das Cookie gefunden.
Da steckt aber nichts verwertbares drin.

Es werden 3 IDs gesetzt. Zusaetzlich sind diese gefolgt von ein paar Zahlen deren Bedeutung sich mir nicht erschließt.

Heißt das, dass ich keine Möglichkeit habe die Daten des Formulars manuell an den Server zu senden? Ich kann mir kaum vorstellen, dass ich immer den Submit Button klicken MUSS.

[Der Martin]

Hallo,

Naja, du darfst natürlich nicht das Cookie senden, das der Browser beim Vergleichs-Request bekommen hat, sondern dasjenige, das auch zum aktuellen Captcha gehört und mit dem Formular geliefert wurde. Im Cookie-Wert steckt ja normalerweise auf irgendeine Weise der Bezug zum ausgewählten und zu lösenden Captcha.
Ok, hab das Cookie gefunden.
Da steckt aber nichts verwertbares drin.

das meinst du - der Server, der dir den Keks gegeben hat, sieht das vermutlich anders.

Es werden 3 IDs gesetzt. Zusaetzlich sind diese gefolgt von ein paar Zahlen deren Bedeutung sich mir nicht erschließt.

Das ist auch egal.

Heißt das, dass ich keine Möglichkeit habe die Daten des Formulars manuell an den Server zu senden? Ich kann mir kaum vorstellen, dass ich immer den Submit Button klicken MUSS.

Keineswegs, nein. Du musst nur das Formular abrufen, dabei kriegst du ein Cookie (oder mehrere) und die Captcha-Grafik. Als nächsten Schritt brauchst du normalerweise nur die Formulardaten und das/die erhaltene/n Cookie/s zurückzuschicken. Etwas anderes macht ein Browser ja auch nicht.

Ciao,
 Martin

[Filiz Gelöst!]

Keineswegs, nein. Du musst nur das Formular abrufen, dabei kriegst du ein Cookie (oder mehrere) und die Captcha-Grafik. Als nächsten Schritt brauchst du normalerweise nur die Formulardaten und das/die erhaltene/n Cookie/s zurückzuschicken. Etwas anderes macht ein Browser ja auch nicht.

Hallo,

ich konnte das Problem scheinbar lösen.
Tatsächlich haben meine beiden anderen Methoden auch funktioniert.
Das Problem war, dass es zu einer Art Wettlaufsituation gekommen ist, bedingt durch die Schleife in der ich dauernd neue URLs aufgerufen habe. Bei genauem betrachten der Wireshark Logs ist es mir aufgefallen:

1. Formular mit Captcha wird abgesendet
GET /sorry/Captcha?continue=[host]/products?[q=...]&aq=f&id=10766246835841737731&captcha=wartost HTTP/1.1\r\n

2. Das ist schon eine neue Anfrage
GET /products?[q=...]&aq=f HTTP/1.1\r\n

3. Hier wird das Captcha akzeptiert und ich werde weitergeleitet
HTTP/1.1 200 OK\r\n
  Location: [host]/products?[q=...]\r\n

4. Gleich darauf wird Anfrage 2 "gesperrt" und ich werde zum Captcha geleitet
HTTP/1.1 302 Found\r\n
  Location: [host]/sorry/?continue=[host]/products%3F[q=...]aq%3Df\r\n

5. Es wird nicht Location aus Status 200 sondern 302 aufgerufen-> alles beginnt von vorn
GET /sorry/?continue=[host]/products%3F[q=...]aq%3Df HTTP/1.1\r\n

Ich hatte zwar nach dem Absenden des Formulars ein sleep eingebaut, jedoch hat es äußerst ungünstig den gesamten Ablauf blockiert, wodurch beide Anfragen trotzdem direkt hintereinander rausgingen.

Ich möchte mich noch einmal bei allen bedanken, denn letzten endes waren eure aussagen entscheidend dafür, dass ich den weg nicht verworfen, sondern noch einmal genau geschaut habe. Insbesondere die überlegungen zu Cookies haben mir geholfen die Abläufe ein bisschen besser zu verstehen.