Moin!

Wir haben hier leider ein sehr akutes Problem bei der Umstellung auf den IE8. Eine Diskussion über die Umstände und Rahmenbedingungen können wir uns sparen, es ist genau so, wie es ist, darauf habe ich praktisch kaum Einfluss.

Wir haben hier Webanwendungen, die über einen WebSphere-Server bereitgestellt wird. Dort laufen zwei Anwendungen, die leider den gleichen Cookienamen verwenden, um ihre Session zu tracken. Tja, so ist das, wenn der Hersteller beim Erweitern der Anwendung schlampt und das nicht richtig angepasst hat. Nja, was soll´s, der Hersteller ist informiert, aber bis da was kommt, kann das noch dauern. Das "Problem" liegt also eigentlich nicht am IE, sondern in der dämlichen Anwendung, aber das kann ich jetzt auch nicht ändern.

Beim IE6 konnten wir das Problem mit einem Workaround unkritisch machen: einfach per CMD-Script eine IE(6)-Instanz mit passenden Parametern für jede Anwendung gestartet, und gut war´s. Dann sind sich die Caches nicht ins Gehege gekommen, obwohl der Cookie den gleichen Namen hat.

Hier mal die beiden 1-Zeiler-Scripte, jeweils in einer separaten CMD:

Seit heute haben wir aber den IE8 im Einsatz und hier zieht der Trick nicht mehr. Obwohl ich mehrere IExplore-Prozesse habe, scheint der Cache doch wieder gemeinsam genutzt zu sein, denn jetzt macht man sich mit der Anmeldung an der einen Anwendung die Sitzung in der anderen wieder kaputt...

Kennt jemand einen Trick, wie ich dem IE8 wieder beibringen kann, Cookies vom gleichen Host (aber unterschiedlichen Ports/Verzeichnissen) mit gleichem Namen getrennt zu behandeln? Offensichtlich klappt´s mit unterschiedlichen Instanzen nicht mehr...

cu
Narses

ich nehm an einen 2. benutzer anlegen und den Prozess unter dem Benutzer ausführen zu lassen geht auch nicht, oder? Weil der cache liegt ja eig. immer im %Appdata%-Verzeichnis vom jeweiligen benutzer.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

Richtig wäre, im Cookie-Header ein Verzeichnis mit zu setzen. Diese Firma hat also maximal verkackt und wäre in meinen Augen verpflichtet, das bis gestern gefixt zu haben. IE6 ist jetzt seit >3 Monaten offiziell als "do not use" gekennzeichnet, das reicht ja wohl.

Und dann ist der auch nur da lesbar. Wie sonst würden sich die ganzen Anwendungen verstehen, die nur PHPSESSID als Cookienamen haben...

Alternativ zu elundril wäre auch der Private Mode über den Schalter -private eine Idee, aber da weiß ich nicht wie der sich mit bereits bestehenden Keksen verhält.

Moin!

elundril hat folgendes geschrieben :

ich nehm an einen 2. benutzer anlegen und den Prozess unter dem Benutzer ausführen zu lassen geht auch nicht, oder?

Ginge schon, aber der andere User-Kontext wirft leider noch viel größere Probleme auf, als die nicht laufende Anwendung. Ich weiß zugegeben aber auch nicht auswendig, ob und ggfs. wohin der Cache vielleicht noch verbogen ist, könnte also nichtmal eine Lösung sein. Aber danke für´s Mitdenken.

Martok hat folgendes geschrieben :

Richtig wäre, im Cookie-Header ein Verzeichnis mit zu setzen. Diese Firma hat also maximal verkackt

Diese Firma hat sogar endmaximal verkackt, wir sind auch gerade dabei, diese Firma bei uns abzuschaffen - und jetzt darfst du mal raten, warum die nicht gerade hochmotiviert sind, das schnell zu fixen (doof sind se also auch noch obendrein! )...

Martok hat folgendes geschrieben :

IE6 ist jetzt seit >3 Monaten offiziell als "do not use" gekennzeichnet, das reicht ja wohl.

Die IE-Bedingung kommt auch nicht von denen, das ist Rahmenbedingung bei uns im Netz (lass uns das nicht auswalzen, bringt nix... ).

Martok hat folgendes geschrieben :

markieren Quelltext     1: Set-Cookie: name=dadf47f23b6135a622e89bcfe986e6e5; expires=Thu, 02-Sep-2010 12:57:23 GMT; path=/some/path/ Und dann ist der auch nur da lesbar. Wie sonst würden sich die ganzen Anwendungen verstehen, die nur PHPSESSID als Cookienamen haben...

