BotDetect ASP Classic CAPTCHA Known Issues

documentation > asp classic captcha > release notes

This page lists known issues with BotDetect ASP Classic Captcha, with explanations why they occur and workaround suggestions.

Server-Side Compression Causes Problems With BotDetect CAPTCHA Sound

Issue ID

#4230851

Affected products

All versions of BotDetect ASP Captcha

Affected servers

All versions of IIS

Affected clients

Internet Explorer 6.0, Firefox 2.x, 3.x

Status

3rd party issue – cannot fix

Description

If you have IIS dynamic content compression enabled on your servers for BotDetect Captcha paths, the Captcha sound will not play in IE 6.0, and will only play the first few characters of the Captcha code in Firefox.

Steps to reproduce

IE 6.0:

Open a page using the BotDetect ASP Captcha in IE 6.0
Click the speaker icon – the Captcha sound will not be played
Right-click the speaker icon and select "Save target as..." – the sound file saved will contain the full Captcha code

Firefox:

Open a page using the BotDetect ASP Captcha in Firefox 2.0 or 3.x
Click the speaker icon – only the starting characters of the code will be played (for example, the first 3 characters of a 5-character Captcha code)
Right-click the speaker icon and select "Open link in new tab" – the sound file will contain the full Captcha code

Explanation

This issue only occurs when you have IIS dynamic content compression enabled for .asp paths on your servers.

Since downloading the file (by right-clicking the speaker icon and selecting "Save target as...") and playing it in Winamp works properly, there is probably a problem in communication between browsers and the sound player plug-ins they use. Maybe the compressed content length is passed to the player instead of the full (uncompressed) one, which could cause the sound file playback to break.

Workarounds

The issue can be resolved by disabling gzip compression for the Captcha sounds. The simplest way to do is by setting the IIS metabase property:

cscript c:\Inetpub\AdminScripts\adsutil.vbs SET 
  W3SVC/Filters/Compression/gzip/HcDoDynamicCompression "FALSE"
		
iisreset

Please note that this will disable compression for all content with types defined in the HcScriptFileExtensions property.

[back to top]

BotDetect Captcha Validation Fails for Brazilian Visitors Using IE With Gbplugin (G-Buster Browser Defense)

Issue ID

#4230862

Affected products

BotDetect ASP Classic Captcha v1.0.1 - v3.0.7

Affected servers

All versions of IIS

Affected clients

All versions of Internet Explorer

Status

Fixed in v3.0.8

Description

When using IE with Gbplugin, validation of the Captcha code displayed in the Captcha image will always fail, while validation of the code spoken in the Captcha image will work correctly.

Steps to reproduce

Open a page using BotDetect ASP Classic Captcha in IE with Gbplugin
Retype the Captcha code from the image – Captcha validation will fail
Click the Captcha sound icon, and retype the spoken code – Captcha validation will succeed
Restart IE with Gbplugin disabled, and revisit the page
Retype the Captcha code from the image – Captcha validation will succeed

Explanation

Gbplugin makes a second Captcha image request which doesn't update the image displayed in the browser. The Http request workflow is simple:

The first Captcha image request (made by IE) comes to the server, and generates the first Captcha code.
A second Http request for the exact same Captcha image comes (made by Gbplugin), and changes the code stored on the server for that particular Captcha test instance to another value.
If the Captcha sound icon is clicked, the Captcha sound request uses the most up-to-date code stored on the server for the given ASP Session.

Since the request made by Gbplugin doesn't update the image in the browser, IE is still displaying the first code generated. Consequentially, the Captcha code from the image is not the one stored on the server and can't be validated, while the code from the Captcha sound is up to date and validates correctly.

BotDetect always generates a new Captcha code for each incoming Captcha image request. This is a security requirement: to prevent automated analysis, each Captcha image is randomized within the given parameters and it's not possible to re-use Captcha codes. So these "invisible" requests made by Gbplugin are a problem.

Workarounds

BotDetect v3.0.8 implements a workaround for this issue, recognizing GbPlugin requests by user agent and avoiding new Captcha image generation.

For older versions of BotDetect: If there is a way to configure Gbplugin to either update the image displayed in the browser when it makes its request, or use a different Session cookie to avoid overwriting user data, it should take care of the problem. Otherwise, it will probably be necessary to disable Gbplugin to make the Captcha Http request workflow normal.

[back to top]

BotDetect Audio CAPTCHA Not Playing in IE When Using Global `no-cache` Headers and SSL

Issue ID

#4230861

Affected products

All versions of BotDetect ASP Captcha

Affected servers

All versions of IIS

Affected clients

All versions of Internet Explorer

Status

3rd party issue – cannot fix

Description

If you configure your server to send no-cache headers with every Http response on a site that is accessed over SSL, BotDetect Captcha sound will not work for IE users.

Steps to reproduce

Modify the IIS settings for Http Headers, adding the following custom Http header for the whole site / virtual directory: Pragma: no-cache or Cache-Control: no-cache.
Open a page to which these settings apply and which is using BotDetect Captcha over Https
Click the speaker icon – the sound will not be played
Right-click the speaker icon and select "Save target as..." – when you try to download the .wav file it will fail with the following error: 'Internet Explorer cannot download CaptchaHandler.asp from localhost. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.'

Explanation

This issue is caused by IE treating all no-cache headers as a strict prohibition the save files when using SSL. Since the .wav file with the Captcha sound can not be saved on the client, it can also not be played. BotDetect Captcha automatically detects SSL and avoids sending no-cache headers in such cases, but if you apply a server-wide or site-wide custom Http header by modifying IIS settings, you will override this logic and your users will experience this problem.