Beiträge von Joerg2010

V 1.1.1

a) Ich erstelle eine Testbestellung, klicke auf der checkout_success auf "weiter", komme dadurch zur Startseite.

b) benutze ich nun den "Zurück"-Button meines Browsers, komme ich wieder auf die checkout_success.

c) Im firefox kann ich nun die Bestellung erneut drucken, der Internet Explorer aber öffnet mir die error_message.html

Frage / Anmerkung: Grundsätzlich sollte man über "Browser-Back" überhaupt nicht mehr auf diese Seite kommen. Wie könnte man das realisieren?

Was läuft da beim IE anders?

PS: Die error_message.html ist m.e. auch fehlerhaft, da sie immer "Möchten Sie noch einmal suchen..." etc. anzeigt, was, gerade in diesem Fall ja Unsinn ist.

PS: M.e. müsste nach der checkout_success, also bei Klick auf "weiter" die Bestellung in der Session "zerstört" werden, da erledigt. Und der "Drucken"-Button eben nur angezeigt werden, wenn es eine gültige Bestellung ist, also eine Bestellung, die noch nicht abgeschickt wurde.

PS: Kurioserweise kann ich den "Fehler" nun kein zweites Mal reproduzieren.... ich hoffe nicht, dass da ein versteckter Bug ist...

Ebenfalls schönes Wochenende

Nochwas entdeckt:

admin/configure
define('ENABLE_SSL_CATALOG', 'true'); // secure webserver for catalog module

/configure
define('ENABLE_SSL_CATALOG', true); // secure webserver for catalog module

Einmal string, einmal boolean...

die beiden sind drin

Also

images, cache, templates_c und im admin Order 2 Unterordner (welche?) + sitemap1.xml auf 777 ???

Wenn ich z.B. die sitemap1.xml auf 775 setze, gibts nen Fehler.

Warning: fopen(sitemap1.xml) [function.fopen]: failed to open stream: Permission denied

Ja klar - ist so, wenn der Server upgedatet wird

Aber nicht schön, wenn man o.a. Fehler sieht

Da mein Provider nicht der langsamste ist, baut der gerade die UpDates
Dabei ist mir nun aufgefallen, dass bei DB-Error

Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) in /var/kunden/webs/xxxxxx/xxxxxx/shop/commerce_seo_url.php on line 9 usw. angezeigt wird

Als Tipp für die Entwickler, da hier wohl mindestens ein @, besser ein try / catch vergessen wurde

Gruß

Nochmal zum eigentlichen Thema Sicherheit.
Mir geht es nur darum, welche Dateien oder Verzeichnisse ZWINGEND auf 777 sein müssen, welche ZWINGEND auf 444, und welche auf XXX - hab schon rumgegoogelt aber nichts eindeutiges gefunden.

PS: ...die genannten Versionen entsprechen dem Versionsstand der Quellcode-Pakete. Jede Linux-Distribution selbst führt aber nochmals eigene Versionen (und darüber hinaus sicherheitsrelevante Patches), so das die Pakete meist nie auf dem aktuellsten Stand sein können. Da sich mit neuen Programmversionen teilweise auch Funktionalitäten und die Abwärtskompatibilität zu Scripten und vorhandenen Konfigurationen ändern kann, kann man nicht immer "automatischen Updates" bei Neuerscheinung ausführen, sondern in der Regel nur sicherheitsrelevante Updates.

Ich meinte eher, nicht mehr auf mySQL 4 und PHP 4 zu sein.

Sind die UpDates, die Du schilderst, sicherheitsrelevant?

Mein Provider (klein aber fein) dated bei Sicherheitsproblemen eigentlich immer automatisch up...

Danke für das ausführliche Statement. Der Server ist up to date. PHP 5.2.0-8, mySQL 5.0.32, Linux 2.6.18, Apache/2.2.3 (Debian)
OpenSSL wird gerade auch upgedatet.

Dankeschön!

Gibt es irgendwo noch eine Checkliste für einen finalen Sicherheitscheck? Rechtevergabe etc.

Herzlichen Dank für Deine/Eure Tipps.

Noch eine Frage: Wofür sind die beiden includes

application_top_export
application_top_callback

?

Danke

Ich habe durch Zufall

http://code.google.com/p/shopos/sourc…ogin.php?r=1291

