Problem mit FEUsers/CustomContent

[giessener]

Hallo zusammen,
ich komme jetzt seit Tagen einem Problem nicht bei und hoffe, jemand von euch kann mir einen Tipp geben.
Ich habe eine Seite mit folgendem Inhalt (Die Option "Zwischenspeicherbar" ist auf dieser Seite aus):

Code: Select all

{cms_module module=FrontEndUsers}
{cms_module module=CustomContent}  
{$customcontent_loginname} 
{if $ccuser->loggedin()}    
  Logged in  
{else}   
  Logged off	 
{/if}

Wenn ich mich das erste Mal anmelde, bekomme ich die Ausgabe "nobody Logged off". Angezeigt wird weiterhin das Anmeldeformular.
Wenn ich mich dann erneut anmelde, bekomme ich die Ausgabe "username Logged in". Wieder wird das Anmeldeformular angezeit, allerdings mit dem Hinweis "Dieser Benutzer ist bereits angemeldet".
Wenn ich die Seite nun erneut aufsuche, steht wieder "nobody Logged off".
Meine Versionen: CMSMS 1.5.4, FEUSers 1.6.5 und CustomContent 1.5.3.
In gleicher Konstellation habe ich das ganze bei einer anderen CMSMS-Installation ausprobiert und hier funktioniert alles erwartungsgemäß: Nach dem Anmelden erscheint das Abmeldeformular und die Ausgabe ist "username Logged in".
Sämtliche Module habe ich bereits neuinstalliert und der Fehler tritt unverändert auf.
Was mir aufgefallen ist: FEUsers speichert eingeloggte User in der Tabelle "cms_module_feusers_loggedin". Das funktioniert auch wie erwartet (Das ist wohl der Grund, warum er bei 2. Login ausgibt, der Benutzer sei bereits angemeldet...).

Bin mit meinem Latein am Ende und hoffe auf euch
Vielen Dank an alle Leser und Mitdenker,
schöne Grüße!

[NaN]

Hallo giessener,

hast Du den Zwischenspeicher mal gelöscht?
(Administrator->Globale Einstellungen)

Ansonsten probier mal folgendes:
Im FEU-Modul gibt es eine Option "Den Benutzern erlauben sich mehr als einmal anzumelden".
Wenn das aktiviert ist, sollte es funktionieren.

Ist aber nicht wirklich die Lösung des Problems.
Sind denn bei allen CMS Versionen wo Du das probiert hast auch die gleichen Vorraussetzungen (also Serverseitig)?
FEU speichert die angemeldeten User nicht nur in der DB, sondern auch als Sessionvariable auf dem Server.
Wenn der Server keine Sessions erlaubt (also keine Session existiert) dann wird in der DB nachgeschaut.
Und dort kann aufgrund fehlender Sessiondaten keine eindeutige Zuordnung zum Clienten hergestellt werden.
D.h., dem User muss erlaubt sein, sich mehr als einmal anzumelden.

[giessener]

Hallo NaN,

danke für deine schnelle Antwort!
Den Zwischenspeicher habe ich gelöscht, ohne dass dies was gebracht hätte.

Die Option sich mehrfach anzumelden hat ebenfalls keine Verbesserung gebracht. Lediglich beim zweiten Login wird jetzt ebenfalls "nobody logged off" ausgegeben.

Somit könntes es durchaus etwas mit dem Sessionhandling des Servers zutun haben. Die "Problemseite" liegt bei 1und1 auf einem Business Pro Paket. Kann ich irgendwo erkennen, ob der Server das Problem ist (php_info?)? Andererseits: Was sollte sonst das Problem sein...

Vielen Dank!

[NaN]

Habe Die Module auch auf einem Business-Paket bei 1und1 ohne Probleme laufen.
Allerdings sowohl CMS als auch Module in einer älteren Version (1.2.5, 1.4 und 1.3 glaube ich).

Im Backend gibts eine Option wo man sich die Serverkonfiguration anzeigen lassen kann.
(unter Administrator)
Ist ähnlich dem php_info Befehl.

Versuch's mal mit einer anderen CustomContent Variable {$customcontent_loggedin}:

Code: Select all

{cms_module module=FrontEndUsers}
{cms_module module=CustomContent}  
{$customcontent_loginname}
{if $customcontent_loggedin}    
  Logged in  
{else}
  Logged off
{/if}

Eine andere Ursache könnte auch sein, dass Du nur auf dieser Seite den Zwischenspeicher deaktiviert hast, aber nach dem Login auf eine andere Seite umleitest wo der Zwischenspeicher noch aktiv ist.
(Kann man im FEU einstellen)

Oder das Problem liegt darin, dass Du die Module - so wie Du schreibst - im Inhalt aufrufst.
Wenn nun FEU das Logout-Formular anzeigen soll, könnte es sein, dass es den Ihalt komplett mit diesem Output ersetzen will.
Somit fehlt für diese Ansicht CustomContent etc.
Dazu gibt es für viele Module einen Parameter namens inline.

Ich habe die Module übrigens noch nie direkt im Inhalt aufgerufen, sondern immer nur im Template.

Mehr fällt mir dazu erstmal nicht ein.
Vergleiche erstmal die Serverkonfigurationen und dann können wir weitere Vermutungen anstellen.

[giessener]

Hallo NaN!

Ich bin mittlerweile etwas weiter - nur eine Lösung habe ich nicht, dafür kenne ich jetzt das Problem

Die Anzeige der Konfiguration im Backend hat mich nicht weitergebracht, da steht auch nicht viel spektakuläres drin.

