PROVIDERPROBLEM? Nach Einloggen immer ausgeloggt, Reload jeder Seite nötig, Cache aktiv

Liegt das an Drupal oder vielleicht doch auch am Webserver?

Hast Du vielleicht ne andere BASE URL in der settings.php eingetragen?

--------------------
Design Probleme einfach mit FF und FIREBUG lösen!

Ich habe keine base_url angegeben. Es ist ein Multi-Site Projekt mit mehreren Domains, jeweils anderer Content (bzw. auch Subdomain).

Aber wie könnte sich die base_url da auswirken?

Der wichtigste Punkte bei der ganzen Sache: Macht man ein Reload im Browser (CTRL R), dann ist der korrekte Content da (also eingeloggte Content nach dem Einloggen) und man muss manchmal bei allen Seiten extra ein Reload machen ...

Ich hatte das schon mal wenn ich mit verschiedenen Browserfenstern und dem gleichen User gearbeitet habe...

Hast du das Problem mit verschiedenen Browsern?
Hast du schon versucht alle Cookies zu löschen und dich dann neu anzumelden?
Ist Browser-Cache aktiv oder tritt das auch bei deaktiviertem Browser-Cache auf?

-----------
Kooperative Netze Hamburg

Ich habe jetzt im Google Chrome (den mit großem Abstand besten Browser der Welt) den Cache geleert.

Bei einer Seite (ohne Drupal Cache) trat das Problem jetzt nicht mehr auf.

Bei einer anderen Seite (mit aktiviertem Drupal Cache) war ich soeben ausgeloggt auf der Startseite obwohl ich gerade vorher einloggte und nach einem Reload auch tatsächlich eingeloggt war. Tritt also zusammen mit Drupal Cache trotz geleertem Browser Cache auf.

Und die Cookies?
Hast du vielleicht auf deiner Seite irgendwas zum Thema Session geändert?
-----------
Kooperative Netze Hamburg

Nicht das ich wüsste.

Jetzt ein weiteres Beispiel:

Gestern habe ich mit CSS (display:none) die meta-Zeile (Verfasst von ...) versteckt (nur im Teaser, nicht im Node, daher mit CSS realisiert).

Heute rufe ich die Seite auf, und die Zeile "Verfasst von .." ist wieder da, obwohl gestern nach dem Reload das natürlich versteckt war.

Dann habe ich unter "Einstellungen" - "Leistung" den Cache geleert. Der Cache ist deaktiviert mit Aunahme der Seitenkompression, die ist anscheinend standardmäßig aktiviert.

Nach dem leeren des Caches klicke ich nochmal auf meinen Hauptmenüpunkt OHNE ein Reload zu machen und die Zeile ist weg. Es hängt also mit dem Cache zusammen.

Was ist die Seitenkompression und warum ist die aktiviert von sich aus?

Warum merkt sich der Browser oder Drupal nicht den korrekten Zustand einer Seite, wenn man doch schon gestern mit einem oder mehrfachen Reload die css-Datei eingelesen hat und auch alles korrekt war (meta-Zeile nicht mehr da) und einige Zeit später verwendet Drupal (oder der Brower, wer weiß) wieder die alte csss-Datei????

Was ist hier los?
Merci.

Ich habe das Problem auf diesem einem Server noch immer und nur auf diesem Server.

Habe das jetzt mit 3 Browsern getestet, es tritt mit allen auf.

Folgende Zusammenfassung:
- zuerst habe ich entwickelt und entwickelt, der Drupal Cache war die ganze Zeit ausgeschaltet ---> kein Problem beim Ein- und Ausloggen.
- endlich fertig: Drupal Cache eingeschaltet
- klicke auf einen Hauptmenüpunkt ---> bin auf der Seite dieses Menüpunkts ausgeloggt.
- klicke auf den nächsten Hauptemenüpunkt --> bin auch auf dieser Seite ausgeloggt
- mache ein Reload (STRG + R, im Browser die Seite neu laden) ---> bin eingeloggt auf dieser Einzelseite und bleibe eingeloggt auf dieser Seite
- um jetzt alle Seiten aller Menüpunkte eingeloggt zu sehen, muss ich bei jeder einzelnen Einzelseite ein Reload im Browser machen
- danach bleiben all diese Seiten eingeloggt bis zum nächsten Ausloggen ....

Das ist sehr ärgerlich.
Es muss am Webserver liegen, so ein Phänomen hatte ich auf keinem anderen Server.