entdeckt und meine login.php in dieser Art angepasst. Ich hab zwar noch nicht raus, warum nun gar kein Captcha beim Login kommt, aber besser als den Kunden "herumklicken" zu lassen, ohne dass etwas passiert.

sikiera - wie hattest Du es gelöst?

Danke für die Infos.
sikiera, hast Du eine Info für mich, was ich in der login.php ändern muss, damit der captcha immer kommt?

Hallo,
ist eigentlich geplant, dass man die V2 einfach auf die V1.1.1 aufspielen, also die 1.1.1 zur 2 updaten kann?
Wäre schon heftig, jetzt nach den ganzen Anpassungen bei der irgendwann "für produktiv" erscheinenden V2 wieder von vorne anfangen zu müssen.
Ich hab nun eigentlich alles lösen können und könnte mit meinem Shop starten, wenn ich nur das Captcha/Login - Problem lösen könnte...
Hast Du bzw. habt Ihr da keinen Tipp (Deine Abfrage...), wie man das in der 1.1.1 hinbekommt?
Wäre klasse...

Noch etwas gefunden:

Fehler tritt seltsamerweise nur bei eingeschaltetem PHPIDS auf.

Warning: Smarty error: unable to read resource: "/lang_.conf" in .......

Ergebnis der Fehlersuche:

In der logoff.php geht nach dem Include der header.php die Session verloren, jedoch wird danach auf die language aus der Session zugegriffen, die es dann aber nicht mehr gibt.

Lösungsansatz:

Vor

require (DIR_WS_INCLUDES.'header.php');

Einfügen

$tmp_lang = $_SESSION['language'];

und die beiden

$smarty->assign('language', $_SESSION['language']);

ersetzen mit

$smarty->assign('language', $tmp_lang);

Oder ist das dirty?

Beim Test / Suche nach dem o.a. Bug ist mir noch folgendes aufgefallen:

Habe ich mir über "Passwort vergessen" ein neues Passwort zusenden lassen und mich erfolgreich eingeloggt, gehe dann z.B. ins Adressbuch oder in die Auftragsübersicht, so erscheint weiterhin die Meldung "Ein neues Passwort wurde per E-Mail verschickt.", obwohl diese "Geschichte" ja dann schon längst erledigt ist.

Hm... niemand vom Support da? 2 Tage? Schade...

Hab mir zwischenzeitlich mal die login.php angesehen.

Die erste Abfrage ist ja:

if (isset ($_GET['action']) && ($_GET['action'] == 'process')){ ...

Diese umschließt unter anderem

$smarty->assign('VVIMG', '<img src="'.FILENAME_DISPLAY_VVCODES.'" alt="" />');
$smarty->assign('INPUT_CODE', xtc_draw_input_field('vvcode', '', 'size="6" maxlength="6"', 'text', false));

Und das müsste dann doch die Ursache sein, denn wenn ich nun über die Links "Kundenkonto" auf die login.html komme und dort "Einloggen oder ein neues Kundenkonto erstellen" klicke, ist die $_GET['action'] leer..., d.h. überhaupt nicht gesetzt...

Hallo,
bin neu hier und habe commerce:seo installiert. Läuft so weit ganz gut aber bei Tests sind mir Fehler aufgefallen:

a) klicke ich in der Login-Box auf "passwort vergessen", wird mir der Captcha (kein gd Fehler !) angezeigt. Dort tue ich nun aber einfach gar nichts und klicke weiter in den Kategorien herum. Gebe ich nun aber in der Login-Box Username und Passwort ein und will mich einloggen, komme ich auf die login.php (action=process), erhalte die Meldung, dass mein Sicherheitscode falsch wäre. Die Login.php zeigt aber keinen Captcha an. (Wurde evtl. in der Session gespeichert, dass ich vorher die Passwort-Vergessen Funktion aufgerufen hatte?).

Lösung?

b) Ganz ähnliches, evtl. Session Problem, z.B. beim Einlösen eines Gutscheines.
Ich gebe einen falschen Gutscheincode auf der shopping_cart.php ein und erhalte richtigerweise die Fehlermeldung.
Ignoriere ich das nun und klicke "zur Kasse", wird diese Fehlermeldung auch auf der checkout_shipping, checkout_payment usw. angezeigt.

Wenn der Kunde auf die nächste Seite klickt, sollte doch nicht die Fehlermeldung der Vorseite erscheinen...

Lösung?

Danke im Voraus.