Unsichere Objekte

[zub]

Hallo  guensi,
ist der Shop bei Strato?

MfG
zub

[guensi]

ja, lief aber bis gestern fehlerfrei

[zub]

Hallo,
schau mal hier:
http://www.(( Wir dulden keine kommerziellen Werbelinks - Bitte Forenregeln beachten! ))/forum/index.php?showtopic=6002&st=20&gopid=40115&

MfG
zub

[zub]

Sorry,
bitte im Anhang nachsehen.

  [ Für Gäste sind keine Dateianhänge sichtbar ]

[guensi]

hmm der Link funktioniert nicht, www.*********.de wird nicht gefunden - auf welcher domain liegt denn die Seite?

[zub]

nimm die zweite Antwort, die mit dem Bild

MfG
zub

[guensi]

Danke, das könnte schon mal ein Problem lösen.

Dann bliebe noch dieser ominöse doppelte Eintrag ...

Habe alle Änderungen seit der letzten mit Sicherheit laufenden Version rückgängig gemacht, Table Sessions geleert, Warenkorb-Dateien geleert - Den Eintrag mit der bezeichneten Nummer hab ich gefunden, aber den gibts nur einmal

Wo soll da der doppelte Eintrag noch liegen?

*FRUST*

[zub]

tja da bleibt nur Neuinstallation oder Schritt für Schritt durch die DB
und suchen

MfG
zub

[guensi]

sowas in der Art hatte ich befürchtet ...

übrigens das mit dem SSL hat noch nicht funktioniert, einziger Effekt - jetzt hab ich das durchgestrichene Schloss auch im Admin-Bereich, der vorher einwandfrei verschlüsselt wurde ...

Mache mich jetzt erst mal an die Datenbanksuche

[zub]

Hallo  guensi,
hast du ssl oder ssl-id.de

MfG
zub

[guensi]

So, Erfolg auf ganzer Linie, aber ein Problem hab damit schon noch (s. Frage unten).

SSL Funktioniert jetzt einwandfrei (tippfehler) - Danke zub - der Code funktioniert!

Zum doppelten-Eintrag-Fehler:
Die Suche in MySQL brachte es an den Tag, trotz mehrfachem Leeren der Table Sessions blieb der Eintrag mit der Nr. 2147483647 erhalten. Also in der Suche ausgewählt und löschen gedrückt, wieder nix - Eintrag blieb erhalten (hartnäckiges Teil). Erneut suchen - jetzt auf bearbeiten statt löschen, und den Wert dann dort markieren und löschen - Das hat dann funktioniert. Nun Table Sessions noch einmal leeren, da ein Dateiüberhang von 1651 Bytes angezeigt wurde - Das wars.

Fehlerursache möglicherweise auch ausfindig gemacht. Ist das ein Bug? Das sollte mal jemand austesten, der mehr davon versteht als ich.
Im Cookie war noch ein Eintrag von einer Testbestellung gespeichert, wodurch hartnäckig eine Session-ID für den Artikel aufgerufen wurde. Der Artikel wurde aber inzwischen geändert, bzw. um Informationen ergänzt. (Keine Ahnung wie sich das auf den Datenbankeintrag auswirkt, aber das muss es wohl gewesen sein). Die Bestellung wurde damals nicht zuende ausgeführt, sondern nur der Artikel 2x in den Warenkorb gelegt, dann wurde die Bestellung abgebrochen. Dieser Status muss wohl irgendwo vermerkt worden sein.
Als ich nun den (inzwischen aktualisierten) Artikel nochmal in den Warenkorb legen wollte kam die Fehlermeldung. Damit muss wohl auch ein fehlerhafter Eintrag in die Datenbank verbunden gewesen sein, sonst hätten ja andere diese Fehlermeldung nicht erhalten.

Lösungsweg: Datenbankeintrag löschen - Cookie löschen (kein Witz) dann nochmal den Artikel aufrufen - nun läuft wieder alles fehlerfrei.

Frage: Wie kann man nun verhindern, dass ein Kunde einen Cookie auf seinem Rechner hat, der einen Verweis auf einen alten Artikel beinhaltet? Und wieso wurde eigentlich der Cookie - soll ja wohl ein Session-Cookie sein - am Ende der Sitzung nicht gelöscht? Habs gerade ausprobiert der aktuell angelegte Cookie wird sowohl bei Firefox als auch bei Opera ordnungsgemäß am Ende der Sitzung gelöscht. Wo kam nun der alte Cookie mit dem Schrottinhalt her? Oder bezog der neue Cookie die alten Daten aus dem DB-Eintrag für den Warenkorb? Kann ich leider nicht nachvollziehen, da ich den Eintrag im Zuge der Suche nach dem Fehler gelöscht habe. Müsste man dann aber nicht den Warenkorb des Kunden am Ende der Sitzung automatisch löschen, um dieses Problem zu vermeiden?

[guensi]

Nachtrag - zumindest beim FF unter MacOS werden die Cookies nicht beim Schliessen des Fensters sondern erst beim Beenden des Progamms gelöscht. Nun da ich auf das Nutzerverhalten ja keinen Einfluss habe, besteht das Problem wohl darin, dass auch ein Session-Cookie nach Aktualisierung des Artikels durchaus noch die alten Informationen beinhalten kann. Wenn sich das so auswirkt, dass ein Login nicht mehr möglich ist wäre das fatal (deshalb auch fataler Fehler) - und durch den Schreibfehler in der Datenbank wirkt sich das nicht nur auf den einen Kunden sondern auf alle aus! Gibts das nun nur beim Admin-Account oder haben einfache Kunden dieses Problem auch? Werde mal versuchen das auszutesten. Insbesondere das Problem von noch mit alten Infos gefülltem Warenkorb werd ich mal versuchen zu testen. Aber bei der Vielzahl von potentiellen Möglichkeiten -  was z.B. die Reihenfolge der Erzeugung der betroffenen Dateien betrifft - ist es fraglich ob ich da die Ursache finde. Ich kann das ursprüngliche Vorgehen auch nicht mehr reproduzieren, kann mich einfach nicht mehr daran erinnern, in welcher Reihenfolge ich welche Veränderungen vorgenommen hab und ab wann genau der Fehler aufgetreten ist. - Ergebnis positiv oder negativ folgt.