PROVIDERPROBLEM? Nach Einloggen immer ausgeloggt, Reload jeder Seite nötig, Cache aktiv
Eingetragen von DrupalFan (1646)am 01.01.2010 - 23:51 Uhr in
Nach der Aktivierung des Caches unter Einstellungen - Leistung gibt es nun folgendes Verhalten:
Nach dem Einloggen ist man zwar auf der Starseite eingeloggt und es funktioniert alles, aber klickt man auf eine andere Seite, z. Bsp. eine Views-Seite, dann ist man dort ausgeloggt, die Seite erscheint so schnell, man hat das Gefühl die Seite wird nur vom Browsercache geladen und nicht vom Server.
Das Problem ist aber leicht behoben: Man macht ein Reload im Browser (Aktualisieren, CTRL+R) und schon ist die Seite korrekt da, man ist eingeloggt. Klickt man nun auf einen anderen Menüpunkt, ist man wieder ausgeloggt, auch dort ist ein Reload nötig.
Irgendwie hängt das mit dem aktiviertem Cache zusammen, denn zuvor konnte man das Verhalten nicht beobachten.
Die Frage ist, ob man da etwas dagegen tun kann und was genau sich da abspielt? Ist das ein Problem von Drupal (Cache)? Oder ein Browser-Problem (tritt aber anscheinend bei mehreren Browser auf)?
Wer hat das schon beobachtet?
- Anmelden oder Registrieren um Kommentare zu schreiben
Cache Probleme - immer ausgeloggt, etc.
am 04.01.2010 - 12:20 Uhr
Liegt das an Drupal oder vielleicht doch auch am Webserver?
Hast Du vielleicht ne andere
am 04.01.2010 - 12:41 Uhr
Hast Du vielleicht ne andere BASE URL in der settings.php eingetragen?
--------------------
Design Probleme einfach mit FF und FIREBUG lösen!
keine base_url
am 04.01.2010 - 18:29 Uhr
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
am 05.01.2010 - 13:42 Uhr
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
Google Chrome Cache geleert
am 05.01.2010 - 14:03 Uhr
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
am 05.01.2010 - 21:17 Uhr
Und die Cookies?
Hast du vielleicht auf deiner Seite irgendwas zum Thema Session geändert?
-----------
Kooperative Netze Hamburg
Nicht das ich wüsste.
am 05.01.2010 - 21:31 Uhr
Nicht das ich wüsste.
Cache Probleme - Seitenkompression ist aktiviert
am 06.01.2010 - 15:20 Uhr
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.
Eingeloggt bleibt man nur, wenn man jede Seite reloaded
am 30.12.2010 - 23:13 Uhr
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!
Einzelseiten fliegen daher, also würden sie nicht vom Webserver
am 30.12.2010 - 23:44 Uhr
Patch #63 und #61 auf http://drupal.org/node/197786 behebt das Problem nicht, also nicht erfolgreich mit:
- header("Cache-Control: store, no-cache, must-revalidate");
+ header("Cache-Control: no-store, no-cache, must-revalidate");
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?
HTTP ETag Problem?
am 31.12.2010 - 00:06 Uhr
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
Caching-Modus deaktivieren um eingeloggt zu bleiben
am 31.12.2010 - 00:19 Uhr
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.
HTTP ETag?
am 31.12.2010 - 00:34 Uhr
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?
no-cache hilft auch nicht
am 31.12.2010 - 13:19 Uhr
Dieser Versuch löst das Problem auch nicht:
if ($user->uid) {header('Cache-Control: no-cache');
header('Pragma: no-cache');
}
Das fix eingebaut in der page.tpl.php bringt auch keine Lösung:
<meta http-equiv="cache-control" content="no-cache"><meta http-equiv="pragma" content="no-cache">
Hat niemand eine Idee, woran das liegen könnte? Server-Cache? Proxy am Server? Was sonst? Merci.
Unlösbar?
am 31.12.2010 - 14:07 Uhr
Patch #108 auf http://drupal.org/node/197786 löst das Problem auch nicht. Irgendwie scheint das Problem genau umgekehrt zu sein.
Hilfe!
Idee für Lösung?
am 02.01.2011 - 22:29 Uhr
Gibt es wirklich niemanden, der eine Idee hat, woran das liegen könnte?
PHP CGI
am 03.01.2011 - 14:34 Uhr
Kann es sein, dass es damit zusammenhängt, dass PHP nicht als Apache Modul sondern in der CGI-Variante verwendet wird am Server?
ETag musste entfernt werden
am 05.01.2011 - 14:33 Uhr
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:
header("Last-Modified: $last_modified");header("ETag: $etag");
neu:
header("Last-Modified: $last_modified");//header("ETag: $etag");
Dieses Problem trat nur bei diesem einem Server auf, nur bei diesem Provider, sonst niemals.