Socket oder URL-Client

[mOSSpOWER]

Hallo, suche dringend für folgenden Sachverhalt Hilfe,

ich denke, dass alles was mit dem Browser machbar ist auch mit einem Socket (oder URL-Objekt) geht. Ich möchte mich bei einer Webite anmelden und dann weiternavigieren und mir die Infos tracken, die ich benötige - mein Problem ist die Session ... die ist ja glaube ich im Header unter ETag ... was muss ich beachten, wenn ich mich eingelogged habe (die Connection ist ja dann wieder unterbrochen) und ich dann weiternavigieren möchte ... was (oder besser) wie übergebe ich die Headerinfos .... (die braucht ja der Server für die eindeutige Kennung, um ihm mitzuteilen, dass der User mit dem angeforderten Request bereits autentifiziert ist) ... ich dachte, dass es einfach mit jsession=SESSIONID als Parameter übergeben ... leider klappt das nicht .. wie macht Ihr das (oder würdet Ihr das machen?)

Schon mal vielen Dank im Voraus.

Gruß

[perdian]

Am einfachsten ist es, wenn du direkt einen richtigen HTTP Client verwendest, der nimmt dir das ganze LowLevel HTTP Handling ab:

Mein Favorit:

http://httpunit.sourceforge.net/

oder auch:

http://jakarta.apache.org/commons/httpclient/

[Whatever]

Vermutlich setzt die Webseite eine Coockie mit der Seesionid bei dir.

[mOSSpOWER]

Am einfachsten ist es, wenn du direkt einen richtigen HTTP Client verwendest, der nimmt dir das ganze LowLevel HTTP Handling ab:

Hi,

sorry, das ist mir jetzt zu hoch ... habe da nicht die super Erfahrung ... wenn ich drauf zugreife, bin ich doch auch ein "richtiger HTTP-Client" ... oder nicht? ... was meinst Du?

Gruß

[mOSSpOWER]

Vermutlich setzt die Webseite eine Coockie mit der Seesionid bei dir.

Hallo,

nun, das sollte doch eigentlich egal sein, denn wenn der Client Cookies disabled, dann setzt doch URL-Rewriting ein (in Tomcat automatisch mit jsessionid=SESSIONID an den Request) ... hm .. irgendwie muss das doch möglich sein .. naja, danke mal für die Hilfe ... ich suche weiter.

Gruß

P.S. Ich schreibe gerade einen "ultra-" HTML-Tracker (konfigurierbar über xml-File, bzw. über GUI) ... da sollte es dann schon egal sein, ob der Server Cookies schreibt, POST verwendet oder whatever.

[perdian]

sorry, das ist mir jetzt zu hoch ... habe da nicht die super Erfahrung ... wenn ich drauf zugreife, bin ich doch auch ein "richtiger HTTP-Client" ... oder nicht?

Naja java.net.URL implementiert schon einen kleinen HTTP Client, das ist schon richtig. Die Funktionalitäten, die dir hierbei geboten werden sind jedoch äusserst bescheiden. Mit halbwegs komfortabler Parameter-Übergabe fängt es schon an. Dazu ist jeder Zugriff über die URL stateless, das heisst Aufruf B, der auf grund des Ergebnisses von Anfrage A gemacht worden ist übernimmt keine Cookies, etc. Gerade diese Dinge bekommst du mit einem "großen" HTTP Client (wie z.B. httpunit) deutlich angenehmer hin. Dazu kommt, dass dort auch JavaScript ausgewertet werden kann, direkt über DOM auf die zurückgelieferte HTML Datei zurückgegriffen werden kann etc. Letzten Endes alles Dinge, die duch auch über direkten URL zugriff erledigen könntest, jedoch mit deutlich mehr Aufwand.

wenn der Client Cookies disabled, dann setzt doch URL-Rewriting ein (in Tomcat automatisch mit jsessionid=SESSIONID an den Request)

Aber nicht, wenn dieses Verhalten nicht auch explizit von der WebApplication angefordert wird.

[mOSSpOWER]

... Gerade diese Dinge bekommst du mit einem "großen" HTTP Client (wie z.B. httpunit) deutlich angenehmer hin ...

...

OK, ich habe da schon gerade mal reingeschaut ... scheint alles drin zu sein .. werde mich da mal weiter einlesen ... danke

Aber nicht, wenn dieses Verhalten nicht auch explizit von der WebApplication angefordert wird.

