Massive Probleme mit Frontendlogin -> Session / Cookies?

_Marc · Beitrag von **_Marc** » Fr 23. Nov 2007, 01:01

Hallo zusammen,

wie im anderen Thema (Stichwort l18n) bereits beschrieben,
will der Frontendlogin seit dem Update von 4.6.15 auf 4.6.23 nicht mehr!

Symptome:

Beim Versuch sich einzuloggen, gelangt man auf die front_crcloginform.php,
in der Adresszeile steht allerdings /front_content.php?idcatart=225 (225=Startseite).
Im Formular werden die Daten angezeigt, mit denen man sich versucht hat, einzuloggen.

Wenn man nun den front_cont... -Teil aus der Adresse löscht (also die Seite erneut aufruft), gelangt man wieder auf die front_crclogin-Seite.
Diesmal wird folgender Fehler angezeigt:

Fatal error: Could not display error page. Error to display was: 'No start article in this category'
Warning: Cannot modify header information - headers already sent by (output started at /homepages/7/d26895569/htdocs/mitglieder/front_content.php:314) in /homepages/7/d26895569/htdocs/mitglieder/front_content.php on line 405

Als Benutzer steht jetzt nobody im Formular.

Wenn man nun die Cookies löscht, funktioniert es wieder! Werden die Cookies testweise deaktiviert, ergibt sich oben beschriebener Fehler. Auch nach dem aktivieren bleibt dieses Verhalten reproduzierbar bestehen, erst ein Löschen der Cookies bringt den Erfolg,

ABER

leider nicht auf jedem Rechner so reproduzierbar. Wird die Seite auf einem Rechner/Browser aufgerufen, der noch nichts damit zu tun hatte, funktionierts. Auf den meisten Browsern, die vor und nach dem Update waren, gehts nicht. Auch ein löschen der Cookies hat nicht immer Erfolg (und muss von den Benutzern manuell durchgeführt werden -> Fehlerquelle)

Ich werde damit nicht fertig. Der Fehler ist einfach zu willkürlich. Kein Verhalten ist auf jedem Rechner zu 100% reproduzierbar.

Bitte helft mir, bin für jeden Tipp dankbar!!!

Grüße
Marc

Beitrag von **emergence** » Di 27. Nov 2007, 14:27

na viele ideen hab ich nicht... (wobei ich bezweifle das ich dich da wirklich verstanden hab)

Could not display error page. Error to display was: 'No start article in this category'

verwendest du im loginformular parameter wie client/lang/changeclient/changelang ?
oder arbeitet deine seite mit weiterleitungen nach dem login das diese parameter beinhaltet... ?

_Marc · Beitrag von **_Marc** » Fr 30. Nov 2007, 20:58

Hallo emergence,

vielen Dank für Deine Antwort, hatte schon nicht mehr mit einer Reaktion gerechnet! (Deswegen auch die späte Reaktion...)

Muss morgen mal nachschauen, habe das Standardlogin-Formular-Modul verwendet. Nichts exotisches.

Grüße
Marc

Beitrag von **Oldperl** » So 2. Dez 2007, 11:04

Hallo Marc,

du könntest versuchsweise mal dem Cookie einen anderen Namen geben.

In conlib/local.php Zeile 137ff steht

Code: Alles auswählen

class Contenido_Frontend_Session extends Session {

  var $classname = "Contenido_Frontend_Session";

  var $cookiename     = "sid";              ## defaults to classname
  var $magic          = "Phillipip";        ## ID seed
  var $mode           = "cookie";           ## We propagate session IDs with cookies
  var $fallback_mode  = "cookie";
  var $lifetime       = 0;                  ## 0 = do session cookies, else minutes
  var $that_class     = "Contenido_CT_Sql"; ## name of data storage container
  var $gc_probability = 5;

  function Contenido_Frontend_Session ()
  {
  	global $load_lang, $load_client;

  	$this->cookiename = "sid_".$load_client."_".$load_lang;

  	$this->setExpires(time()+3600);
  }
}

Wichtig ist in der Initfunktion die Zeile

Code: Alles auswählen

$this->cookiename = "sid_".$load_client."_".$load_lang;

Ich würde dort versuchen den Prefix "sid_" zu ändern.

Wie gesagt, ein Versuch, wenn sich dann was ändert, muss man überlegen, wie man das für weitere Con-Versionen anders umsetzen kann, wobei die Frage ist, wann 4fb eine Umstellung auf ein anderes Sessionverwaltungssystem als die PHPLib macht.

Gruß aus Franken

Ortwin

knb · Beitrag von **knb** » Mo 3. Dez 2007, 13:03

Kann sein dass Du Dich schon mal auf einem anderen Host eingeloggt hast, der den gleichen DNS-Domänenname hat, auf dem eine Webapp läuft, die Cookies setzt?

also z.B.
(Host 1) webmail.mycompany.de
(Host 2) contenidomandant.mycompany.de

