Download & Extend

Encode emails in select drop-downs to prevent email harvesting

Project:Webform
Version:6.x-2.9
Component:Code
Category:feature request
Priority:normal
Assigned:Robin Monks
Status:closed (duplicate)

Issue Summary

This is based off the hashing solution presented in http://drupal.org/node/282436#comment-1068063 . It creates an additional table, and stores a hashed value, as well as the original e-mail in that table. This version is compliant with the new select grouping options.

This patch applies cleanly against 2.6. Patch sponsored by Prometheus Labor Communications.

Robin

AttachmentSize
Email Hashing for Webform - 5.x-2.6 patch9.1 KB
Email Hashing for Webform - 6.x-2.6 patch9.8 KB

Comments

#1

Status:needs review» reviewed & tested by the community

+2 Works well and using this on our sites without incident.

#2

This looks interesting and promising. Does this also fix #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters) if encoding the values?

#3

No, hashed emails would still be identical keys; so this would not fix the unique key issue (hence why I split it into a separate issue).

Robin

#4

+1 subscribe

#5

Where does this patch go, please?

#6

Was this ever considered for incorporating into the Webform code? Seems like it's a worthwhile addition.

#7

I would prefer a solution with simple numbers instead of hashing.
Just add a checkbox "use numbers as option keys on client side" to the settings for a multichoice field. We don't need an additional table to store the mapping, it can simply be stored in the form array (not accessible on client side).

#8

Version:6.x-2.x-dev»
Category:task» feature request
Status:reviewed & tested by the community» active

I'm moving this to the 3.x branch as new features are no longer being added to the 2.x branch. The 3.x branch has a very different way of handling e-mails that might make it much more feasible to implement a contact.module-like approach, where the e-mails are not part of the list of options at all, but instead tied to the e-mail configuration.

My thoughts on this would be the following workflow:

- Set up a webform with a select list. Give the select list whatever keys you want (or none at all).
- Visit the "E-mail" tab of the Webform configuration, add a new e-mail for the select component.
- Under the select component, enter in e-mails for each value of the select list (multiples or duplicates allowed easily here).

I've set this back to active because it's an entirely different approach than the current patch.

#9

Status:active» closed (duplicate)

We'll merge this with #282436: Multiple Options, Same Value in 'Select' Form Element (+ Protect from Spam Harvesters) again so I don't have to keep track of 2 issues.

#10

Version:» 6.x-2.9

I decided to not encode emails but rather insert something like "..._at_" at the end because all my recipients are in the same domain. So, I made a little module based on discussions here, and in setup of this module you need to insert mask and domain then use that defined mask everywhere in keys and it will be automatically replaced with domain. Maybe someone would like to try it.

AttachmentSize
webform_email_converter.tar_.gz 1.14 KB