BotDetect CAPTCHA Java FAQ

BotDetect Java Captcha library requires Java 5 or higher.

BotDetect Java Captcha library requires Servlet 2.3 or higher.

BotDetect Java Captcha library works with JSP 2.0 or higher.

BotDetect Java Captcha library works with JSF 1.2 or higher.

BotDetect uses CaptchaServlet class to serve Captcha images and sounds. For BotDetect to work properly, you must ensure that you have registered CaptchaServlet in your WEB-INF/web.xml file.

Traditional API requires Java Servlet Sessions.

Yes, it does not work by default. Because we have used the getRealPath() to determine the real system WEB-INF\BotDetectSounds path in the BotDetect Java Captcha library, this method returns null in Oracle WebLogic Server by default.

To make BotDetect Sounds works, you will need to change the behavior of getRealPath() by using the following configuration in your weblogic.xml file:

<weblogic-web-app>
  <container-descriptor>
    <show-archived-real-path-enabled>true</show-archived-real-path-enabled>
  </container-descriptor>
</weblogic-web-app>

Use the following API to find out which version of BotDetect Java you run:

Captcha.getLibInfo();

BotDetect will not work if BotDetect markup is added to webform on a server side, and then forms with Captcha are delivered through CDN.

Basically, the issue is that BotDetect markup that is added into your webform markup contains some parameters that are unique for each rendered Captcha.

Delivery through CDN freeze this parameters to values that are stored in CDN, and therefore Captcha fails to display, validate (or both depending of your implementation).

There are 2 ways to resolve this issue:

• To exclude webform containing BotDetect markup from being served through CDN:

  All of other content referenced (styles, images, scripts, etc...) in your web page source, can still be served through CDN so there will be no larger performance penalty.

  OR:

• To add BotDetect markup to your webform with JavaScript.

Please note:

Whatever approach you decide to go with, you still MUST exclude /botdetectcaptcha urls from being served through CDN.

It is not a bug but expected and built in default behavior.

Once requested audio is cached on a client side (because of performance) for future replay. If caching fails in particular brand of browser (or due to custom configuration) then the brand new captcha (with a different code) is generated. That is exactly what happens in IE because audio cannot be cached on a client side with it.

You may ask yourself why different code but not the same? Because of security reasons -- we don't want to play different audio files for the same captcha code. Different audio versions of the same challenge would provide an attacker with an opportunity to try to guess the same char repeatedly until he can have a highly confident guess.

We use a Let's Encrypt certificate on https://git.captcha.com, and it seems there is no "DST Root CA X3" certificate in your JDK's trusted certificates keystore.

Please check the $JAVA_HOME/jre/lib/security/cacerts file of your app server.

Here is where you can download the "DST Root CA X3" certificate:
https://letsencrypt.org/certificates/

You have most likely forgotten to include Captcha validation code in the Java script that processes your form's submitted data. You can see an example code snippet for Captcha validation in the How To Add BotDetect CAPTCHA Protection to JSP forms guide.

Also, you might want to take a look at the BotDetect Java integration examples that come with BotDetect downloads, starting with the JavaServer Pages Basic CAPTCHA integration code example.

You are right, and this behavior of the Captcha component is by design. Only one validation attempt is allowed per Captcha code for security purposes.

If we allowed multiple retries on solving the same Captcha, it would significantly lower the Captcha security, since bots could just brute-force different code values until they eventually got it right. Also, it would be much easier to write a bot which used OCR techniques to bypass the Captcha: if, for example, it could recognize two out of the five digits in the image, it would just have to brute-force the remaining three.

So a failed validation attempt (whether on the client- or server-side) always invalidates the current Captcha code. Successful server-side validations also remove the code (so we prevent cases where somebody solves just one Captcha and then keeps reusing it for multiple submissions).

Successful client-side validations (using the ValidationAttemptOrigin.CLIENT value) are the only ones that don't invalidate the current code, so you can also validate the same submitted values on the server-side once all form fields have been filled-out.

So basically, if the Captcha validation attempt wasn't successful, the Captcha image also needs to be reloaded and the previous user input cleared, since the old Captcha code has been invalidated.

The two ValidationAttemptOrigin values were added to support a specific use-case involving Ajax Captcha validation: If somebody starts with a regular full post-back Web Forms page using BotDetect Captcha, and wants to improve the accessibility of the form by performing asynchronous Captcha validation.

The improvement Ajax Captcha validation brings is that users will get faster feedback when they enter an incorrect Captcha code, and they won't have to reload the full form and other form values. When users enter a valid Captcha code, a full post-back is performed and the form is validated again on the server (since all client-side code is unsafe and can be tampered with by malicious clients).

So to support this use-case, we have to allow the same Captcha code to be successfully validated twice (once from an Ajax request, and once in the full form post-back). This is the reason why we added the ValidationAttemptOrigin.CLIENT flag, which signals the Captcha validation not to remove the successfully validated Code immediately (since it will need to be validated again in the full form post-back). All other validation attempts remove the stored Captcha code after one validation (regardless of the result) for security reasons.

In conclusion, ValidationAttemptOrigin.CLIENT is used when performing Ajax Captcha validation, and ValidationAttemptOrigin.SERVER is used when performing full post-back Captcha validation.

Users definitely shouldn't have to solve another Captcha if they enter the correct Captcha code, but (for example) username validation fails. The purpose of Captcha is to ensure the user is human, and once they solve it this purpose is fulfilled.

If you have to return them to the form because another field value needs to be corrected, it's best not to show them the Captcha at all.

See the JavaServer Pages form captcha code example to know how to display and validate the Captcha if it hasn't already been solved.

For security reasons, it is not possible to get the same BotDetect Captcha image on two page loads, nor to use the same code for more than one Captcha image.