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:
| 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.
| $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.
GefÀllt mir:
GefĂ€llt LĂ€dt…