Als ersten versuch habe ich auf den beiden Webspaces ein weiteres CMSMS parallel installiert und nur FEUsers und CustomContent installiert. Dann habe bei beiden Seiten mit deinem Beispielcode angelegt. Ergebnis: Das Verhalten ist das gleiche, wie auf der Hauptseite...

Dann habe ich den Bereich zur Session von der phpinfo-Ausgabe der beiden Installationen verglichen, die einzigen beiden Unterschiede sind bei session.gc_probability und session.cookie_httponly. Die beiden Optionen sollten aber keine Relevanz für das Problem haben, soweit ich das einschätzen kann. Kennst du dich da aus? Auf was muss ich achten?

Die zwischenzeitlich eingeschaltete Option von FEUsers auch Cookies zu verwenden, hat ebenfalls keine Besserung gebracht.

Als letztes habe ich mir die session_id (per UDT mit session_id() )  unterhalb des Login-Formulars ausgeben lassen und habe etwas interessantes festgestellt:
Ausgabe erster Login:  Nobody Logged off 8a48...e913
Ausgabe zweiter Login: Dieser Benutzer ist bereits angemeldet Username Logged in 071f...25ec
Ausgabe Seite neu laden:  Nobody Logged off 8a48...e913

In der Datenbank, in cms_module_feusers_loggedin, steht als session_id 071f...25ec. Irgendwie werden also zwei verschiedene IDs verwendet, wobei die eine nur von PHP per session_id() ausgegeben wird, wenn der eingeloggte Benutzer sich nochmal einloggt und eben in der loggedin-Tabelle vom FEUsers. Die ID wird hierbei aber nicht neudefiniert, sondern ist nur temporär gültig. Dadurch, dass sie aber in der Tabelle abgelegt ist, kann der Benutzer nicht wieder identifiziert werden.


Zusammenfassung aus meiner Sicht: Das Problem liegt beim Session-Handling des Servers.

[NaN]

Zum Thema PHP-Sessions kenne ich mich (noch) nicht besonders gut aus.
Was genau steht denn da? Worin unterscheiden sich die Werte?
Welche PHP Version läuft auf den Servern?
session.cookie_httponly funktioniert erst ab PHP5. (erlaubt den Zugriff nur über http Protokoll)
Das andere hat was mit Müll zu tun... 

Weiteres kann man evtl. hier nachlesen:
http://de.php.net/session.configuration

[giessener]

Ich weiß auch nicht viel über Sessions... Wir haben uns jetzt aus diesem, aber auch aus anderen Gründen entschieden auf einen Manages-Server umzuziehen. Mal schauen, wie sich unser CMSMS da verhält.
Der vollständigkeithalber hier noch die Unterschiede zwischen den beiden phpinfo()-Ausgaben im Bereich Session:
session.gc_probability = 1 auf dem Server, wo es nicht geht und 0 auf dem anderen
session.cookie_httponly = 1 auf dem Server, wo es nicht geht und nicht vorhanden auf dem anderen

Vielen Dank schonmal für deine Unterstützung!

[giessener]

Hallo zusammen,

so, die Geschichte geht weiter:
Wir sind jetzt umgezogen auf einen Managed Server bei 1und1 in der Hoffnung, dass das Problem sich dann von alleine löst, mussten aber feststellen, dass alles beim Alten ist 
Hat jemand eine Idee, die zur Ergreifung des Übeltäters führt? Ich weiß nicht mehr weiter...

Schöne Grüße!

[giessener]

So nochmal ich:

Ich versuche mal einen aktuellen Denkansatz zu formulieren:
Ich habe jetzt mal in der index.php im Wurzelverzeichnis von CMSMS ganz an den Anfang des Skriptes den Aufruf

Code: Select all

session_start();
$sessionIdSts = session_id();
echo $sessionIdSts;

geschrieben. Das Ergebnis ist, (neben dem Hinweis, dass die Header nicht mehr modifiziert werden können) dass auch hier die SessionID eine andere ist, wenn ich mich in FEUsers anmelde. Diese kann ich reproduzieren, in dem ich mich wiederholt versuche anzumelden. Wenn ich sonst auf der Seite navigiere, erhalte ich die ursprüngliche ID.
Zusammenfassung:
Der Server weist mir zwei SessionIDs zu - eine, wenn ich normal auf der Seite navigiere und eine weitere, wenn ich mich bei FEUsers anmelde (aber eben nicht, wenn ich angemeldet bin, so dass er mich nicht identfizieren kann). Daraus folgere ich, dass FEUsers den Server - aus welchen Gründen auch immer - dazu veranlasst zu glauben, dass er eine neue Session anlegen muss.
Woran könnte das liegen und wie kann ich das verhindern?

Vielen Dank für jedes Mitlesen und Mitdenken!

[giessener]

Hallo zusammen,

ich habe jetzt endgültig die Ursache des Problems gefunden:
Unsere root-URL (so steht sie auch in der config) ist www.xyz.de. Folglich laufen auch alle Seiten unter www... FEUsers specihert aber die Session_ID in der DB, die der Server vergibt, wenn die Seiten ohne www, also mit xyz.de aufgerufen werden - ohne, dass die URL im Browser dorthin wechselt (eine return-to-Seite ist nicht angegeben).
Der Workaround ist auch ganz simpel: Wenn ich die root-URL auf xyz.de setze, funktioniert alles prima! Blöd ist das aber dennoch, da ich ja nicht weiß, ob nicht jemand die URL direkt im Browser eingibt...
Immerhin haben wir jetzt einen Weg, der erstmal funktioniert...

Vielen Dank an alle, die mitgedacht haben - vielleicht fällt euch ja noch was zur neuen Situation ein?

Schöne Grüße!

[NaN]

Du kannst doch via .htaccess von www.xyz.de auf xyz.de umleiten. (oder umgekehrt)