fix(contact): stop autofill from swallowing submissions - #45
Merged
Merged
Conversation
The honeypot was a text input named website_hp that browser autofill and password managers filled from a saved profile; the form then showed "Message sent" without posting anything. No submission had reached the API since deployment. The field is renamed hp_check, tagged so extensions skip it, and only the API inspects it. The time-to-submit check now uses the elapsed time the browser measured instead of comparing the browser's timestamp with the server clock, which dropped visitors whose clock ran ahead. Both drops are logged with their reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The contact form showed "Message sent" but no email arrived. The ingress log since 21 August holds no POST to
/api/contactfrom a browser, and the pod log has no contact entries: submissions never left the browser.Cause: the honeypot was a plain text input named
website_hp. Browser autofill and password-manager extensions fill off-screen inputs from a saved profile (Chrome ignoresautocomplete="off"for address data), and the form's submit handler returned "success" without posting whenever that field had a value.A second silent drop sat in the API: the time-to-submit check compared the browser's timestamp with the server clock, so any visitor whose clock ran ahead by a couple of seconds was dropped with a success response and no log line.
Fix
hp_check, tagged with the LastPass, 1Password and Bitwarden ignore attributes, and only inspected by the API. The client short-circuit is gone.elapsed_ms); the API no longer compares two clocks.[contact] dropped: ...with the reason. README notes what to grep for.Verified
Type-check, unit tests, build. Standalone server exercised: honeypot filled and a 800 ms submission both answer
okand log their reason; a normal submission reaches the delivery path. The rendered form carrieshp_checkand nowebsite_hporrendered_at. The SMTP path itself was confirmed working in production with a direct API call before this change.