Ich hab folgendes Problem:

Mit der unten angeführten Funktion erzeuge ich eine Session-ID, die
mittels Cookies übergeben wird.

Wenn ich von einer Seite zur nächsten mittels Klick auf einen Link
gehe, wird die Session-ID brav beibehalten. Das funktioniert in jedem
Browser, mit dem ich es bis jetzt getestet habe.

Im Opera und auch im Firefox kann ich einen Reload der Seite
durchführen, und die Session-ID bleibt erhalten.

Wenn ich jedoch im IE6 einen Reload der angezeigten Webseite mache,
wird eine neue Session-ID generiert. Wieso?

Cookies sind im Browser aktiviert. Muß ich im Browser sonst noch was
einstellen?

Komischerweise hab ich auf einem anderen Rechner einen IE6, bei dem
tritt dieses Phänomen nicht auf. Ich hab die beiden IE6 verglichen...
bis auf die letzte Stelle ist die Browser-ID die gleiche. Ich bin
ratlos.

mfg,
Christian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~

function session_secure($errorMessage = 'Access forbidden.') {
// Salt täglich wechseln
$salt = md5(date('d.m.Y'));

[at] session_start();

if (!isset($_SESSION['hash'])) {
$_SESSION['hash'] ="";
}

if (!$_SESSION['hash']) {
// Client Session wurde gerade erst initialisiert
// Neuer Client Hash-Wert wird erzeugt und in den
// Session-Daten gespeichert
$_SESSION['hash'] = md5($_SERVER["REMOTE_ADDR"] .
$_SERVER["HTTP_USER_AGENT"] .
$_SERVER["HTTP_ACCEPT"] . $salt);
} else {
// Alter Hash-Wert ist bereits vorhanden => überprüfen
if ($_SESSION['hash'] != md5($_SERVER["REMOTE_ADDR"] .
$_SERVER["HTTP_USER_AGENT"] .
$_SERVER["HTTP_ACCEPT"] . $salt)) {
//die($errorMessage);
session_secure_end();
header("Location: http://www.mydomain.com/startseite.php");
}
}
}

function session_secure_end() {
$_SESSION = array();

if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
session_destroy();
}

Christian Aigner wrote:

Hallo,

> Wenn ich jedoch im IE6 einen Reload der angezeigten Webseite mache,
> wird eine neue Session-ID generiert. Wieso?

Keine Ahnung. Vielleicht führt was von folgenden zu einen Erfolg:

- Vor header('Location: '); das Speichern der Session-Daten selbst
erledigen -> session_write_close()

session_write_close();
header();
exit;

- Schauen, ob immer ein Cookie gesendet wird -> var_dump($_COOKIES);
- Die Fehlermeldung bei session_start(); nicht unterdrücken und
schauen ob error_reporting(E_ALL) aktiv ist.
- Da header('Location: ') Fehlermeldungen im Browser verdeckt
im Error-Log nachschauen.
- Testweise mal $_SERVER["REMOTE_ADDR"] rausnehmen und anschauen,
ob sich allgemein auch die anderen Parameter nicht ändern.

29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Sch=
utz
gegen eine =DCbernahme der Session?
http://www.php-faq.de/q/q-sessions-ip.html


tschuess
[|8:)
--
PHP: MonthGrid - Einfaches generieren von Kalenderansichten
http://www.sven-drieling.de/diary/2007/08/16/PHP_MonthGrid.h tml

Christian Aigner schrieb:
>
> Wenn ich von einer Seite zur nächsten mittels Klick auf einen Link
> gehe, wird die Session-ID brav beibehalten. Das funktioniert in jedem
> Browser, mit dem ich es bis jetzt getestet habe.

Ist es vielleicht abhängig vom OS?

Hatte vor langer Zeit mal das gleiche Problem. Aber nur unter Win98.
Dort hat der IE6 auch seine Cookies verloren. Unter 2000 und XP bei
sonst gleicher Konfiguration war alles okay.

Peter

Am Wed, 22 Aug 2007 20:51:35 +0200, schrieb Peter Schleif
<gib.spam.keine.chance [at] web.de>:

