Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cookies und der IE8

7 views
Skip to first unread message

Stefan Froehlich

unread,
Feb 1, 2011, 9:06:23 AM2/1/11
to
Heute hat mich ein Kunde mit der Meldung beglueckt, dass er sich in
einer meiner Applikationen nicht anmelden kann. Naeheres
Hinterfragen und Auswerten von Logfiles hat dann gezeigt, dass das
Phaenomen

a) an der voelligen Verweigerung aller mitgeschickten Cookies liegt,
b) nur mit dem IE8 auftritt und
c) erst ab der Sicherheitseinstellung "mittel", die aber dort Policy ist.

Soweit, so schlecht. Nun entstammt das entscheidende Cookie der ganz
normalen PHP-Sessionverwaltung und ist - meiner Meinung nach -
vollkommen unauffaellig. PHP-Version ist 5.2.6, und die
Konfiguration meint zum Thema Session (weitgehend die Defaultwerte):

| [Session]
| session.save_handler = files
| session.use_cookies = 1
| session.name = PHPSESSID
| session.auto_start = 0
| session.cookie_lifetime = 0
| session.cookie_path = /
| session.cookie_domain =
| session.cookie_httponly =
| session.serialize_handler = php
| session.gc_divisor = 100
| session.gc_maxlifetime = 86400
| session.bug_compat_42 = 1
| session.bug_compat_warn = 1
| session.referer_check =
| session.entropy_length = 0
| session.entropy_file =
| session.cache_limiter = private
| session.cache_expire = 180
| session.use_trans_sid = 0
| session.hash_function = 0
| session.hash_bits_per_character = 4

Erzeugt wird das Keks dann schliesslich durch:

| <?php
| $sid = sha1(rand());
| session_name('SID');
| session_id($sid);
| session_start();
| ?>

Man kann sich jetzt sicherlich ueber die Sinnhaftigkeit der
eigenen Erzeugung der SID bzw. des abweichenden Namens unterhalten,
aber fuer das gegenstaendliche Problem ist das wohl ohne Relevanz.
Die Cookies, die ich in meinem Iceweasel erhalte, sehen jedenfalls
genauso harmlos aus, wie es das obige Setup vermuten laess (i.e. die
Domain entspricht dem Hostnamen, die Lebensdauer ist auf die
aktuelle Session beschraenkt).

Die Sicherheitseinstellung "Mittel" unterscheidet sich im fraglichen
IE8 von "Niedrig" (mit der es wunderbar klappt) durch den folgenden
Satz:

| Blocks third-party cookies that save information that can be used
| to contact you without your explicit consent

Das scheint mir alleine schon deshalb fragwuerdig, als es sich beim
Session-Cookie ja nicht um ein third-party cookie handelt. Ich bin
an sich geneigt, die Schuld dem IE8 (oder irgendwelchen spezifischen
Einstellungen der Firmeninstallation) zuzuschieben, nur
funktionieren zum einen diverse andere Seiten problemlos und zum
anderen hilft mir das natuerlich in der Sache selbst nicht weiter.

Was koennte ich auf MEINER Seite noch aendern, um zu einer Loesung
zu kommen?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan: der Grund, den man braucht!
(Sloganizer)

Sam Kang

unread,
Feb 1, 2011, 5:49:46 PM2/1/11
to
Stefan Froehlich schrieb:

> Heute hat mich ein Kunde mit der Meldung beglueckt, dass er sich in
> einer meiner Applikationen nicht anmelden kann. Naeheres
...

> Erzeugt wird das Keks dann schliesslich durch:
>
> | <?php
> | $sid = sha1(rand());
> | session_name('SID');
> | session_id($sid);
> | session_start();
> | ?>

Du erzeugst jedesmal eine neue Session? Mich wundert das da �berhaupt etwas
funktioniert. Etwa Asyncron mit Ajax?

Was soll das denn mal werden?

Sam


--
Sufficiently advanced incompetence is indistinguishable from malice
(J. Porter Clark)

Stefan Froehlich

unread,
Feb 2, 2011, 1:01:58 AM2/2/11
to
On Tue, 01 Feb 2011 23:49:46 Sam Kang wrote:
> > Erzeugt wird das Keks dann schliesslich durch:

> > | <?php
> > | $sid = sha1(rand());
> > | session_name('SID');
> > | session_id($sid);
> > | session_start();
> > | ?>

> Du erzeugst jedesmal eine neue Session?

Hm? Ich erzeuge jedes Mal eine neue Session, wenn eine neue Session
erzeugt wird (soll heissen: das ist nur ein Programmfragment, das nicht
bei jedem Seitenaufruf durchlaufen wird).

> Was soll das denn mal werden?

Ein Cookie halt. Allein, bei diesem einen Kunden wird es nicht gespeichert.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Die Lust zu sein, oder warum Stefan so kalt aalt!
(Sloganizer)

Ulf K@dner

unread,
Feb 2, 2011, 3:25:41 AM2/2/11
to
Am 01.02.2011 15:06, schrieb Stefan Froehlich:
> Heute hat mich ein Kunde mit der Meldung beglueckt, dass er sich in
> einer meiner Applikationen nicht anmelden kann. Naeheres
> Hinterfragen und Auswerten von Logfiles hat dann gezeigt, dass das
> Phaenomen
>
> a) an der voelligen Verweigerung aller mitgeschickten Cookies liegt,
> b) nur mit dem IE8 auftritt und
> c) erst ab der Sicherheitseinstellung "mittel", die aber dort Policy ist.

Nur so als Idee. sende mal einen entsprechenden P3P Header mit der dem
Browser mitteilt was eir mitwelchen Daten angefangen wird. Beim IE7 hat
das immer wunderbar funktioniert. Keine Ahnung ob sich da bei ie8 oder 9
was geändert hat aber ich hab von den Kunden bisher noch keine negativen
Feadbacks das irgendwas nicht wegen Keksen funktioniert.

