Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /var/www/clients/client1/web22/web/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /var/www/clients/client1/web22/web/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /var/www/clients/client1/web22/web/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Wenn man von Nutzern Daten in irgendeiner Art erhebt, in der Regel via eines Online-Formulars und man Aufgrund des angestossenen Vorgangs reagieren möchte, zum Beispiel dem Versenden von Newslettern, kommt man um ein sogenanntes Double Opt-In nicht drum herum, wenn man sich nicht mit Schadensersatzansprüchen des Nutzers herumschlagen möchte, weil dieser vielleicht unerwünschte E-Mails oder Anrufe erhalten hat.
Wir haben bisher immer alle Benutzerdaten bei diesem Prozess in Datenbanken gesichert, was natürlich bedeutet, dass man den Nutzer zusätzlich auf Datenschutz-Bestimmungen hinweisen muss. Je nach Formulierungen ein weiterer juristischer Knackpunkt. Auf der technischen Seite wird man gezwungen eine Datenbank aufzusetzen, diese Daten zu pflegen und gegebenenfalls per definiertem Regelwerk den Datenbestand wieder zu bereinigen. Wie man sieht, im laufe der Zeit nicht wenig Aufwand, den man sich damit einfängt.
Ich muss zugegeben, es gibt Szenarien, wo man nicht darum herum kommt, die oben genannten Punkte alle zu berücksichtigen, aber wir hatten letztens den Fall, dass Daten via eines Bestellformulars für Probefahrten direkt an ein CRM (Customer-Relationship-Management) weitergeleitet werden sollen und wir die Datenvorhaltung lediglich für das Double Opt-In benötigen. Da kam ein ehemaliger Kollege von mir auf die Idee, doch alles via E-Mail inkl. der Daten per Get-Parameter zu übergeben. Da in diesem Fall sämtliche Daten in dem Link für das Double Opt-In innerhalb der E-Mail sind, benötigen wir hier keine weitere Instanz, um die Daten zu speichern.
Damit nicht jeder sofort erkennt, was da versendet wird, sollte man den Wert des Get-Parameters maskieren, zum Beispiel mit der PHP-Funktion base64_encode. Noch besser wäre es, das ganze zu verschlüsseln, wobei sich hier in PHP die mcrypt-Library eignet. Aus dem ganzen könnte dann folgende Klasse entstehen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | class Encryption { protected $key = 'irgendein zufalls-salt'; public function encrypt($value){ if (!$value) { return false; } $key = $this->key; $text = $value; $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB); $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND); $crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv); $encoded = trim(urlencode(base64_encode(bzcompress($crypttext)))); return $encoded; } public function decrypt($value){ if (!$value) { return false; } $key = $this->key; $crypttext = bzdecompress(base64_decode($value)); $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB); $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND); $decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $crypttext, MCRYPT_MODE_ECB, $iv); return trim($decrypttext); } } |
Nun braucht man einen passenden String, den man mit der oben aufgeführten Klasse verschlüsseln möchte. Ich fand einen JSON Formatierten String für diesen Zweck ideal, da man ja am Ende die Daten wieder irgendwie nach Keys und Values auflösen möchte. Hier kann man entweder mit entsprechenden Libraries einen JSON String erstellen (JSON Encode), oder, da das Format recht überschaubar ist, den String selbst erstellen.
Ich habe mich für Letzteres entschieden und am Ende sollte das dann so oder ähnlich aussehen. Das Ergebnis wird dann für das Double Opt-In via E-Mail an den User gesendet. Die Daten kommen aus einem vorher ausgefüllten Formular:
1 2 3 4 5 6 7 8 9 10 11 12 13 | require_once 'lib/Encryption.php'; $crypt = new Encryption(); $request = '{"fn":"' . $_REQUEST['firstname'] . '","ln":"' . $_REQUEST['lastname'] . '","em":"' . $_REQUEST['email']. '"}'; $request = $crypt->encrypt($request); // Das Ergebnis dann via Mail Funktion an User versenden // und den Request als Parameter an eine entsprechende // URL in der E-Mail hängen z.b.: $message = '<a href="http://www.deinedomain.tld/activate.php?r=$request">Hier klicken</a>'; |
Ich habe den String vor allem selbst erstellt, um die Möglichkeit zu haben, die Key-Namen um einiges zu verkürzen, damit der String bei mehreren Feldern nicht zu lang wird. URLs sollten eine länge von ca. 2000 Zeichen nicht übersteigen und da beim Verschlüsseln, trotz des komprimierens die Länge etwas zunimmt, schadet es nicht, dort zu sparen, wo es geht und Sinn macht.
Der User erhält eine E-Mail, wenn er korrekterweise der richtige Empfänger ist, wird er auf den Link klicken und auf der Zielseite wird der verschlüsselte Wert wieder dekodiert, das JSON Objekt wieder in ein Array umgewandelt und die Daten dann weiter verarbeitet, zum Beispiel an ein externes CRM geschickt.
1 2 3 | $crypt = new Encryption(); $data = $crypt->decrypt($data); $data = json_decode($data); |
Wie man sieht, kommt man so um eine eigene Datenhaltung herum und spart sich eine Menge Aufwand.
It is a superb suggestions specifically to people new to blogosphere, temporary and correct information… Many thanks for sharing this 1. A ought to examine write-up.
Hello there, just required you to know I he added your website to my Google bookmarks due to your layout. But seriously, I feel your web internet site has 1 in the freshest theme I??ve came across. It extremely helps make reading through your website significantly easier.
Hi Dwayne,
it´s a free WordPress Theme by Drew Stauffer and you can obtain it here: http://wordpress.org/extend/themes/elements-of-seo
I like it, because it´s not overloaded.