> Christian Aigner schrieb:
> >
> > Wenn ich von einer Seite zur nächsten mittels Klick auf einen Link
> > gehe, wird die Session-ID brav beibehalten. Das funktioniert in jedem
> > Browser, mit dem ich es bis jetzt getestet habe.
>
> Ist es vielleicht abhängig vom OS?
>
> Hatte vor langer Zeit mal das gleiche Problem. Aber nur unter Win98.
> Dort hat der IE6 auch seine Cookies verloren. Unter 2000 und XP bei
> sonst gleicher Konfiguration war alles okay.
>
> Peter

Ich hab mir jetzt mal das Verzeichnis angesehen, in dem die
Session-Cookies abgelegt werden. Bei jedem Reload verschwindet das
Session-Cookie, und ein neues wird gesetzt.

Kann man dieses Verhalten irgendwie ändern? Komisch ist, daß dieses
Verhalten auf einer IE6-Installation auftritt, bei einer anderen
nicht. Ich kann leider nicht erkennen, worin der Unterschied besteht.
Kann das mit unterschiedlichen Updates zu tun haben?

Christian

Christian Aigner wrote:
>
> Ich hab mir jetzt mal das Verzeichnis angesehen, in dem die
> Session-Cookies abgelegt werden. Bei jedem Reload verschwindet das
> Session-Cookie, und ein neues wird gesetzt.
>
> Kann man dieses Verhalten irgendwie ändern? Komisch ist, daß dieses
> Verhalten auf einer IE6-Installation auftritt, bei einer anderen
> nicht. Ich kann leider nicht erkennen, worin der Unterschied besteht.
> Kann das mit unterschiedlichen Updates zu tun haben?

Ja.
Ich hatte dieses Problem hier bei einer speziellen Seite direkt nach dem
letzten Patchday. Da ich keine saubere Lösung für den Sonderfall
gefunden habe, habe ich dann den Useragent abgefragt und im Falle des IE
die Session-Id an die URL angehangen.
Das ging aber auch nur deshalb, weil die Session in dem Fall keine
wichtigen Daten enthielt.

Ich wäre aber auch an einer sauberen Lösung interessiert.

regards,
Jens

Am Thu, 23 Aug 2007 10:27:19 +0200, schrieb Jens Himmelrath
<usenet [at] zhayad.de>:

> Christian Aigner wrote:
> >
> > Ich hab mir jetzt mal das Verzeichnis angesehen, in dem die
> > Session-Cookies abgelegt werden. Bei jedem Reload verschwindet das
> > Session-Cookie, und ein neues wird gesetzt.
> >
> > Kann man dieses Verhalten irgendwie ändern? Komisch ist, daß dieses
> > Verhalten auf einer IE6-Installation auftritt, bei einer anderen
> > nicht. Ich kann leider nicht erkennen, worin der Unterschied besteht.
> > Kann das mit unterschiedlichen Updates zu tun haben?
>
> Ja.
> Ich hatte dieses Problem hier bei einer speziellen Seite direkt nach dem
> letzten Patchday. Da ich keine saubere Lösung für den Sonderfall
> gefunden habe, habe ich dann den Useragent abgefragt und im Falle des IE
> die Session-Id an die URL angehangen.
> Das ging aber auch nur deshalb, weil die Session in dem Fall keine
> wichtigen Daten enthielt.
>
> Ich wäre aber auch an einer sauberen Lösung interessiert.
>
> regards,
> Jens

Ich hab jetzt mal mittels

echo $_SERVER["HTTP_USER_AGENT"];

angesehen, was der Browser so als Kennung von sich gibt.

Bei dem Browser, wo ich das Problem habe, kam das raus:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
Mozilla/4.0(Compatible Mozilla/4.0(Compatible-EmbeddedWB 14.59
http://bsalsa.com/ EmbeddedWB- 14.59 from: http://bsalsa.com/ ; .NET
CLR 1.1.4322; .NET CLR 2.0.50727)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Beim anderen Browser, wo ich das Problem nicht habe, kam das raus:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1;
..NET CLR 2.0.50727)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Kann mir bitte wer erklären, was ich da sehe?

LG,
Christian

Christian Aigner wrote:

> Kann mir bitte wer erklären, was ich da sehe?

Das das "Embedded Web Browser package" von
http://bsalsa.com/product.html fehlerhaft ist? ;-)

--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!

Christian Aigner schrieb:

> Wenn ich jedoch im IE6 einen Reload der angezeigten Webseite mache,
> wird eine neue Session-ID generiert. Wieso?

Das kann ja gar nicht sein, weil der Browser das Sessionhandling nicht
steuert, sondern php, bzw. das Programm.

