Ich stand gerade mal wieder vor dem Problem, wie ich in eine Smarty-Template-Datei Javascriptcode einfügen kann, ohne dass es Fehlermeldungen hagelt. Ich wußte noch, dass es irgendein Tag gibt, das nicht zu interpretierenden Code einschließt.
Für die Zukunft habe ich es mir gemerkt: {literal}
Mehr Infos gibt’s bei smarty.net
wieder mal etwas dazugelernt:
das automatische Runterladen per FTP einer Datei mit PHP hat bei all-inkl.com bei mir bisher eigentlich immer problemlos geklappt. Auf unserem neuen Server hakt die Sache jedoch plötzlich und es kommt zu der Warnung:
Could not open data connection to port
Nach längerem Suchen habe ich herausgefunden, dass man zuerst den Passivmodus einstellen muss und zwar mit dem Befehl:
ftp_pasv($conn_id, true);
jetzt klappt es wieder 
ich bin gerade dabei ein Zahlungsabwicklungsmodule, nämlich das von 1&1 stammende iPayment, in einem unserer zu betreuenden OnlineShops einzubauen. Das in der damaligen xtcommerce Shopversion vorhandene war nicht mehr aktuell und so habe ich hier ein Update gefunden.
Das Problem ist jetzt jedoch, dass durch das iPayment Modul die Kreditkarte sofort belastet wird. Das mag vielleicht bei Downloadartikeln recht sinnvoll sein. Wenn die Ware aber z.B. aktuell nicht ab Lager ist oder es sich um eine Vorbestellung handelt, dann ist das für den Kunden ziemlich ärgerlich.
Das iPayment-Technik-Handbuch gibt jedoch abhilfe. Für die Vorautorisierung, d.h. der Betrag wird für 28 Tage registriert und noch nicht abgebucht, muss man den Parameter trx_typ mit dem Wert ‘preauth’ übergeben.
Dies geschieht in der Datei /includes/modules/payment/ipayment.php.
Hier sucht man die Zeile
xtc_draw_hidden_field(’trx_paymenttyp’, ‘cc’).
und fügt direkt im Anschluß noch folgendes hinzu
xtc_draw_hidden_field(’trx_typ’, ‘preauth’).
Jetzt muss ich nur noch rausfinden, was es mit der Fehlermeldung “Die Zahlung wurde abgelehnt (ipayment-FPS/FDS).” auf sich hat. Und nein, meine beiden Kreditkarten sind nicht gesperrt oder überzogen … so wie es aussieht, bin ich für 1&1 ein Betrüger:
über Ihren ipayment Account wurde in den letzten Minuten versucht mehrere
erfolgreiche Transaktionen von der gleichen IP (XXX.XXX.XXX.XXX) aus
abzuwickeln. Für einen Onlineshop oder eine andere Online-Anwendung
ist dies untypisch, weshalb hier unser Betrugserkennungssystem alarmiert
und diese IP für einen gewissen Zeitraum blockiert hat.
Tja nun, dann muß ich wohl für heute Feierabend machen …
Ich bin gerade mal wieder dabei meine Kontaktformulare spamsicher zu machen. Captchas finde ich nicht wirklich benutzerfreundlich, deshalb fällt diese Möglichkeit weg.
Einen ersten Anhaltspunkt fand ich bei Paul Silver (Link). Er stellte fest, dass viele Spamer in den automatisch ausgefüllten Formularen spezielle Wörter verwenden: Content-Type, cc oder bcc. Enthält nun ein abgeschicktes Formular solche Phrasen, wird es verworfen.
Um einen weiteren Schutz zu haben, hatte ich mir überlegt, noch Input-Felder einzubauen. Diese sollen per CSS auf nicht sichtbar gesetzt werden. Wenn nun eines dieser Felder im abgeschickten Formular einen Wert enthält, weiß ich, dass es sich um einen Spamversuch handelt. Ein normaler Internetnutzer sieht ja das Feld nicht und kann es folgich auch nicht ausfüllen.
Hier mein Beispielcode:
function checkforspam() {
if ( preg_match( “/bcc:|Content-Type:/i”, implode( $_POST ) ) ){
return ‘Y’;
} else {
return ‘N’;
}
}if (checkforspam() == ‘N’ & $_POST['emailspam'] == “” & $_POST['namespam'] == “”) {
$message = “”;
foreach ($_POST as $key => $value) {
$message .= $key.”: “.$value.”\n”;
}
Die Input-Felder emailspam und namespam müssen natürlich im HTML-Formular eingebaut und mit dem Style “display: none” versehen werden.
Es wird sich zeigen, wie lange diese Methode funktioniert. Ich werd auf jeden Fall dranbleiben und ggf. updaten