Beiträge von peterdd

    Das Problem kenne ich. :o Bei dieser aktivierten Option ist dann eine aus meiner Sicht etwas verquere Logik im Shop aktiv. (ältere xtc/cseov1 Version, cseov2 weiß ich nicht)

    Bei der Option wird erst ein Cookie namens cookie_test gesetzt, aber keine Session gestartet (und damit kein Sessioncookie gesetzt). Erst mit dem nächsten Seitenaufruf schickt der Browser das cookie_test zurück und der Shop "weiß" dann, dass Cookies doch gehen beim User/Kunden. Erst dann erstellt er ne Session/Sessioncookie. Dadurch ist ein Roundtrip / "Browser-Server Pingpong" mehr nötig.

    Dumm halt dann, wenn vorher schon die User/Kunden einloggen/Warenkorb füllen, bevor ein Sessioncookie im Browser vorhanden ist.

    Hallo,

    neuere Browser unterstützen die HTTPonly Eigenschaft von Cookies, die Sessionklau erschweren sollen.
    Wenn man am Anfang der beiden sessions.php (normal und in der admin Verzstruktur) folgendes einfügt,

    PHP
    # 20110707 Test: keinen direkten Zugriff per Javascript auf Sessioncookie in modernen Browsern erlauben
    @ini_set('session.cookie_httponly', true);

    sollte das sessioncookie sicherer sein als ohne.
    Diese Eigenschaft ist laut php.net seit php 5.2.0 verfügbar.

    Irgendwelche Bedenken/Probleme?

    Habe mal kurz die demoshops diverser Shopanbieter durchprobiert, im xt:c Bereich habe ich das jetzt noch nicht gesehen, bei einem anderen System ja. Viele großen Seiten (Google usw) nutzen inzwischen die HTTPonly Eigenschaft.

    Hallo, wir nutzen einen modifizierten v1.1.1 und haben - seitdem wir versuchen, die XTCsid komplett aus dem HTMLcode/URLS zu verbannen - vermehrt Fehlerfälle mit "Produkt in Warenkorb" legen.

    Leider läßt sich trotz unterschiedlichster Versuche (Browser, Browsereinstellungen, Caches/Chronik löschen, über Google kommen etc, Cookies on/off) der Fehlerfall von uns selbst nicht reproduzieren, tritt aber laut accesslog bei Kunden auf (definitiv auch echte Kunden, da im weiteren Verlaufe Produkt doch noch gekauft) :o

    Hintergrund, die Session soll nur noch per Cookie laufen und keine XTCsid mehr in Suchmaschinen (ja, man kann das per robots.txt und in Quellecode abfragen, funktioniert aber ni 100%, bei gecachten Boxen sind URLs mit XTCsid auch sinnlos)

    Vorher ist der Fehler dem Logfile nach auch schon aufgetreten, aber seltener. Ich denke, das Problem war vorher nur verdeckter.

    Ein ähnliches Verhalten lässt sich auch im aktuellen v2.1 Demoshop provozieren. (in diesem Falle aber reproduzierbar)

    Auslöser ist, dass im Verlauf der inkludierten php-files keine gültige $_SESSION['cart'] da ist, in cart_action.php aber auf die Objektmethode(?) add_cart zugegriffen wird.

    In application_top.php:

    PHP
    require (DIR_WS_INCLUDES.FILENAME_CART_ACTIONS);
    // create the shopping cart & fix the cart if necesary
    if (!is_object($_SESSION['cart'])) {
            $_SESSION['cart'] = new shoppingCart();
    }

    wird ein fehlendes "cart" ja erst NACH dem Durchlauf von cart_actions.php "repariert"(?), aber vorher stirbt das Skript schon in cart_actions.php.

    webdesign erfurt, bitte melden, damit wir zusammen die Lösung finden können. :)

    z.B. p.products_id, pd.name, ....

    oder wenn man Spaltennamen im Ergebnis anders benennen will:

    p.products_id AS produktnummer, pd.name AS produktname, ...

    Naja, bei einem einzigen Produkt als Ergebnisliste ist das wohl hier eher zu vernachlässigen und würde es komplizierter machen, da die Felder dieser Abfrage sicherlich in vielen Templates verwendet werden.

    Bei der advanced_search in v1.1.1 wirkt das Entfernen von DISTINCT Wunder in der sql-search-query in der SQL-ausführung bei sehr hoher Produktanzahl. Man drücke mal in einem Shop ohne Suchstringeingabe auf den Suchen-Button, was theoretisch alle vorh. Produkte als Ergebnis liefert.
    (bei Worstcase-szenario etwa 50 Sek auf unter 1Sek.)
    Bei uns auf den ersten Blick ohne Nebenwirkung.

    Ist jetzt nur die Frage, warum das DISTINCT dort überhaupt mal reingesetzt wurde...