Error submiting the form to create a new event #33

Activity

1. yoandresaav

   added

   bugSomething isn't workingSomething isn't working

   on Sep 7, 2026
2. pullfrog commented on Sep 7, 2026

   

   pullfrogbot

   on Sep 7, 2026 – with Pullfrog

   Contributor

   More actions

     ^{｜ Build this ➔ ｜ Make a plan ➔}
3. MinosChatzidakis commented on Sep 7, 2026

   

   MinosChatzidakis

   on Sep 7, 2026

   More actions

   Hi, I am neither the author nor a maintainer of this project, however I encountered the same issue a couple of weeks ago.

   After looking around the source code, I found what you are pointing out in your screenshot of the code. A honeypot field not visible to humans (named 'company' if i remember correctly), meant to trick bots into filling it out, thus exposing themselves (humans can't possibly fill it out if they don't see it). So this seems like a clever trick which produces a generic error.

   Filling out the form automatically using google's autofill was what caused the error for me, whereas manually filling the visible fields did not trigger the honeypot. So my guess is that google's autofill sees the invisible to you and me field and fills it out, resulting in calnode thinking you are a bot,

   What worked for me was obviously not using google's autofill, but that is not a long-term solution, and one cannot expect their users to not use it either. So I ended up renaming the hidden field into 'url'. Something tempting for bots but not something google might know how to fill (certainly less likely than 'company').

   Hope that helps.
4. distronode-com commented on Sep 17, 2026

   

   distronode-com

   on Sep 17, 2026

   Contributor

   More actions

   @MinosChatzidakis's diagnosis was right. Chrome matches both the "Company" label and name="company" against its company-name pattern, and fills the field from an address profile even with autocomplete="off" set. #51 drops the label and renames the input to name="hp", a name that matches none of Chromium's autofill patterns. The API field stays company, so the embed widget and any API client are unaffected.

   👍React with 👍1Reacted by Minos Chatzidakis
5. shockalotti commented on Sep 17, 2026

   

   shockalotti

   on Sep 17, 2026

   Contributor

   More actions

   Found it - and your own description names the culprit: "the company came with data".

   company is the anti-bot honeypot on the booking form. Any submission carrying a non-empty company value is rejected with 400 invalid submission (plus a booking rejected: honeypot filled line in the server log). You did nothing wrong: browsers map a field literally named company to the organization autofill entry, ignoring `autocomplete="off"", and fill the invisible field for real humans - who are then told they're bots. Password managers and form fillers do the same.

   Fixed on branch fix/mcp-bearer-archived: the honeypot is renamed to hp_extra on the booking page and the embed widget (the manage page never had the field). The stale company key is now just an ignored unknown field, so older embeds keep working with no flag day. Covered by TestCreateBooking_honeypotRejected (bots still caught) and TestCreateBooking_legacyCompanyFieldIgnored (autofilled humans sail through).

   To confirm this was your exact hit: which browser were you using, and do you have organization autofill or a password manager active? If the server log from your attempt survives, booking rejected: honeypot filled at that timestamp would settle it.
6. shockalotti

   added a commit that references this issue on Sep 17, 2026

   fix(booking): rename honeypot off the autofill-mapped company name (#33)

   ...

   86cc414
7. shockalotti commented on Sep 17, 2026

   

   shockalotti

   on Sep 17, 2026

   Contributor

   More actions

   Update: the rename is now live in production. I smoke-tested a normal visitor booking and it goes through fine.

   One gap I have to be honest about: I could not test the actual autofill path. I just migrated to a fresh machine (Omarchy) and my Chrome has no company/organization data saved, so my browser never would have sprung the old trap either. The regression proof so far is automated (TestCreateBooking_legacyCompanyFieldIgnored + TestCreateBooking_honeypotRejected).

   @yoandresaav - could you verify on your side? With your usual browser profile (the one with organization autofill that triggered the original 400), a booking should now succeed. If it still fails, the server log line booking rejected: honeypot filled at your attempt time would tell us the trap is still catching you, versus a different 400 cause.
8. shockalotti commented on Sep 17, 2026

   

   shockalotti

   on Sep 17, 2026

   Contributor

   More actions

   Fixed on main via #57 (commit 86cc414 - honeypot renamed off the autofill-mapped company name). Reopen if you still see it.
9. shockalotti

   closed this as completedon Sep 17, 2026