Du meinst request.encodeURL("fo") ? ... hm, ich dachte das mal getestet zu haben (schon länger her) ... ist dann aber zu meinem Erstaunen trotzdem gegangen .. und letztens sagte ein Kollege, dass dies Tomcat automatisch macht ... wahrscheinlich in der JSP automatisch, wenn Client cookies disabled hat ... bin mir da aber nich 100 % sicher ... danke nochmals für die tollen Tips ... ich hoffe, dass bei HttpUnit was für mich dabei ist.

Gruß

[perdian]

dass dies Tomcat automatisch macht

Nein, macht er nicht - und das ist auch gut so. Ein Webserver soll(te) die von mir geschriebenen Logiken niemals ändern ohne dass ich das vorher genauso so eingestellt habe.

[mOSSpOWER]

Hallo perdi, hallo Interessierte oder Eingeweihte

ich hatte vor langem mal eine Antwort von Dir bekommen -> Thread httpunit ... nun bin ich schon weiter und finde httpunit wirklich gut ... nun möchte ich aber auf Seiten auch den manipulierten DOM auslesen, leider funzzt das nicht, bzw. ich bekomme den Ursprungsdom. Einmal ein praktisches Beispiel: ich rufe Seite auf und da steht dann u.a.

<div id="someId">Starting Text</div>

so ... dies sieht man aber nicht im Browser, aber wohl im Quellcode, da weiter im Quellcode dann (total vereinfacht) z.B. steht ...

<script>docuement.getElementById("someId").innerHTML = "blablabla";</script>

wie komme ich jetzt mit httpunit an die Info? (dazu gibt es leider kein Tutorial ... wenn ich es so versuche ...

webResponse.getElementWithID("someId"); 

... bekomme ich null ... wenn ich es so versuche ...

webResponse.getScriptableObject().getDocument().getElementWithID("someId")

... bekomme ich das Original, sprich das nicht manipulierte Objekt mit dem Text "Starting Text". Weißt Du vielleicht, wie ich daran komme .. muss ich hier vielleicht selbst die Function aufrufen? .. wie geht das? .. Danke für evtl. Antwort, aber im http-Forum habe ich jetzt noch nix gefunden.

Gruß

[perdian]

Also entweder per PM oder im Forum - dann haben auch alles was davon:

also ich tippe mal auf folgendes: Damit in das entsprechende Element der Inhalt reingeschrieben wird muss JavaScript aktiviert sein - im Browser funktioniert es daher auch ohne Probleme.

httpunit allerdings führt das JavaScript, was den Inhalt ändern so wie es aussieht nicht aus - daher auch der alte Inhalt. Von daher wäre ein Ansatzpunkt zu versuchen httpunit die Ausführung von JavaScript beizubringen.

Irgendwie geht auch das, aber das ist inzwischen schon eine ganze Weile her und ich müsse auch in den entsprechenden Dokus suchen, von daher: Dort sollte sich - wenn es geht - dazu etwas finden lassen.

[mOSSpOWER]

@Perdi ... OK, machen wir im Forum weiter ... habe hier die Antwort erst nach meiner Antwort gesehen, deshalb ...

Also erstmal tausend Dank für Deine Antwort ... nun, das dachte ich Anfangs auch, aber wenn ich einen Javascript-Fehler in die HTML-Seite reinmache, gibt es einen Fehler (inwiefern das jetzt Rhino ist oder "nur" der Parser weiß ich (noch) net) ... naja, vielleicht klappt das überhaupt nicht, denn dann könnte man ja (fast) alles machen (inklusive AJAX) ... und das wäre wirklich toll ... leider habe ich weder im Forum, noch im Quellcode oder aber in den Test- und Beispieldateien gar nix hierfür gefunden ... vielleicht ist es ja wirklich nur so, dass halt geprüft wird, ob JS-Fehler vorliegt und dann kann man halt einfach durchs Dokument klicken und Forms abschicken (und mehr nicht) ... es ist so schon sehr viel ... aber warum dann das mit Rhino drinnen ist, weiß ich auch net ... da habe ich keine Erfahrungen und im Web finde ich da auch nix .. von professionellen Büchern ganz zu schweigen ...naja, muß ich mich weiter umhören oder schauen ... ich glaube bei httpunit ist auch schon von Seiten der Programmierer lange nix mehr gemacht worden und es ist halt eigentlich "nur" ein Testingtool und kein Crawler wie ich ihn verwenden möchte. Also, to make a long story short ... danke für Deine Antwort und Deine "damals" geposteten Tipps ... finde beide gut und setze die auch, je nach dem wie ich die brauche, ein

cu