No comment, ich schüttle da überhaupt schon seit Jahren nur noch den Kopf, mir ist schon ganz schlecht davon...

Martok hat folgendes geschrieben :

Alternativ zu elundril wäre auch der Private Mode über den Schalter -private eine Idee, aber da weiß ich nicht wie der sich mit bereits bestehenden Keksen verhält.

Hmm, ist evtl. ne Idee, ich teste das mal morgen.

Habe jetzt, um die Kuh vom Eis zu kriegen, einen Firefox Portable auf die paar entscheidenden Maschinen gepackt. Ist zwar "verboten", aber dass die Anwendungen nicht laufen, ist noch "verbotener", also als Workaround gerade geduldet. Jetzt läuft die eine Anwendung im IE und die andere im FF, nicht schön, aber geht. Was das Ganze administrativ so zum Kotzen macht, ist, dass die 2. Anwendung praktisch nur in den ersten Tagen eines Monats sehr intensiv genutzt wird, den Rest des Monats dümpelt das Ding so vor sich hin... tja, schau mal auf den Kalender... aahhhhh...

Danke für die Vorschläge, wir werden sehen, was der morgige Tag so bringt...

cu
Narses

Narses hat folgendes geschrieben :

Die IE-Bedingung kommt auch nicht von denen, das ist Rahmenbedingung bei uns im Netz (lass uns das nicht auswalzen, bringt nix... ).

Och, IE an sich ist ja nicht mal das Problem. ActiveX kann manchmal ganz praktisch sein (SAP afair).
Was mich extremst ank***t sind diese Softwarebuden, die uns ehrliche Webdesigner ( ) dazu zwingen, in IE6 zumindest noch bedienbare Seite zu erzeugen, nur weil sie die Firmen auf ein 10 Jaher altes Produkt festnageln. Privathaushalte haben das Teil ja kaum noch, wurde ja schon lange rausgewindowsupdated.
Sowas ist ein Produktmangel und gehört in meinen Augen gefixt. Oder der entlassen, der ein Pflichtenheft geschrieben hat, dass sowas zulässt...

Whatever. Was sind das für Apps? Wenn gar nichts hilft, kann man das ja vielleicht Firmenintern lösen. Wie gesagt: Cookie Path setzen statt path=/ würde ja reichen.

Dabei fällt mir aber was ein. Der Server könnte einen DNS Hostnamen announcen. Einen pro App, dann sehen die sich auch nicht mehr...

Moin!

Martok hat folgendes geschrieben :

Whatever. Was sind das für Apps? Wenn gar nichts hilft, kann man das ja vielleicht Firmenintern lösen. Wie gesagt: Cookie Path setzen statt path=/ würde ja reichen.

Hab da heute morgen nochmal angerufen und in wenig diplomatischen Worten (naja, also eigentlich nur noch in Worten, ganz ohne Verpackung ) kund getan, wie ich mir die Schadensersatzforderung vorstelle, die ich jetzt gleich stellen werde. Kurz drauf hat dann doch jemand entschieden, mit mir in dieser ekeligen WebSphere-Administration zu versuchen, den Cookienamen zu ändern (was augenscheinlich auch geklappt hat, sehen wir aber erst morgen nach dem nächtlichen Reboot). Cookie-Pfad wäre hier keine Option, da die 2. Anwendung nur auf einem anderen Port, aber mit gleicher http-VZ-Struktur hantiert.

Martok hat folgendes geschrieben :

Dabei fällt mir aber was ein. Der Server könnte einen DNS Hostnamen announcen. Einen pro App, dann sehen die sich auch nicht mehr...

Aua, das muss man mir sagen, wie peinlich... Na klar, einfach einen DNS-Alias und gut wär´s gewesen... *seufz* Sag das doch gleich.

Ich habe aber auch heute die Lösung gefunden, die mir eigentlich vorgeschwebt hat: mit dem Parameter "-nomerge" kann man dem IE beim Start den Wunsch mitgeben, eine separate Session zu öffnen (genau so, wie mit dem Menüpunkt "Neue Session"). Tja, das hatte ich gesucht!

Danke nochmal für´s Mitdenken!

cu
Narses

Auch wenn's inzwischen bereits behoben ist, würde mir noch einfallen: Schalt jeweils nen transparenten App-Proxy davor und rewrite dort die Cookie-Namen in Richtung Brause.

Aber gut, die anderen Lösungen sind die wesentlich besseren in der Situation; insbesondere die Nutzung mehrerer VHosts.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.