HTTP JSESSIONID in Http(s)URLConnection loswerden!

[Benutzer 08/15]

Hallo,

wir setzen bei uns neuerdings i-net Clear Reports als Reportgenerator ein. Der Client kommuniziert per HTTP mit dem Reportserver (steht bei uns im Intranet).
Scheinbar wird dort irgendwie eine Session erzeugt.
Das Problem ist, wenn wir nun danach selber eine Http(s)URLConnection zu einem Server im Internet aufbauen wird die erzeugte SessionID (JSESSIONID) als Cookie mit übertragen.

Es liegt definitiv an dem vorherigen Verbinden mit dem Reportserver.

Leider stört die JSESSIONID vollends die Kommunikation mit dem externen Server, da der jede Anfrage mit falsch abtut.

Nun die Frage: Wie verhindern wir, das dieses blöde Cookie mit an den externen Server gesendet wird?

DANKE!

 

[nillehammer]

Scheinbar kopierst Du die Header der http-Connection zu Eurem ReportingServer in die https-Connection zum Internetserver. Poste bitte den Code, damit man schauen kann, wo.

 

[Benutzer 08/15]

Soll ich das wirklich machen?!

URL url = new URL("https://domain.tld");
HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
con.setRequestMethod("GET");
con.connect();
BufferedReader reader = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line = null;
while ((line = reader.readLine()) != null) {
	System.out.println("!" + line + "\n");
}
con.disconnect();

Glaub mir einfach: Wir kopieren nichts! Irgendwie setzen die von i-net Defaultwerte, aber wir wissen nicht, wie man diese wieder rausbekommt!

 

[nillehammer]

Nu mal nicht so schnippisch. Es ist ja wohl nicht zuviel verlangt, Source Code zu sehen, um eventuelle Fehler in meiner Umgebung nachvollziehen zu können.

Ich habe jetzt verschiedene Varianten ausprobiert. Erst eine http-Url aufrufen, wo ich weiß, dass im Response ein JSESSIONID-Cookie gesetzt wird. Danach eine https-Url, bei der kein Cookie verwendet wird. Das hat funktioniert. Weil ich bei der https-Connection nicht in den Datenstrom reingucken kann, hab ich danach nochmal eine normale http-Connection ausprobiert und mit Wireshark in die Pakete angeschaut. Das Cookie aus der ersten Connection wird beim Request der zweiten nicht mitgesendet.

Weiterhin viel Erfolg bei der Fehlersuche wünscht,
nillehammer

 

[Benutzer 08/15]

Sorry erstmal,

ist nichts gegen dich persönlich, aber es ist nunmal so, das unsereins erstmal ausgiebig selber recherchiert und untersucht, bevor er eine Frage in einem Forum stellt. Und falls es dann zu einer Beantwortung dieser kommen kommen sollte, werden meistens irgendwelche Trivialitäten abgeprüft oder vorgeschlagen.

Wie schon geschrieben, das Problem ist, das der Cookie irgendwie permanen für alle Http(s)URLConnection gespeichert ist und ich ihn nicht wieder losbekomme.
Also ist die Frage, weiß einer, wo das "Mistding" noch hängen kann, oder nicht?

Danke!

 

[areafo]

Cookie. was für eine Art? Https Streams während der Laufzeit zu beeinflussen naja Secure by Design ^^

Stichworte bei Wikipedia wären:
http cookie
Cross-Site-Cooking
Logdateianalyse
DOM Storage
Flash-Cookie

Warum es an allen nachfolgenden Stream dran hängt wäre zu klären. Sowas ist nicht "normal" und muss ein gewolltes und wahrscheinlich nicht abänderbares Design Problem des Reportgenerator sein. Wenn die mit Sessions arbeiten, dann ist das so designed.

Ürsprüngliche Spezifikation von Netscape sah vor

You can manipulate cookies:

Explicitly, with a CGI program.

Programmatically, with client-side JavaScript using the cookie property of the document object.

Transparently, with the server-side JavaScript using the client object, when using client-cookie maintenance.

 

[Benutzer 08/15]

Warum es an allen nachfolgenden Stream dran hängt wäre zu klären. Sowas ist nicht "normal" und muss ein gewolltes und wahrscheinlich nicht abänderbares Design Problem des Reportgenerator sein. Wenn die mit Sessions arbeiten, dann ist das so designed.

Treffer, genau das ist ja die Kernaussage. Wobei bei dem "nicht abänderbaren Designproblem" würde ich nicht zustimmen. Ich habe mal jetzt dem Support bei denen geschrieben. Mal schauen, was ich da abklären kann.

