merkwürdiges Phänomen

**penizillin** · 23.04.2007, 13:35

hat wohl irgendwas mit sessions zu tun. was genau - wirst du selbst herausfinden müssen.

**jonas01** · 23.04.2007, 13:37

Würde eine FIrewall das Senden des Cookies vom Benutzer zum Server evtl. unterbinden können?

**penizillin** · 23.04.2007, 13:39

solange sie beim benutzer installiert ist - ja. aber sie wird es nicht tun. bei cookies wird die akzeptanz verweigert, nicht das "versenden".

**frankburian** · 23.04.2007, 13:51

ich hab sowas mal bei www.triff-chemnitz.de gesehen. da hatte es irgendwas mit der datenbank zu tun. das ist immer frühs aufgetreten.

Das Anmeldeproblem früh morgens ist identifiziert. Es handelt sich um eine Berechnung auf der Datenbank, welche die Verteilung eine zeitlang asynchron werden läßt. Diese ist ab sofort erstmal deaktiviert.

vielleicht mal in die richtung schauen!

**jonas01** · 23.04.2007, 14:20

OK...

Ich habe das mit einem sehr geduldigen Mitglied verfolgen können...

Er hat sich bei mir eingloggt -> Cookie wurde gesetzt (Er hat das mit dem Cookie Manager des Firefox Browsers geprüft).
Beim nächsten Klick kam erneut die Aufforderung, er müsse sich einloggen.
Das Cookie war aber laut FF Browser noch vorhanden.
Also schließe ich daraus: Das Cookie bzw. dessen Inhalt konnte von unserem Server nicht gelesen werden.

Oder sehe ich das falsch?

**penizillin** · 23.04.2007, 14:23

nicht "vom server gelesen", sonder "vom client verschickt".
schau dir die übertragenen http headers an (und zeige sie vielleicht hier).

**jonas01** · 23.04.2007, 15:04

Uh...

ich glaube, ich habe das Problem soeben gefunden...
Und zwar wird ein User (wenn er denn dann eingeloggt ist) als "eingeloggter" User in eine MySQL Tabelle geschrieben.

Dabei werden User Name, IP, user_agent und PHPSESSID eingetragen.

Wenn ich den user_agent eintrage mache ich das brav mit einem addslashes($USER_AGENT);

Wenn ich aber nach dem Login den USER_AGENT aus der DB auslese und ihn mit dem USER_AGENT des users vergleiche, fehlte das "stripslashes();"
Das fällt ja nicht bei jedem ins Gewicht, sorgt aber bei einigen dafür, dass das als != erkannt wird, und der User fliegt raus.

Das sollte es evtl. gewesen sein....

**tontechniker** · 23.04.2007, 20:56

ich hab sowas mal bei www.triff-chemnitz.de gesehen

OffTopic:
interessant ... die Seite wird weder im Firefox noch im Internet Explorer richtig dargestellt ...

Du solltest vielleicht einfach die Logins mitloggen dann siehst du ja wer sich nach kurzer Zeit immer wieder einloggt und kannst damit auf den Fehler schließen ... nur mal für die Zukunft.

**TobiaZ** · 23.04.2007, 21:17

Wenn ich aber nach dem Login den USER_AGENT aus der DB auslese und ihn mit dem USER_AGENT des users vergleiche, fehlte das "stripslashes();"

Ähm, du weißt aber schon, dass die slashes in der DB nichts zu suchen haben???

**closure** · 24.04.2007, 08:32

Original geschrieben von TobiaZ
Ähm, du weißt aber schon, dass die slashes in der DB nichts zu suchen haben???

Und warum nicht?

greets

**TobiaZ** · 24.04.2007, 09:02

gegenfrage: Warum sollte man sie darin speichern. Du speicherst auch keine zusätzlichen @s oder Gs oder = oder sonst was darin.

**closure** · 24.04.2007, 11:09

Original geschrieben von TobiaZ
gegenfrage: Warum sollte man sie darin speichern. Du speicherst auch keine zusätzlichen @s oder Gs oder = oder sonst was darin.

Nein zusätzliche nicht, aber wenn sie zum beispiel zu textdaten
gehören, dann nehm ich sie doch nicht da raus.

greets

**tontechniker** · 24.04.2007, 16:01

Nein es geht ja auch um die "escapenden" Slashes.

**jonas01** · 26.04.2007, 11:38

Original geschrieben von TobiaZ
Ähm, du weißt aber schon, dass die slashes in der DB nichts zu suchen haben???

Auch auf die Gefahr hin, dass wir gerade aneinander vorbeireden....

Wenn ich den Wert 'sdksdfklklsdfkjlkmnvn"ydkfkjf"djdjdjdj' in eine DB schreiben will, komme ich wohl nicht um ein addslashes(); drumrum, oder?

Da der Inhalt der Variable $USER_AGENT einen Wert mit einem " haben kann (in diesen Fällen war das auch so) sollte ich wohl addslashes(); benutzen.

Lese ich dann den Wert, muss ich natürlich stripslashes(); nutzen, da sonst das Vergleichen natürlich fehlschlägt.

Da es nun 100% funktioniert war der Fehler auch dort zu suchen.

merkwürdiges Phänomen