4

The Google Invisible Recaptcha docs say that their captcha v3 can be used in two ways:

  1. On form submissions
  2. On page loads

Page loads are essentially GET HTTP requests. I'm in need to validate a user using recaptcha v3 on a particular GET request. In short, it is a search results page, that searches through the database based on the parameters provided in the GET request, and returns a page of results.

I'm at loss how I can implement the recaptcha on page load. What's is the point of determining that this client is a bot, when we have already loaded the page? Or am I missing something here?

nvkrj
  • 1,002
  • 1
  • 7
  • 17

2 Answers2

1

I've been taking a look into this and I think the reason they suggest it can work on page loads are:

  • It helps them build up a profile of normal visitor interaction on a site over time. For example it would be unusual for a real user to try and submit a product review without having visited the product page first.

  • One example they give for a home page is being able to see a cohesive view of your traffic on the admin console while filtering scrapers.

For your use case which is similar to what I had in mind because their JavaScript has to run in the client browser after the page has been loaded the only solution I've thought of is:

Once you get their response back fire off an Ajax request to your server to verify it against your private key and then return either the results or an empty dataset / error. Personally I decided not to go ahead with that method because it means the pages will never be indexed by search engines and it would also give a worse user experience by adding to the page load time and showing blank results for some time.

PeterJ
  • 3,705
  • 28
  • 51
  • 71
1

I don't think it's possible. This comes from my experience with the V2 api, but I assume V3 is the same.

GET requests have to be idempotent, but recaptcha tokens are one time use only. So if you send a recaptcha token along with a GET request, the token won't be valid to be used again, so you can't run the same GET request again, so it wouldn't be idempotent.

The solution I tried ended up leading me to a bunch of problems. I ended up just having the same URL be accessible through a GET request or a POST request. When accessed through the GET request, the client would just send an ajax request to Google/recaptcha and get a verification token, and then POST to the same URL while also sending the recaptcha token as a (non url, ie in the http request body) parameter.

This lead to problems besides requiring two page loads, because when the user clicked back from the POST response page, it would take them back to the GET page which would make the POST request and end up back at the POST page again. I looked through the browser history api and never found a good solution. My hack was to just replace the GET request page's URL using history.replaceState() before firing off the POST request. I set the URL to my homepage, so that when someone clicked back from the POST response page, it just took them to my homepage. But then the browser's back forward cache started to make things all buggy, and I don't think there is a solution that works across all browsers. In the future if there is a reliable way to tell if someone arrived at a page using the back button or the forward button and exactly which of the two is the case, then the intermediary page (the GET request page) could just use history.back() or history.forward() to skip past the intermediary page.

The only solution I can think of is to use client side rendering. The GET request page should fire off an ajax/fetch call, get a recaptcha token, and then make another ajax/fetch call to your server with the token, receive whatever data it needs in response, and then use client side rendering. Of course this can have its own problems with SEO and with library compatibility if you are using libraries that depend on server side rendering.

Kevin Wheeler
  • 1,331
  • 2
  • 15
  • 24