Aber wie schon geschrieben, das Problem ist, dass jede Http(s)URLConnection (Clientseitig) egal wohin, diesen blöden Cookie mitsendet!

 

[areafo]

Was ich nicht verstehe. Wird die Connection nach der Report Session immer weiterverwendet? Laufen normale Verbindungen somit auch über den Reportserver weil er gleichzeitig eine Art Proxy ist, anders könnte ein Coookie nicht in eine https Session "eindringen".

 

[Benutzer 08/15]

Nein, sie wird nicht weiterverwendet.

Wir wissen nicht genau, wie die Kommunikation mit dem Reportserver abläuft. Ist ja properitär. Die Vermutung liegt nahe, dass da auch eine HttpURLConnection verwendet wird, da wir eine URL an die clientseitige Komponente übergeben müssen.
Und danach rufen wir den Code von oben auf. Und ab dann wird immer ein Cookie mitgeschickt!
Es ist fast so, als würde die Clientkomponente von i-Net setDefaultRequestProperty ("Cookie", "JSESSIONID=abcde123;") aufrufen. Laut API ist das natürlich nicht möglich!
Man kann es Programmtechnisch auch nirgendwo abfragen, aber es wird definitiv mitgeschickt!

 

[areafo]

Das lässt nur einen Schluss zu (was sehr unsauber ist).Der Reportserver scheint mit seinen clientseitigen Komponenten einfach (weil bequemer) eben diese JVM weiten Defaultwerte zu setzen. Da wollte eben jemand Programmzeilen sparen ^^

Genau der selbe Schluss wie bereits in dem Post über mir vom Ersteller

Also vor neuer Verbindung erst Global reset default ^^

Abfragen über getDefaultRequestProperty vor neuer Con ^^

 

[Benutzer 08/15]

Das lässt nur einen Schluss zu (was sehr unsauber ist).Der Reportserver scheint mit seinen clientseitigen Komponenten einfach (weil bequemer) eben diese JVM weiten Defaultwerte zu setzen. Da wollte eben jemand Programmzeilen sparen ^^

Ja, ist bekannt! Unbekannt ist, wie haben Sie die Programmzeilen gespart?! Also wie bringt man diese Defaultwerte überhaupt rein ins System?!

Also vor neuer Verbindung erst Global reset default ^^

Genau das ist meine Frage! Wie macht man diesen "Global reset default"?! (Ohne die JVM neu zu starten!)

 

[areafo]

Wie die Zeilen gespart haben ^^. Ganz klar so:

Vor jeder Verbindung müsste man die passenden Werte setzen, wenn das immer die selben sind setzt man Sie global (für die gesamt JVM-Session). Will man diese bereinigen startet man die JVM neu oder setzt die Werte auf Nothing und bereinigt diese auf Standard.

 

[Benutzer 08/15]

Wie die Zeilen gespart haben ^^. Ganz klar so:

Vor jeder Verbindung müsste man die passenden Werte setzen, wenn das immer die selben sind setzt man Sie global (für die gesamt JVM-Session). Will man diese bereinigen startet man die JVM neu oder setzt die Werte auf Nothing und bereinigt diese auf Standard.

Entschuldige, aber du weißt schon, dass die Antworten irgendwie null (neuen) Informationsgehalt haben, oder?!

Aber egal, wir haben gerade einen Fix für das Problem von i-net bekommen. Und es funktioniert.
Weiterhin hat mein Kollege noch etwas recherchiert und hat auch die Antwort auf unsere ursprüngliche Frage gefunden! Sie heißt:

CookieManager.setDefault(null);

(siehe API)
So einfach, wenn man es denn weiß!

Ich habe an den i-net Support nochmal die Rückfrage gestellt, ob es denn daran gelegen haben könnte! Wobei wir zu 99% sicher sind das ja!

Also für mich/uns ist die Frage damit beantwortet: Bei Cookieproblemen die neuen Cookie-Klassen ab Version 1.6 beachten!

DANKE nochmal.

 

[areafo]

Die API hab ich mir nie angeschaut ^^. Es war ja klar das die Clientseitigen Reportserver Komponenten schuld haben. Das die API da sogar eine Manager Klasse bereitstellt wunderbar, ansonsten hätte man das wie gesagt selbst implementiert, so dass die JVM Einstellungen wieder "genullt" werden.

Danke auch das du die Lösung gepostet hast.