Forum
Are hidden email form fields bad?
Hi
I'm building a customer feedback form for my client, they have multiple projects in a collection, and each project has a unique email address.
I'm trying to create a safe way to use one form to send feedback to the unique email address of each project.
My first attempt was to pull all the email addresses from the projects collection into a <select> tag. This would allow the user to select a specific project to provide feedback.
This output:
<select id="form1_projectEmail" name="projectEmail" placeholder="Select a project" required="required">
<option selected="selected" value="">Select a project</option>
<option value="j.smith@bedford-gardens.com">Bedford Gardens</option>
<option value="demo@another-project.com">Another project</option>
<option value="test3@test-project3.com">Test project 3</option>
<option value="info@demotest.co.uk">Test Project Name</option>
</select>
However, Drew kindly informed me this would expose the form to spammers.
Back to the drawing board...
My current solution uses slug, skip-template and a few other bits to output a single email address into a `hidden field. Like this:
<!-- Hidden fields pulled in from projects collection -->
<perch:input id="mailText" label="Project email" type="hidden" />
This outputs:
<!-- Hidden fields pulled in from projects collection -->
<input id="form1_mailText" name="mailText" value="test3@test-project3.com" type="hidden" />
- Is this ok, or would this also expose the form to spam?
- The email address is only present at the time of filling in the form
- Unlike my first attempt the form isn't on a dedicated 'customer feedback' page, it's only displayed when a
phpelseifcondition is true
If someone can edit the form in their browser to change the address the email gets sent to, then it can be used for spam.
As long as the email address is present in the final generated HTML code in the client's browser the address is exposed. In one of our projects in our corporate network, we need a project identifier in the field value and in the backend process after form submission, each project identifier was tagged to a corresponding email address.
@Shubhojyoti thanks for your input.
Drew suggested something similar in another post, unfortunately (in this specific case) setting up filters at the server level and managing them for future projects wouldn't be ideal.
The way the form works now is dynamic, it doesn't matter how many projects/email addresses are added. It's set and forget for the client. It's a real shame it's not a safe solution.
Hi Stephen,
One option (though not a great one), is to have the emails all sent to one address, but with subject lines that are generated from a variable set by a select, so something like
Feedback on {project}in the form settings . Then you can use subject line filters in whatever email program they have to then forward on to the relevant addresses.@Drew, the screenshot below shows the sending email settings.
The red highlight shows the dynamic ID I'm using to submit the form to the email address associated with the project. This is taken from a hidden field in the form - not a safe option.
The green bar shows a
selectmenu that makes all theIDsfrom the form available, including an email address. This feels like it's doing something similar to what I'm trying to achieve.The email address for the ReplyTo header isn't fixed, yet it's secure because it's not part of the form HTML.
Is it feasible to implement something similar for the email address(es) field in a future forms app update?
@Stephen assuming the domain is always the same, can you have
{mailText}@domain.comas the email address? Then the whole email isn't exposed on the form front end.@Mike yes good idea, I might have to consider it.
It feels like this should be able to done via the website/forms app. It can, the solution I've hacked together works, it's just not safe.
If there's a chance the client will forget to update a filter for a new project they probably will.
@Mike Unfortunately each project has a completely different email address, not on the same domain.
I like your blue sky thinking! :)
I think I may have to go with your suggestion of submitting the form to one email address, include the project name in the subject and explain to the client they will have to setup a filter to forward the email to the relevant address.
Not ideal, but at least it'll be safe.
Haha well I try :)
{mailText}@{mailDomain}....?@Mike I think that would still output a
value=in the HTML of the form that could be edited within the browser.Unless I'm mistaken, the only way I know of getting the form to
seetheid="mailText"is to pass it in as a hidden field.Thanks for your suggestions though!
In older sites we used (not with any CMS but hand coded HTML), the formmail script we used, we added a random string in place of @ e.g. instead of alias@domain.com, we used alias-WEAREGEEKSBUTWEWILLLIVE-domain.com :) The formmail script used to strip the expected field between -- and replaced with @ and went on. Though not an ideal solution but it did work for a long time.