Bonita and reCaptcha

Q&A
1

Hi

Has anyone tried to get Google’s “reCaptcha” working with a Bonita form?
I’ve tried but cant get the button to display, and I’m hoping someone has got it working and can clue me in on how.

Thanks
Chris

2

Yep…

  1. Register for a reCaptcha Account
  2. Register LOCALHOST as a valid host
  3. Keep the details page open (in another window)
  4. Open Bonitasoft
  5. Open UI
  6. Create a new test Custom Widget
  7. I tend to leave everything there as it helps prove the widget works or not, I then remove the default stuff after I know everything is OK
  8. Add https://www.google.com/recaptcha/api.js (from google documentation) as an Asset
  9. Add < div class=“g-recaptcha” data-sitekey=“your_site_key” >< /div > to the Template (NOTE remove spaces in < div > and < /div > I added to ensure you can see them)
  10. Change your_site_key to the site key from Google
  11. Save
  12. Create newForm
  13. Add Form Container
  14. Add Custom Widget
  15. Save
  16. Preview
  17. Voila! it works…

Now how you gonna use it - that’s up to you…

regards
Seán

PS: As this reply answers your question, please mark as resolved.

3

Thanks Sean.

As ever, your answer hit the nail on the head.

It was step 8 that I was doing differently (wrongly, as it turned out). I was adding a “< script >” tag into the template - and it was being ignored. Making it an asset instead cracked the problem.

BUT: there seems to be a random timing issue with your approach - unless you use also use the “async” and “callback” options (it failed for me about 1 in 10 times without them, but is predictably okay with them).

Chris

4

Not so much firewalls and network (it’s nippy enough here - and I’m working on “localhost” anyway for development) - it’s more that you cant predict the order of things. Viz: does the template load before the asset api js or visa versa? I’ve followed the load order in firefox and chrome’s dev tools - and it’s pretty predictable in Firefox, but Chrome is clearly more multi-threaded and the problem occurs when the api.js configured as an asset to the widget gets loaded BEFORE the model and/or controller. If anything: the problem is not slow down due to network, but a server/client that are fast enough to make race conditions more likely.

I’ve had to introduce a rescue step on a $timeout in the controller to handle the 10% or so cases where the API loads before the controller, and so cant find the callback. The result is that the capture frame doesn’t appear. The answer is for the controller to check the state of things on a timer after its initialization and call the call-back explicitly if the grecapture object exists (the api has loaded) but the capture iframe doesnt (api init has failed).

So far I’ve not had it fail with those safety guards in place.

5

Not a problem Chris, we’ve not seen the delay issues you talk about. Network and firewalls?

Glad it worked,
regards

6

That’s a very good summary of the issue, thanks.

I suggest you raise this as a bug report as it is not just reCaptcha that could fall prey to this. It may be the first visible instance of it but others may also be having the issue without understanding it.

Point the Bug report to this thread as well so we can all see it and follow.

I wonder if the same issue happens if the Asset is moved from the Widget to the Page… still this shouldn’t matter, Assets should always be loaded before the template.

regards