reCAPTCHA in Sign Up Form block

Publishing help Project settings
1

Hello, I’m attempting to add a reCAPTCHA to my Sign Up page and I’m having an issue actually dropping a reCAPTCHA element into my Sign Up Form block.

I’ve generated and added my v2 API keys to the Site Settings > Forms > reCAPTCHA validation fields. As you can see from the image below, I’ve also made sure to enable reCAPTCHA validation on all forms. (I’ve also published to make sure the changes are live.)

reCaptcha-webflow-settings
reCaptcha-webflow-settings1248×802 71.3 KB

From there, I created a demo form and dropped a reCAPTCHA into it for testing. As you can see from the image below, it displays the “This is a Preview” text, which tells me it appears set up correctly.

webflow-active-reCaptcha
webflow-active-reCaptcha481×336 5.58 KB

After publishing the test form and navigating to my staging site, I have a form with a reCAPTCHA and it works! Yay! So easy, so fast.

Now that I have reCAPTCHA enabled, I’ve run into a bit of a snag with my Sign Up page. I’m using the built in Webflow users to handle simple gated content. I’ve successfully built a sign up form and have created users with it. Also, yay!

The issue now is that I can’t drop a reCAPTCHA element into my Sign Up Form block. No matter where I try to drop it in the block, I always receive the message, “reCAPTCHA can only be placed in a Form”. But wait, isn’t the Sign Up Form block a form? I’m not seeing the issue, but I just cannot drop one in there.

The only thing I’ve done to successfully get it into the block is drop another form block, with the reCAPTCHA, into my Sign Up Form block. At least that will render it. But it’s useless at that point because that doesn’t validate the parent form. Yes, I can do some custom JS to pass the validation from the child form to the parent form, but I feel like there is probably another way that I’m missing.

So, my main question is, Why can’t I, or How can I, add my reCAPTCHA to my Sign Up Form block?

For some additional information, this seems to be the case on all Form Blocks related to authentication. Why is that? Is there any documentation I can read as to how those blocks function under the hood so that I can better understand and work with them?

Additionally, I feel that I should note that despite having enabled reCAPTCHA validation on all forms, I can still submit my Sign Up form and create users without a reCAPTCHA block. I can perhaps overlook this, but I’m receiving the “General error” message for all form errors. I think that is because the reCAPTCHA is not being set and there is no specific message for that. So it overrules any additional errors, such as invalid password.

1 Like
2

The Forms used in User Accounts sign-up, log-in, and user-account pages, as well as the forms used in ECom are “special” forms that follow special rules on what they contain and how they can be configured.

Recaptcha is one example of this.

Incidentally I think the underlying mechanics are quite different. A typical form POSTs to a webhook with form data. I’d guess that forms like log-in and sign-up are processed entirely by script and not POSTed by the browser.

There may be built-in bot-detection mechanics like a honeypot, etc. I haven’t tested.

Are you getting a lot of robo signups?

1 Like
3

That’s what I was thinking. Ironically, a honeypot was going to be what I recommended as an alternative if this didn’t pan out. I’m not seeing any invisible or hidden fields added to the form on my staging site though, so I’m not too sure.

Thankfully I’m not dealing with a lot of bot submissions, truely I won’t be handling a lot of users either. However, I’m trying to set up my client for the future and would like to assure them that I’ve taken all necessary precautions. This is also why I was wanting some documentation, if any existed. So that I could properly vocalize to them how things are handled.

Do you maybe have any insight as to why my Sign Up form would always display the Generic error message instead of say an Invalid Password message? Even if the error is indeed invalid password? Thank you for the help by the way!

4

I just checked and my assumption that it’s a script-based login is correct, so a honeypot is not useful here. You can see the process in the network traffic during the login process, it’s a GraphQL query to Apollo.

This is what I see…

image
image472×143 8.93 KB

Which is generated by webflow.js.

In a security context this is best practice. Any information you give such as “unknown email”, “wrong password” is very useful to hackers, because they can determine what they have correctly guessed.

If you look at the Apollo response directly, it doesn’t matter whether you failed on the username or on the password, you get the same error. That’s 100% the right way to do it for security, even though legit users might prefer a hint on where they’ve messed up.

Nice work Webflow :clap:

But, inconvenient, yes. Security is often the enemy of usability.

[
    {
        "errors": [
            {
                "message": "Invalid credentials",
                "locations": [
                    {
                        "line": 2,
                        "column": 3
                    }
                ],
                "path": [
                    "usysCreateSession"
                ],
                "extensions": {
                    "code": "UsysInvalidCredentials"
                }
            }
        ],
        "data": null
    }
]
5

I will take inconvenient over insecure any day of the week! You’re absolutely correct on the information disclosure. I just assumed that, because they have separate messages in the editor for separate error types, it was already implemented. So I figured I’d take advantage of it. But I’m totally content with just a single generic message.

Thank you so much for this information, it is exactly what I was looking for! Cheers!

2 Likes