Vermutlich gibt es da einfach ein Problem mit den Cookies.

Martin

Am Sun, 26 Aug 2007 23:38:33 +0200, schrieb Martin Lemke
<usenet [at] maaaddin.de>:

> Christian Aigner schrieb:
>
> > Wenn ich jedoch im IE6 einen Reload der angezeigten Webseite mache,
> > wird eine neue Session-ID generiert. Wieso?
>
> Das kann ja gar nicht sein, weil der Browser das Sessionhandling nicht
> steuert, sondern php, bzw. das Programm.
>
> Vermutlich gibt es da einfach ein Problem mit den Cookies.
>
> Martin

Ja, es scheint ein Cookie-Problem zu sein. Bei jedem Reload löscht der
Browser das Cookie und legt ein neues an. Aber wieso tut er das?

Wenn ich von Seite zu Seite navigiere behält er das Session-Cookie und
alles funktioniert tadellos.

LG,
Christian

Christian Aigner wrote:

Hallo,

> Ja, es scheint ein Cookie-Problem zu sein. Bei jedem Reload löscht =
der
> Browser das Cookie und legt ein neues an. Aber wieso tut er das?

Auch schon bei einem minimalen Beispiel oder erst beim
Redirect mit header("Location:")?

<?php
session_start();

echo "<pre>";
var_dump($_COOKIE);
echo "</pre>";

if(!isset($_SESSION['count']))
{
$_SESSION['count'] =3D 0;
}

echo "Count: {$_SESSION['count']}";
$_SESSION['count']++;
?>


Vielleicht ändert sich durchs Redirect der Pfad oder die
Subdomain. Das lässt sich über _path und _domain regulieren.

session.cookie_path
session.cookie_domain



Eventuell sind auf dem Rechner auch Sicherheitsprogramme aktiv,
die das Cookie-Handling beeinflussen.


tschuess
[|8:)

[Mon, 27 Aug 2007 10:03:36 +0200|Christian Aigner]
> Am Sun, 26 Aug 2007 23:38:33 +0200, schrieb Martin Lemke
> <usenet [at] maaaddin.de>:
>
> > Christian Aigner schrieb:
> >
> > > Wenn ich jedoch im IE6 einen Reload der angezeigten Webseite mache,
> > > wird eine neue Session-ID generiert. Wieso?
> >
> > Das kann ja gar nicht sein, weil der Browser das Sessionhandling nicht
> > steuert, sondern php, bzw. das Programm.
> >
> > Vermutlich gibt es da einfach ein Problem mit den Cookies.
> >
> > Martin
>
> Ja, es scheint ein Cookie-Problem zu sein. Bei jedem Reload löscht der
> Browser das Cookie und legt ein neues an. Aber wieso tut er das?

Das Problem ist Dein Plugin.

