dnsquery.org seems to work and has no rate limit.

Despite it not having any visual work done to it in about 10 years, it seems like it is still maintained to some extent, and the domain was last renewed earlier this year.

That one is too slow and doesn't show reverse lookup names. I'd rather get rid of the link if there aren't any good ones.

Quote: Originally posted by miqrogroove

I might have to delete the traceroute link. Have you found any alternative?

https://mxtoolbox.com/SuperTool.aspx?action=trace:%20ip

The reCAPTCHA Classic admin dashboard threw a flag for the change in traffic stats.

"We detected that your site is verifying reCAPTCHA passed solutions less than 50% of the time. This could indicate a problem with your integration with reCAPTCHA. Please see our developer site for more information."

I went through the first few steps of the XMB registration process again and confirmed it is working normally. So the admins using this feature can expect that flag to show up after switching to XMB v1.10.

Not to sidetrack, but is email OTP verification worth looking into?

Edit: Apparently password/email verification has been an option since forever. I had never noticed this; on my board we always used 1 IP a day and a hack (the additional questions mod). I was thinking of the 6 digit random numbers, but now that doesn't make sense. Carry on; I was never here.

I'm pretty sure that's already a thing anyway: the verification used here sends a random password, at least...

Unless you mean something like sending a one time verification code to the email address associated with the account when logging in from a new location...

Also I need to stop using elipses.

Registration script now provides soft errors for the required fields: Username, password, and e-mail address. When at least one of those is invalid, the profile creation step will save all inputs and refresh with a message at the top. This enables the user to continue registration without going back to the captcha step after every mistake.

Switching to an "invisible" site key didn't cause any problems. In fact, the v2 API doesn't seem to care what the console settings are, nor does it inform the client which type of key it is. It just follows the rendering in our templates and shows the checkbox. Adjusting the template to use a different element switches the captcha to invisible mode.

Now I need to look at the siteverify API v3 and figure out if we need to support that too, and how is it any different from the Enterprise API.

Here's the first instance of breakage: If the admin supplies a v3 classic key and attempts to render a captcha checkbox, the box renders with an error message, "ERROR for site owner: Invalid key type".

This might not happen in all cases. Within the Cloud/Enterprise console, it appears possible to create a challenge-type key. I need to try all of those settings to figure out how to explain this to our users.

So, two more things.

When creating a "Challenge" key through the Enterprise API, it returns a v2 type response.

When that same key is rendered as invisible, it renders with another error, "This site key is not enabled for the invisible captcha."

This is really confusing. I will stare at it for a while and hopefully see the larger pattern.

Now running with a new reCAPTCHA key generated by Google Cloud with the checkbox challenge disabled. I'm happy with the results so far and marked this feature resolved.

Quote: Originally posted by miqrogroove

That one is too slow and doesn't show reverse lookup names. I'd rather get rid of the link if there aren't any good ones.

Possible encoding error in that post. I need to review what happened there. Some of the later posts had apostrophes with no problem.

I see in the commit history there was an inconsistency between the July 2 and July 3 changes. So that was simply a bug during the alpha and I will edit the post to resolve that hiccup.

The reason it only showed up now is because the old post format used raw quotes and the introduction of encoded quotes was invisible until the upgrade. The upgrade re-encoded all HTML, so any unexpected quote encoding would become double-encoded.