Guten Abend,
auf Dauer mach ich mich hier sicher unbeliebt, aber das nehm ich jetzt in Kauf.
PRG: Post/Redirect/Get - Wikipedia, the free encyclopedia
Wie an anderer Stelle bereits erwähnt, schreibe ich gerade ein Template. Beginnend mit leeren Dateien.
Das mach ich nicht aus Langeweile, sondern weil ich als CCO selbst festlegen möchte, wie die Besucher der Websites meiner Auftraggeber mit dieser interagieren sollen.
Ziele des Templates:
Es muss ohne Javascript die wesentlichsten Funktionen bereitstellen. Javascript ist nur ein Wrapper, der dem User, der es aktiviert hat bzw überhaupt nutzen kann (vgl. Screenreader, Braille), die Usability vereinfacht. Ich kann also nicht einfach alle Formulare auf XHR formulieren. Zudem will ich die PHP-Dateien soweit wie es geht nicht anfassen oder injecten; ich würde wahrscheinlich den Shop neu schreiben weil mich das hier aufregt... 240ms Ladezeit sind entschieden zu lang.
Aus diesem Weglassen des XHR ergibt sich ein Problem, dass mit dem Script-Ablauf der Original-Files zu tun hat.
Templateseitiges PRG würde theoretisch gehen. Ich hab zumindest erfolgreich eine Seite (mein Konto -> Rechnungsadresse ändern) so umbiegen können, dass der User aus der POST-Schleife herauskommt.
In der functions.php ist der PRG; um sicherzuestellen, dass ich nicht zu früh sterben lass, trigger ich das vom Template aus.
Prinzip:
Ich war eben dabei das mal in die Artikel-Seite einzubauen. Die Artikel-Seite ist jedoch Context-Sensitive. Und hier kommen wir auch zu dem "falschen" Script-Ablauf:
Das Template wird bereits ignoriert, z.B. wenn ich den Lagerbestand überziehen will. Den Redirekt macht ihr wiederum, um eine Nachricht an den User via GET zu triggern, statt das in der Session zu speichern, mit dem Ergebnis, dass ich auch die SEO-Url verlass (selbst wenn ich als action im Formular definiert ist).
Würde ich das jetzt als Plugin umsetzen, hätte ich hier imho auch schon ein Hook-Problem: entweder mach ich den Redirect zu früh (bevor ihr das Script abgearbeitet habt) oder zu spät (smarty wird bereits getriggert).
Auswahl:
Die PHP-Scripte sind aus PHP4-Zeiten und teilen dem Leser mit, dass die Autoren wenig bis gar keine keine Ahnung von der PHP-Engine haben, weil sie C, C++ oder C# gewohnt sind. Das würde einen nicht so interessieren, hättet ihr nicht vor wenigen Tagen diesen artkel published: JTL-Software zählt zu den 50 am schnellsten wachsenden Technologieunternehmen Deutschlands
OT: Das Triggern der Message-Boxen kann man schon fast als vulnarabilty einstufen, denn das ist ne Quasi-Einladung für Script-Kiddies zu ner Port-Scan-Party. Ich habe Zweifel, dass jeder eurer Lizenznehmer nen Admin im Keller gefesselt hat oder regelmäßig Log-Files liest.
Als Nicht-Lizenznehmer (ich arbeite nur im Auftrag mit eurem Shop und kann nicht mal Tickets erstellen ohne schief angeguggt zu werden) hätte ich gern eine Adresse, an die man Exploits melden kann. Sowas gehört nicht ins Forum. Und manche Threads hier sollten nur für Shop-Betreiber zu sehen und nicht öffentlich einsehbar sein.
Ich danke für Ihre Zeit.
auf Dauer mach ich mich hier sicher unbeliebt, aber das nehm ich jetzt in Kauf.
PRG: Post/Redirect/Get - Wikipedia, the free encyclopedia
Wie an anderer Stelle bereits erwähnt, schreibe ich gerade ein Template. Beginnend mit leeren Dateien.
Das mach ich nicht aus Langeweile, sondern weil ich als CCO selbst festlegen möchte, wie die Besucher der Websites meiner Auftraggeber mit dieser interagieren sollen.
Ziele des Templates:
Es muss ohne Javascript die wesentlichsten Funktionen bereitstellen. Javascript ist nur ein Wrapper, der dem User, der es aktiviert hat bzw überhaupt nutzen kann (vgl. Screenreader, Braille), die Usability vereinfacht. Ich kann also nicht einfach alle Formulare auf XHR formulieren. Zudem will ich die PHP-Dateien soweit wie es geht nicht anfassen oder injecten; ich würde wahrscheinlich den Shop neu schreiben weil mich das hier aufregt... 240ms Ladezeit sind entschieden zu lang.
Aus diesem Weglassen des XHR ergibt sich ein Problem, dass mit dem Script-Ablauf der Original-Files zu tun hat.
Templateseitiges PRG würde theoretisch gehen. Ich hab zumindest erfolgreich eine Seite (mein Konto -> Rechnungsadresse ändern) so umbiegen können, dass der User aus der POST-Schleife herauskommt.
In der functions.php ist der PRG; um sicherzuestellen, dass ich nicht zu früh sterben lass, trigger ich das vom Template aus.
Prinzip:
PHP:
function prg()
{
if(FALSE === $this->isPrg())
return;
!ob_get_length() ?: ob_end_clean();
clearstatcache();
ignore_user_abort(true);
header('Cache-Control: no-store, no-cache', true);
header('Pragma: no-store, no-cache', true);
header('Content-Length: 0', true);
header('Content-Type: text/plain', true);
header('location: '.$_SERVER['REQUEST_URI'], true, 0x012D);
}
function isPrg()
{
return $_SERVER['REQUEST_METHOD'] === 'POST';
}
PHP:
{strip}
{if $x42.core->isPrg() === true}
{$x42.core->prg()}
{else}
... mach das, was du sonst tust
{/if}
{strip}Ich war eben dabei das mal in die Artikel-Seite einzubauen. Die Artikel-Seite ist jedoch Context-Sensitive. Und hier kommen wir auch zu dem "falschen" Script-Ablauf:
Das Template wird bereits ignoriert, z.B. wenn ich den Lagerbestand überziehen will. Den Redirekt macht ihr wiederum, um eine Nachricht an den User via GET zu triggern, statt das in der Session zu speichern, mit dem Ergebnis, dass ich auch die SEO-Url verlass (selbst wenn ich als action im Formular definiert ist).
Würde ich das jetzt als Plugin umsetzen, hätte ich hier imho auch schon ein Hook-Problem: entweder mach ich den Redirect zu früh (bevor ihr das Script abgearbeitet habt) oder zu spät (smarty wird bereits getriggert).
Auswahl:
- Der Script-Ablauf (ein Pattern habt ihr ja nicht), müsste zumindest dahingehend abgeändert werden, dass alle Header erst collected und Bedarf versandt werden.
- Eine Nachricht an den User ist nicht mittels GET zu triggern. Ich kann 10 Artikel im Warenkorb haben und mir trotzdem "Ihr Warenkorb ist leer" anzeigen lassen. Anderes Beispiel:
http://example.com/index.php?a=1327&n=1&r=1
http://example.com/index.php?a=1327&n=1&r=2
http://example.com/index.php?a=1327&n=1&r=3
http://example.com/index.php?a=1327&n=1&r=4
http://example.com/index.php?a=1327&n=1&r=5
http://example.com/index.php?a=1327&n=1&r=6
http://example.com/index.php?a=1327&n=1&r=7
http://example.com/index.php?a=1327&n=1&r=8
Angenommen ein Kunde legt etwas in den Warenkorb und triggert einen Fehler, z. B. Verfügbarkeit:
Es ist nicht unwahrscheinlich, dass er sich jetzt ein Bookmark zieht. Solang er über das Lesezeichen einsteigt, wird also immer die Nachricht "Nicht Verfügbar" sehen.
Nachrichten wie diese gehören normalerweise tokenized in die Session (sterben also mit dem nächsten Request). - Der ganze Thread wäre nicht notwendig, würde der Shop PRG bereits von Haus aus unterstützen. Die Änderungen im Core sind nicht mit Aufwand verbunden (siehe oben) - allerdings nur, wenn man weiß, an welcher Stelle. Das wiederum kann nur JTL selbst.
- Formular-Targets: Die artikel_inc überschreibt mit ihrem Location mein Target. Unabhängig davon, was ich dem User vorsetzen will, sollte es wenigstens so formuliert sein, dass er anschließend wieder auf die SEO-Url kommt. Er hat schließlich nur etwas in den Warenkorb legen wollen.
- Es fehlt eine Möglichkeit Custom Ajax-Formulare abzusenden: RFC ist UTF-8. Der Shop ist aber so geschrieben, dass er nur das encoded, von dem er annimmt, dass es UTF-8 sein könnte. Hier fehlt im Core ein Mapping, dass dann getriggert wird, wenn der Browser den XHR-Request-Header mitschickt.
Die PHP-Scripte sind aus PHP4-Zeiten und teilen dem Leser mit, dass die Autoren wenig bis gar keine keine Ahnung von der PHP-Engine haben, weil sie C, C++ oder C# gewohnt sind. Das würde einen nicht so interessieren, hättet ihr nicht vor wenigen Tagen diesen artkel published: JTL-Software zählt zu den 50 am schnellsten wachsenden Technologieunternehmen Deutschlands
OT: Das Triggern der Message-Boxen kann man schon fast als vulnarabilty einstufen, denn das ist ne Quasi-Einladung für Script-Kiddies zu ner Port-Scan-Party. Ich habe Zweifel, dass jeder eurer Lizenznehmer nen Admin im Keller gefesselt hat oder regelmäßig Log-Files liest.
Als Nicht-Lizenznehmer (ich arbeite nur im Auftrag mit eurem Shop und kann nicht mal Tickets erstellen ohne schief angeguggt zu werden) hätte ich gern eine Adresse, an die man Exploits melden kann. Sowas gehört nicht ins Forum. Und manche Threads hier sollten nur für Shop-Betreiber zu sehen und nicht öffentlich einsehbar sein.
Ich danke für Ihre Zeit.