http://en.wikipedia.org/wiki/P3P

Am einfachsten:

\header( 'P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"' );

MfG, Ulf

Stefan Froehlich

unread,
Feb 2, 2011, 7:05:13 AM2/2/11
to
On Wed, 02 Feb 2011 09:25:41 Ulf K@dner wrote:
> Nur so als Idee. sende mal einen entsprechenden P3P Header mit der
> dem Browser mitteilt was eir mitwelchen Daten angefangen wird.
[...]
> Am einfachsten:
> \header( 'P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"' );

Das hat voellig ausgereicht, danke (interessanterweise ist noch
nie zuvor jemand darueber gestolpert, aber die Sinnhaftigkeit des
ganzen Verfahrens scheint mir ja auch eher zweifelhaft zu sein).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Seeligkeit und Vergnügen. Mit Stefan. Ein listiges Vergnügen!
(Sloganizer)

Ulf K@dner

unread,
Feb 2, 2011, 10:01:06 AM2/2/11
to
Am 02.02.2011 13:05, schrieb Stefan Froehlich:

> Das hat voellig ausgereicht, danke (interessanterweise ist noch
> nie zuvor jemand darueber gestolpert

Doch! Als ich vor 3-4 Jahren ein änhliches Problem mit einem IE (glaube
es war IE6) hatte, habe ich dazu im Web einen Hinweis auf P3P gefunden.
Allerdings nicht als fertiger Header sondern eher sowas in Richtung:

Ich hab von jemanden gehört der kennt einen… der der meinung ist, es
gäbe da eine rätselhafte Bezeichnung P3P unter der man finden kann
wie die Kekse im IE richtig knacken.

Damit wars dann ein leichtes.

Da ich seit dem grundsätzlich diesen Header mitschicke bekomme ich von
evtl. Problemen nix mehr mit und wuste bis eben auch nicht ob neuere IEs
das jetzt anders handhaben.

Allerdings ist das Problem und dessen Erkennung von mehreren
Anforderungen und Gegebenheiten abhängig.

- Besucher muss IE nutzen (Das dessen Nutzerkreis immer weiter zurück
geht sinkt hier auch stetig die Fehlerrate)
- Sitzungskekse müssen notwendig sein.
- Benutzer muss gewillt sein einen Fehler zu melden (hieran hängts wohl
am ehesten)

> aber die Sinnhaftigkeit des
> ganzen Verfahrens scheint mir ja auch eher zweifelhaft zu sein).

Naja. Ist halt so eine "Totgebut" des W3C. Aber da es IE nutzt sollte
man es im Hinterkopf behalten :-x

MfG, Ulf

Stefan Froehlich

unread,
Feb 2, 2011, 10:32:13 AM2/2/11
to
On Wed, 02 Feb 2011 16:01:06 Ulf K@dner wrote:
> > Das hat voellig ausgereicht, danke (interessanterweise ist noch nie
> > zuvor jemand darueber gestolpert

> Doch!

Schon klar :-). Die Aussage bezog sich auf den Nutzerkreis eben jener
Applikation. Und das ist insofern lustig, als:

> - Besucher muss IE nutzen (Das dessen Nutzerkreis immer weiter zurück
> geht sinkt hier auch stetig die Fehlerrate)

...dort ausschliesslich meine Geschaeftskunden und deren Lieferanten
sind, unter denen der IE in Standardkonfiguration ueberproportional
haeufig vertreten ist,

> - Sitzungskekse müssen notwendig sein.

...seit jeher Session Cookies verwendet werden und

> - Benutzer muss gewillt sein einen Fehler zu melden (hieran hängts
> wohl am ehesten)

...Fehler recht zuverlaessig gemeldet werden, da sonst kein Arbeiten
auf den (vorab bezahlten) Seiten moeglich ist.

Insofern bin ich zu 99,5% sicher, dass dieses Problem _hier_ noch
nicht aufgetreten ist, und das erstaunt mich angesichts der Ursache
doch ziemlich. Aber wer weiss schon, welche Einstellungen und
Faktoren da bei Windows und IE noch mit im Spiel sind?

> Naja. Ist halt so eine "Totgebut" des W3C. Aber da es IE nutzt
> sollte man es im Hinterkopf behalten :-x

Ich habe eine entpsrechende Zeile in die zentrale .htaccess-Datei
eingebaut, damit ist das jetzt fuer alle Zeiten erledigt (bzw.
solange, bis wieder jemand eine neue, derartige Idee ausbruetet).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - der Wahn zu pupsen!
(Sloganizer)

Ulf K@dner

unread,
Feb 2, 2011, 11:56:09 AM2/2/11
to
Am 02.02.2011 16:32, schrieb Stefan Froehlich:

> ...dort ausschliesslich meine Geschaeftskunden und deren Lieferanten
> sind, unter denen der IE in Standardkonfiguration ueberproportional
> haeufig vertreten ist,

Naja, dann hat halt jetzt erst ein Admin, für einen oder mehre PC,
Sicherheitsrichtlinien entsprechend angepast. (Ist so keine
Standarteinstellung!) Kurz das Tool von MS aus dem internen Netzwerk
genutzt und Einstellung "optimiert" dauert kein 2 Minuten wenn bereits
irgendwo zu nutzende Richlinien hinterlegt sind. Je nach Firmennetzwerk-
und Client-Struktur geht das sogar von Adminrechner oder
Fernwartungsclient aus z.B. für Clients mit negativ auffälligen
Onlineverhalten oder gar für alle ;-) Aber das geht glaube zu weit, das
jetzt hier auszudiskutieren.

MfG, Ulf

0 new messages