Schwerwiegendes Login-Problem nach Update von 1.06 auf 2.0.X

[noRiddle]

Aufgrund des von Shop-Version 1.06 zu 2.0.X unterschiedlichen Cookie-Attributes 'domain' kann es nach einem Update von 1.06 auf 2.0.X zu geschäftsschädigenden Login-Problemen für Kunden kommen.
Das geschieht dann, wenn Kunden noch Session-Cookies des alten Shops im Browser haben.

Bitte den von mir dazu ​gestarteten Thread beachten, in welchem ich alles genauer darlege.

Gruß,
noRiddle

[Torsten Riemer]

War das wirklich ein Update direkt auf 2.0.4.2 oder mit Zwischenschritten erst auf eine frühere Version?

[anonymous]

Im oben verlinkten Thread habe ich dazu bereits etwas gesagt.
Allerdings führt deine Art der Fragestellung hier zu Fragen meinerseits.
Wie kann man denn von 1.06 auf 2.0.4.2 ohne Zwischenchritte updaten ?

Damit das Verständnis nicht an Begrifflichkeiten scheitert:
Die Shop-Dateien wurden mit einem Mal angehoben, die DB-Updates selbstverständlich schrittweise durchgeführt.
Aber selbst wenn zu unterschiedlichen Zeitpunkten erst auf 2.0.0.0, dann auf 2.0.1.0 usw. upgedatet worden wäre, was ändert das ?
Fakt ist:
Ich habe jetzt einen Testshop auf 1.06 und einen auf 2.0.4.2 und das Problem trit auf wenn ich beide im selben Browser geöffnet habe. Dabei ist doch unerheblich in wievielen Schritten der 2.0.4.2-Shop zu seiner Version kam (war übrigens nie 1.06).
Ich kann das Problem ja jederzeit reproduzieren, also Cookies löschen, erneut beide Shop-Version im Browser öffnen => Login-Problem.

Bei Kunden kam mir das Problem ebenfalls unter.

In beiden Fällen, in meiner Testumgebungen sowie in der von Kunden, gibt/gab es jeweils den Live-Shop auf 1.06 auf www und die Testumgebung auf 2.0.4.2 auf einer (anderen) Subdomain derselben Domain.

Gruß,
noRiddle

[anonymous]

*NACHTRAG*
Ach, und ich sehe ja auch unabhängig vm Login-Problem im Browser-Tool, daß das Domain-Attribut das weniger spezifische des 1.06-Shops ist, also .DOMAIN.TLD .

Gruß,
noRiddle

[Torsten Riemer]

Replying to anonymous:

[...]
Damit das Verständnis nicht an Begrifflichkeiten scheitert:
Die Shop-Dateien wurden mit einem Mal angehoben, die DB-Updates selbstverständlich schrittweise durchgeführt.
Aber selbst wenn zu unterschiedlichen Zeitpunkten erst auf 2.0.0.0, dann auf 2.0.1.0 usw. upgedatet worden wäre, was ändert das ?
[...]

Das Ergebnis ist ja das selbe, aber wenn du als Dienstleister die Einzel-Updatepakete verwenden würdest, dann würdest du dir unnötig viel Arbeit machen. Nur das wollte ich damit gesagt haben.

Kann sein, dass das Problem auch erst mit der kommenden Shopversion 2.0.5.0 behoben sein wird. Gerhard hat da mehr Überblick, da er das mit den Cookies korrigiert hatte.

[anonymous]

Nöö, klar verwende ich nicht die Einzel-Updatepakete. Danke trotzdem für den Hinweis.

Gruß,
noRiddle

[Torsten Riemer]

Stand bei dem Shop STORE_SESSIONS auf true oder false?

Die Cookies werden nur gelöscht, wenn die Sessions datenbankbasiert gespeichert werden.

Grüße

Torsten

[anonymous]

Ich weiß, habe mir ja den Code ja angeschaut.
Ja, ist db-basiertes Session-Handling.
Allerdings sollten alte Cookies auch bei datei-basiertem Sesion-Handling gelöscht werden.

Ich hab's mir jetzt mal genauer angesehen.
Das Problem taucht auf wenn man zu Zwecken des Updates eine Kopie des Shops auf eine Subdomain legt (wie auch im thread erklärt).
Dann nämlich ergibt $current_domain und $current_domain_old dasselbe.
Z.B. test.DOMAIN.TLD
Mit www.DOMAIN.TLD klappt es, da sind $current_domain und $current_domain_old unterschiedlich.

Ich habe die Regex in der Funktion xtc_get_top_level_domain() noch nicht ganz durchschaut, evtl. liegt es daran.
Ich denke aber eher es liegt an diesem Code

    if(substr($domain_path, 0, 4) == 'www.') {
        $domain_path = substr($domain_path, 4);
    }
    $return_array['old'] = $domain_path;

welcher

$return_array['old']

nur dann auf DOMAIN.TLD setzt wenn die Subdomain www. ist.

Wenn der Live-Shop auch vorher schon auf einer Subdomain lag weiß ich nicht wie es aussieht, kann ich gerade weder testen noch durchdenken.

Gruß,
noRiddle

[Gerhard Waldemair]

In 11732:

fix #1603

[Gerhard Waldemair]

In 11738:

fix #1603