-->
Bei dem Browser, wo ich das Problem habe, kam das raus:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
Mozilla/4.0(Compatible Mozilla/4.0(Compatible-EmbeddedWB 14.59
http://bsalsa.com/ EmbeddedWB- 14.59 from: http://
<--

Zwei User-Agents greifen auf die selbe Seite mit der selben
Session-ID im Cookie zu.

-->
if (!$_SESSION['hash']) {
// Client Session wurde gerade erst initialisiert
// Neuer Client Hash-Wert wird erzeugt und in den
// Session-Daten gespeichert
$_SESSION['hash'] = md5($_SERVER["REMOTE_ADDR"] .
$_SERVER["HTTP_USER_AGENT"] .
$_SERVER["HTTP_ACCEPT"] . $salt);
} else {
// Alter Hash-Wert ist bereits vorhanden => überprüfen
if ($_SESSION['hash'] != md5($_SERVER["REMOTE_ADDR"] .
$_SERVER["HTTP_USER_AGENT"] .
$_SERVER["HTTP_ACCEPT"] . $salt)) {
//die($errorMessage);
session_secure_end();

Das Plugin erzwingt einen neuen Hash, der mit dem alten nicht mehr
übereinstimmt, da sich der User-Agent ändert.

Den User-Agent in einen Hash zu packen, halte ich nur dann für
sinnvoll, wenn gleichermassen Suchmaschinen-Bots gefiltert werden.
Sonst könnten die im Falle von NoCookies => UseTransid mit einem
anderen UA auf die gleiche Session zugreifen, was zum Löschen
derselben führt, weil die Hash-Prüfung scheitert. Oder Cookies
erzwingen.


grüsse
michael

[Mon, 27 Aug 2007 14:04:53 +0200|Michael Weber]
> Das Problem ist Dein Plugin.
>
> -->
> Bei dem Browser, wo ich das Problem habe, kam das raus:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
> Mozilla/4.0(Compatible Mozilla/4.0(Compatible-EmbeddedWB 14.59
> http://bsalsa.com/ EmbeddedWB- 14.59 from: http://
> <--

Aber wie ich grad sehe, ist der UA kaputt? Es fehlen die
schliessenden Klammern.
<46cd51fa$0$16112$9b4e6d93 [at] newsspool1.arcor-online.net>

> Wenn ich von Seite zu Seite navigiere behält er das Session-Cookie und
> alles funktioniert tadellos.

Vielleicht holt das Plugin die Seiten aus dem Cache und fordert nur
beim Reload was beim Server an.


grüsse
michael

Am Mon, 27 Aug 2007 14:04:53 +0200, schrieb Michael Weber
<webster [at] kaffeeschluerfer.com>:

> Das Problem ist Dein Plugin.
>
> Zwei User-Agents greifen auf die selbe Seite mit der selben
> Session-ID im Cookie zu.
>
> Das Plugin erzwingt einen neuen Hash, der mit dem alten nicht mehr
> übereinstimmt, da sich der User-Agent ändert.

Hallo Michael!

Vielen Dank. Das ist die Lösung gewesen. Ich hab jetzt den UA aus der
Hash-Berechnung rausgenommen, und nun geht es.

Ich wäre da nie drauf gekommen.

Jetzt frag ich mich nur noch, wie ich diesen zweiten UA wieder aus
meinem Browser rausbekomme. Ich hab den nicht selber installiert. Der
war schon auf dem Rechner, als ich den Arbeitsplatz übernommen habe.

mfg,
Christian

[Wed, 29 Aug 2007 13:52:52 +0200|Christian Aigner]
> Am Mon, 27 Aug 2007 14:04:53 +0200, schrieb Michael Weber
> <webster [at] kaffeeschluerfer.com>:
>
> > Das Problem ist Dein Plugin.
> >
> > Zwei User-Agents greifen auf die selbe Seite mit der selben
> > Session-ID im Cookie zu.
> >
> > Das Plugin erzwingt einen neuen Hash, der mit dem alten nicht mehr
> > übereinstimmt, da sich der User-Agent ändert.
>
> Hallo Michael!
>
> Vielen Dank. Das ist die Lösung gewesen. Ich hab jetzt den UA aus der
> Hash-Berechnung rausgenommen, und nun geht es.
>
> Ich wäre da nie drauf gekommen.
>
> Jetzt frag ich mich nur noch, wie ich diesen zweiten UA wieder aus
> meinem Browser rausbekomme. Ich hab den nicht selber installiert. Der
> war schon auf dem Rechner, als ich den Arbeitsplatz übernommen habe.

Du könntest versuchen, den User-Agent zu filtern und die Anfragen
des Plugins direkt per exit() ins Jenseits zu befördern. Die UA-
Prüfung müsste dann aber schon geschehen, bevor die Session
gestartet wird. Dann könnte der UA im Hash bleiben. Hilfreich (auch
für andere Sachen) könnte da sein, eine Info-Mitteilung auf den
Schirm zu printen, wenn zwei verschiedene Hashs auf die selbe
Session zeigen. Dann kannste nachgrasen und gucken, wer da
reinfunkt. Und ggf. filtern. Meine häufigsten Erkenntnisse sind
#(bot|slurp|crawling|neomo|yahoo|google|phyton|findlinks|met acrawler)#i

Gibts unter "AddOns verwalten" im IE keine Hinweise auf das
Plugin? Deaktivieren?


grüsse
michael

Ingrid...
[Wed, 29 Aug 2007 15:48:01 +0200|Michael Weber]
> Du könntest versuchen, den User-Agent zu filtern und die Anfragen
> des Plugins direkt per exit() ins Jenseits zu befördern.

Ärks, allerdings nix gut bei Suchmaschinen, wenn die Seite gefunden
werdn will. Wenn die (erkannten) Bots mit ner ID ankommen, nur dann
praktikabel.


grüsse
michael