Gibt es serverseitig Caching-Methoden oder ähnliches, die vielleicht nur bei diesem Provider eingeschaltet sind und anderswo nicht?
Woran könnte es nicht liegen (laut Tests ist es kein Browserproblem)?

DANKE!

Patch #63 und #61 auf http://drupal.org/node/197786 behebt das Problem nicht, also nicht erfolgreich mit:

Bemerkenswert ist noch, dass bei aktiviertem Drupal Cache und wenn man dann ausloggt man zuerst mal mit einigermaßen normaler Geschwindigkeit jede Seite geliefert bekommt, die man zum ersten Mal anklickt.

Besucht man aber nun z. Bsp. alle Hauptmenüpunkt zum zweiten mal nach dem ausloggen, dann fliegen ab jetzt diese Seiten so schnell daher, dass man glaubt, die werden nicht vom Webserver geholt, die sind wirklich in einem Bruchteil einer Sekunde, so in 0,2 Sekunden da, man glaubt gar nicht, dass die geladen werden. Und das geht in 3 Browsern gleich, auch im langsamen IE fliegen die Seiten daher, als würden sie nicht geholt.

So gut ist kein Drupal-Cache auf keinem anderen Server. Aber was nutzt das, wenn man das Problem hat, dass man nach dem Einloggen bei allen vorher aufgerufenen Seiten ausgeloggt ist und jede Einzelne Seite erst mit einem STRG+R holen muss, damit man sie eingeloggt verwenden kann (sie oben beschrieben)?

Was spielt sich hier ab?

Der Server liefert beim ersten Aufruf:

HTTP/1.1 200 OK
Date: Thu, 30 Dec 2010 23:04:17 GMT
Server: Apache/2.2.3 (CentOS)
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Last-Modified: Thu, 30 Dec 2010 23:04:18 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

beim 2. Aufruf

HTTP/1.1 200 OK
Date: Thu, 30 Dec 2010 23:05:20 GMT
Server: Apache/2.2.3 (CentOS)
ETag: "0a25a7ab5074134d96ab5ce06f37a184"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
Last-Modified: Thu, 30 Dec 2010 23:04:19 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

http://de.wikipedia.org/wiki/HTTP_ETag

Das Problem tritt nur dann nicht auf, wenn der "Caching-Modus" in Drupal deaktiviert ist. Caching-Modus = Normal funktioniert nicht, man ist immer ausgeloggt nach dem einloggen.

Seitenkompression, Block-Cache, CSS-optimieren und JavaScript-optimieren können aktiviert sein, das macht kein Problem.

Woran liegt das?

Wenn der Caching-Modus ausgeschaltet ist, wird kein
ETag: "0a25a7ab5074134d96ab5ce06f37a184"
mehr geliefert, sondern immer ein
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
wie oben im oberen Bsp.

Jetzt habe ich mehrere Server auf denen Drupal ohne diese Login-Problem läuft getestet und siehe da, ein Server liefert das hier (mit ETag):

HTTP/1.1 200 OK
Date: Thu, 30 Dec 2010 23:33:46 GMT
Server: Apache
Last-Modified: Thu, 30 Dec 2010 23:32:28 GMT
ETag: "257d144a5af2a482064f2392b16b0fd1"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
Content-Encoding: gzip
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Aber auf diesem Server gibt es KEINE Login-Probleme. Liegt es doch nicht am HTTP ETag? Oder ist eine eine Kombination mehrerer Header-Werte? Welcher?

Dieser Versuch löst das Problem auch nicht:

Das fix eingebaut in der page.tpl.php bringt auch keine Lösung:

Hat niemand eine Idee, woran das liegen könnte? Server-Cache? Proxy am Server? Was sonst? Merci.

Patch #108 auf http://drupal.org/node/197786 löst das Problem auch nicht. Irgendwie scheint das Problem genau umgekehrt zu sein.

Hilfe!

Gibt es wirklich niemanden, der eine Idee hat, woran das liegen könnte?

Kann es sein, dass es damit zusammenhängt, dass PHP nicht als Apache Modul sondern in der CGI-Variante verwendet wird am Server?

Habe endlich eine Lösung gefunden.

Auf diesem Webspace wird der http ETag nicht korrekt unterstützt oder läuft nicht fehlerfrei. Vielleicht hängt es damit zusammen, dass php als fast-cgi ausgeführt wird.

Als Lösung musste ich folgende Zeile in der bootstrap.inc entfernen:

original:

neu:

Dieses Problem trat nur bei diesem einem Server auf, nur bei diesem Provider, sonst niemals.