Wenn dort (Host 1) ist eine Applikation (wie z.B: ein webmailer) ist, die einen Cookie setzt, die die Variablen USERNAME und LANGUAGE enthält, dann kriegen wir hier auch sehr seltsames Verhalten: Beim Aufrufen der Mandanten Homepage wird statt der Homepage das Backend-Loginformular angezeigt. Das Username Textfeld ist bereits mit einem default-Username "a25" (oder so was) belegt. Man kann sich nicht einloggen, und man kriegt die Homepage nicht zu sehen.

(Absoluter Showstopper. Hat schon für Kopfschütteln gesorgt. Aber das nur nebenbei bemerkt)

Das Problem ist nur in den Griff zu kriegen dadurch,dass man den HTTP Authentication Cache klärt, z.B. unter Firefox mit der Webdeveloper extension... geht sicher auch anders.

Hoffe das hilft, DIch auf eine andere Spur zu bringen-
Würde erklären warum das nur sporadisch / unvorhersehbar auftritt. (Nämlich nur dann wenn der user vorher bei (1) eingeloggt war, mit dem selben Browser mit dem er dann innerhalb gewisser Zeit auf contenido zugreift.)

_Marc · Beitrag von **_Marc** » Di 4. Dez 2007, 20:53

Hallo ihr Beiden,

ja, den Cookie-Namen hatte ich schon geändert. Allerdings habe ich mich an das "sid" nicht rangetraut, sondern nur hinten ein wenig geändert. Hat allerdings nicht zum Erfolg geführt. Ob es überhaupt etwas gebracht hat, ist bei pseudo-reproduzierbaren Fehlern schwer nachzuvollziehen.

Auf dem Webspace läuft eine Contenido-Instanz mit 2 Mandanten (+1 "Beta"-Mandant).
Backend-Login und fehlerbehaftete Seite liegen tatsächlich als Subdomain auf einer Domain. Allerdings sollte sich Contenido nicht mit sich selbst stören oder?
Webmail, etc., erreicht man darüber nicht (geht bei 1und1 anders).

Das mit dem HTTP Authentification Cache werde ich mir mal anschauen. Wo finde ich das denn bei der Webdeveloper Toolbar (anbei: Prima Werkzeug, gehört bei mir zu den FF-Must-Haves)?

Kann leider das Update im Moment nicht einspielen, da weitere Seitenausfälle im Moment unbedingt zu vermeiden sind. Wenn ich Zeit habe (das die immer so knapp ist...), versuche ich mal eine Testecke einzurichten. Wenn das Problem da nicht mehr auftritt, ist das dann ja auch eine Art Fehlereingrenzung, wenn doch, kann ich da weiterforschen.

Grüße
Marc

Beitrag von **Oldperl** » Mi 5. Dez 2007, 08:33

Hallo Marc,

leider kann ich den Fehler nicht reproduzieren, hab zwar einige Contenidos laufen, bisher aber keine solch massiven Probleme damit.

Halt uns auf dem Laufenden.

Gruß aus Franken

Ortwin

knb · Beitrag von **knb** » Do 6. Dez 2007, 11:03

in der web developer toolbar
unter miscellaneous/clear private data/HTtp authentication

holger.librenz_4fb

Hallo.

Hat sich das Problem mittlerweile erledigt? Wenn nicht: Ab der Version 4.6.22 ist es möglich Sessions auch im Dateisystem abzulegen. Den entsprechenden Schalter findest Du unter contenido/includes/config.misc.php folgende Zeile:

Code: Alles auswählen

$cfg["session_container"] = 'sql';

Mögliche, unterstützte Werte sind momentan sql und file. Eventuell hat sich bei Dir hier ein file eingeschlichen und der Webserver kann jedoch nicht die Session-Files schreiben?!

Gruß. Holger

_Marc · Beitrag von **_Marc** » Sa 22. Dez 2007, 20:20

Hallo zusammen,

habe noch nicht wieder probiert, das Update einzuspielen. Jetzt so unmittelbar vor Weihnachten ist aber wieder etwas Ruhe in die Seitenbesuche eingekehrt und da könnte ich eigentlich mal einen neuen Versuch starten.

Ich melde mich!

Grüße
Marc

_Marc · Beitrag von **_Marc** » So 23. Dez 2007, 15:55

Und da bin ich schon wieder!

Hab jetzt eine Testinstallation aufgesetzt:
Unterordner im Webspace mit eigener Subdomain,
eigene Datenbank.

Datenbank-Dump eingespielt, Dateien kopiert, .23 hochgeladen und Upgrade ausgeführt. Änderungen vorgenommen (dirty nach Holger).

Die massiven Probleme konnte ich noch nicht nachvollziehen, d.h. wenn Cookies aktiviert sind, ist alles klar.

Wenn man die Cookies testweise deaktiviert, gelangt man nach einer gefühlten Ewigkeit auf das Loginformular der front_crcloginform.inc.php.

Normalerweise sollten (wenn ich das richtig recherchiert habe) doch Sessions einspringen und die Cookies ersetzen oder?
Ob man den Speicherort dieser auf sql oder file setzt (sql war voreingestellt), macht keinen sichtbaren Unterschied.

Wenn das ganze jetzt in der Testinstallation läuft (mit deaktivierten Cookies?!), versuche ichs nochmal auf der Produktivumgebung. Hab die Schritte diesmal haargenau einzeln protokolliert.

Grüße
Marc