Nach Update auf 4.2.1: Downloadlinks funktionieren nicht mehr

[pnav]

Hallo,

mal wieder ist unser Shop nach einem WPSG Update kaputt. Alle Downloadlinks funktionieren nicht mehr. Downloads über die Downloadlinks werden mit der Meldung "Die Datei wurde nicht gefunden" quittiert.

Die Ursache ist die Code Änderung in der Datei wpsg_mod_downloadprodukte.class.php Zeile 538:

Vor dem Update:

Code: Alles auswählen

if ($_file == base64_decode($_REQUEST['file']))

Nach dem Update:

Code: Alles auswählen

if ($_file == rawurldecode($_REQUEST['file']))

Dadurch werden die base64 kodierten Dateinamen nicht mehr dekodiert und WPSG findet die Datei nicht. Wir haben das jetzt temporär gefixt durch ein Wiedereinfügen der base64_decode Funktion.

Gruß

[maennchen1.de]

Hallo!
Wenn ich dich richtig verstehe, meinst du bestimmt alte Downloadlinks, welche vor dem Update erzeugt wurden. Neue Links funktionieren. Kann das sein?
Wenn ja, liegt das an der mangelnden Rückwärtskompatibilität, an welche wir in diesem Fall nicht gedacht haben. Grund für die Entfernung sind leider die Vorgaben von WordPress.org.

[pnav]

richtig die neuen Links gehen, die Frage wäre, wie das Problem gelöst werden kann. Schließlich wollen die alten Kunden auch nach wie vor Ihr Produkt runterladen können!

VG

[Karl Herre]

Hallo,

wir Arbeiten zurzeit an einem Bugfix, sobald es einen fix gibt melden wir uns!

Gruß Karl

[daschmi]

Hi,

sorry für die Unannehmlichkeiten. Wir haben die base64_(en)decode Funktion ersetzt, weil damit viel bösartiges passiert und viele Scanner diese Funktion daher als verdächtig einstufen.

Wir arbeiten an einem Plugin, was die Abwärtskompatibilität sicherstellt.

Kannst du folgenden Code in einem Plugin oder im Theme versuchen, es müsste die alten URLs umleiten.

Code: Alles auswählen

add_action('template_redirect', function() {
		
    if (($_REQUEST['m_id']??'') == '601' && isset($_REQUEST['file']) && isset($GLOBALS['wpsg_sc'])) {
        
        $encoded_file = base64_decode($_REQUEST['file']);
        
        if ($encoded_file !== false) {
            
            $url = get_permalink(wpsg_ShopController::getShop()->get_option('wpsg_page_basket'))."&plugin=1&noheader=1&m_id=".$this->id."&order=".$_REQUEST['order_id']."&file=".rawurlencode($encoded_file)."&produkt=".$_REQUEST['produkt']."&chash=".$_REQUEST['chash']."\r\n\r\n";
            
            header('Redirect: '.$url);	
            exit;
            
        }
        
    }
    
}, 9);

Viele Grüße

Daschmi

[pnav]

Hallo,

Wow... ich weiß nicht ob ich lachen oder weinen soll über diesen Lösungsvorschlag. Es fühlt sich so an, als ob du diesen Code nicht getestet, sondern mir als Kunden einfach ungetestet vor die Füße geschmissen hast, sodass ich jetzt knapp 30 Minuten dran saß, um diese paar Zeilen zu debuggen und die Fehler zu beseitigen...

Folgende Fehler sind in den wenigen Zeilen Code:

• if ($encoded_file !== false) ist keine gültige Lösung auf valides base64. Viele nicht base64 kodierte Strings (wie z.B. Dateinamen) liefern eine base64_decode Rückgabe. Lösung bringt der 2. Parameter $strict = true

• Statt "&plugin=1 muss es "?plugin=1" heißen (bei unserer permapagelink config)

• Worauf soll m_id=".$this->id." referenzieren? $this ist ein ungültiger Ausdruck an der Stelle.

• order=".$_REQUEST['order_id'] - Tippfehler? Die Downloadlinks enthalten keinen order_id Parameter, "order" ist korrekt.

• header('Redirect: '.$url); Was soll Redirect für ein HTTP Header sein? Mit Location: funktioniert es.

Zudem listet PHPCS mit WordPress coding Standards noch folgende Notices für diesen Code:

phpcs: $_REQUEST data not unslashed before sanitization. Use wp_unslash() or similar
phpcs: Detected usage of a non-sanitized input variable: $_REQUEST['m_id']
phpcs: Detected usage of a non-sanitized input variable: $_REQUEST['order']
phpcs: Detected usage of a possibly undefined superglobal array index: $_REQUEST['order']. Use isset() or empty() to check the index exists before using it
...

[daschmi]

Moin,

das ganze war wirklich ungetestet und auch nur als Ansatz gedacht und schnell blind hingeschrieben. Aber danke für dein Feedback
Es war nur eine schnelle Idee, wie man das Problem lösen kann ohne die Anpassung einfach Rückgängig zu machen.

Ich habe ja geschrieben wir arbeiten an einem Plugin zur Abwärtskompatibilität was wir separat veröffentlichen werden für Nutzer die das Problem haben.

Viele Grüße

Daschmi

[daschmi]

Hi,

wir haben ein Plugin geschrieben, was bei Bedarf die alten URLs (die base64 kodiert waren) auf die neuen URLs umleitet. Damit funktionieren alte verschickte Links weiterhin.

Das Plugin kann kostenlos hier: https://wpshopgermany.maennchen1.de/wp- ... direct.zip

heruntergeladen werden.

Viele Grüße

Daschmi