Zwei Bugs im Premium-Shop

Einstellung des Betriebs!

Zum 01.02.2023 wird der Beitrieb von Atrox-Dev eingestellt. Alle Downloads und Benutzer werden entfernt und die Website geht offline. Wer noch eine Kopie der alten Pakete benötigt, sollte sich diese bis dahin runterladen.

Alle Pakete sind bereits unter neuem Label in unserem und im WoltLab-Store erhältlich, wo ihr auch weiterhin Support erhaltet.

Mehr Informationen zur Atrox-Übernahme

    Hallihallo,


    ich habe heute nochmal zwei Fehler bekommen:


    Der Erste bezieht sich auf den manuellen Aufruf der MCPAPISuccessPage. Hier sollte eventuell nachgebessert werden, falls ein Kunde irgendwie auf die Seite gelangt. Zum Beispiel mit einem roten Hinweistext und einer Weiterleitung auf die Shop-Rechnungen-Liste. Ein Fehler sollte hier auf jeden Fall nicht geworfen werden.


    Code
    1. Tue, 16 Jun 2015 11:14:33 +0000Message: PHP notice in file /jc/website/shop/lib/page/MCPAPISuccessPage.class.php (30): Undefined index: amountFile: /jc/website/wcf/lib/system/WCF.class.php (304)PHP version: 5.6.9-0+deb8u1WCF version: 2.1.4 (Typhoon)Request URI: /shop/mcpapi-success/Referrer: User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36Information: ""Stacktrace: #0 /jc/website/shop/lib/page/MCPAPISuccessPage.class.php(30): wcf\system\WCF::handleError(8, 'Undefined index...', '/jc/website/sho...', 30, Array) #1 /jc/website/wcf/lib/page/AbstractPage.class.php(273): shop\page\MCPAPISuccessPage->readData() #2 /jc/website/wcf/lib/page/AbstractPage.class.php(100): wcf\page\AbstractPage->show() #3 /jc/website/wcf/lib/system/request/Request.class.php(58): wcf\page\AbstractPage->__run() #4 /jc/website/wcf/lib/system/request/RequestHandler.class.php(139): wcf\system\request\Request->execute() #5 /jc/website/shop/index.php(10): wcf\system\request\RequestHandler->handle('shop') #6 {main}


    Der zweite Fehler bezieht sich auf den manuellen Aufruf der MCPAPIErrorPage. Ich vermute allerdings, dass der Fehler auch bei einem legitimen Aufruf auftreten würde.


    Code
    1. Fatal error: Class 'shop\page\AbstractPage' not found in /jc/website/shop/lib/page/MCPAPIErrorPage.class.php on line 24


    Nachtrag: Auch wenn ich einen API-Check auf Micropayment durchführe erhalte ich:



    als Rückmeldung auf MicroPayment.


    Vielen Dank im Voraus,
    Scrayos

    Der erste Fehler liegt wohl an der falschen Konfiguration bei Micropayment. Ich denke, du hast den amount Parameter in den API Antwort gelöscht.


    Zum dritten Fehler: Du hast hier wieder ein Mailserverproblem. Irgendwo ist eine leere Emailadresse oder ein leeres Name angegeben.
    Hast du einen Namen für die Adminadresse im ACP hinterlegt? Gehört die Bestellung 48 einem User mit gültiger Email?

    Scrayos schrieb:

    Der Erste bezieht sich auf den manuellen Aufruf der MCPAPISuccessPage

    Nein. Im Normalfall klappt es ja exellent. Ich meinte, dass dieser Fehler produziert wird, wenn man die API-Seite normal im Browser aufruft. Das ist natürlich keinesfalls der Normalfall, dennoch sollte es nach Möglichkeit keinen Fehler werfen. Deshalb auch der Hinweis:

    Scrayos schrieb:

    Hier sollte eventuell nachgebessert werden, falls ein Kunde irgendwie auf die Seite gelangt. Zum Beispiel mit einem roten Hinweistext und einer Weiterleitung auf die Shop-Rechnungen-Liste. Ein Fehler sollte hier auf jeden Fall nicht geworfen werden.

    Zum dritten Fehler: Auch hier dürfte prinzipiell mein Mail-Server weitestgehend unschuldig sein. Denn der Fehler kommt ebenfalls nicht im normalen Betrieb sondern wenn man den MicroPayment-API-Check durchführt (Ein Feature im ControlPanel). Damit kommt dann die Endanwendung nicht klar. Vermutlich weil ja zu dem Request nichts vorliegt. Er darf ja gerne still verworfen werden mit einer bejahenden "Status"-Antwort, aber auch hier sollte einfach kein Fehler erscheinen, da es sich ja um eine Feste Funktion bei MicroPayment handelt.

    Fehler 2 und 3 siehst du aber auch als "Wert zu beheben" an, oder?


    Ich sehe es zudem als potentielle Lücke für Angreifer, wenn man durch das Aufrufen einer einfachen URL einen langen Log-Eintrag erzeugen kann, so ist es extrem unpraktisch, wenn man den Überblick behalten möchte. Ein findiger Nutzer kann so ohne jeglichen Aufwand mein Log zuspammen. Das log wird so auch nicht für tatsächlich wichtige Fehler freigehalten, sondern mit voraussehbaren Meldungen überschwemmt.


    Natürlich handelt es sich hier um einen unwahrscheinlichen Fall, aber wenn man von einem Fehler schon bescheid weiß, es keine negativen Konsequenzen hat ihn zu beheben, und man so eine Lücke schließen kann, so sollte diese Chance doch wahrgenommen werden, oder nicht?