BotDetect ASP CAPTCHA Known Issues
- [#4220851] BotDetect Audio CAPTCHA truncated in Firefox
- [#4220862] Google Chrome clients and audio CAPTCHA
- [#4220861] SSL offloading and audio CAPTCHA in IE
BotDetect Audio CAPTCHA truncated in Firefox
Issue ID
#4220851
Affected products
BotDetect ASP CAPTCHA v2.0.*
Affected clients
Firefox 2.0.x, 3.0.x
Status
3rd party issue - can not fix
Description
If you have IIS dynamic content compression enabled on your servers for BotDetect CAPTCHA paths, the audio CAPTCHA will only play the first few characters of the CAPTCHA code in Firefox browsers.
Steps to reproduce
- Open a page using the BotDetect ASP CAPTCHA in Firefox 2.0 or 3.0
- 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 "Open link in new tab") and playing it in Winamp works properly, there is probably a problem in communication between Firefox and the sound player plug-in (QuickTime on our test machines). Maybe the compressed content length is passed to the player instead of the full (uncompressed) one, which could cause only a part of the sound file to be played.
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.
If you want to continue compressing your .asp pages and other dynamic content, but disable compression for BotDetect requests, you could use a different extension for the LanapBotDetectHandler.asp file, which will not be included in the HcScriptFileExtensions property.
If you do this, you will also have to make sure the new extension is properly mapped to the ASP execution engine in IIS.
Google Chrome clients and audio CAPTCHA
Issue ID
#4220862
Affected products
BotDetect ASP CAPTCHA v2.0.*
Affected clients
Google Chrome 0.2.149.27, 0.2.149.29
Status
3rd party issue - can not fix
Description
In beta versions of Google Chrome the audio CAPTCHA played by clicking the speaker icon always contains a different code than is displayed in the CAPTCHA image.
Steps to reproduce
- Open a page using the BotDetect ASP CAPTCHA in Google Chrome
- Click the speaker icon - the spoken code will be wrong
- Try to validate the CAPTCHA using the spoken code - validation will fail
- Try to validate the CAPTCHA using the displayed code - validation will succeed
- Right-click the speaker icon and select "Open link in new tab", then click the captcha.wav file - the spoken code will be correct
Explanation
The issue cause can be seen in the following IIS logfile sample (slightly edited for easier reading):
05:19:21 GET /LanapBotDetectHandler.asp Command=CreateImage Chrome 0.2.149.29 - 05:19:26 GET /LanapBotDetectHandler.asp Command=CreateImage&d=1221085161052 Chrome 0.2.149.29 +ASPSESSIONIDQAQCSDRR=IBCNCFFAPJBKGFDNLIBFIBLO 05:19:28 GET /LanapBotDetectHandler.asp Command=CreateSound&d=1221085163229 Windows-Media-Player/10.00.00.4051 ASPSESSIONIDQAQCSCQQ=KNGDHDFAGDIFBPCPMBDAPIGC; +ASPSESSIONIDSCRBSCQR=GELBCEFAJEMMHGEGHOICCBEN 05:19:28 GET /LanapBotDetectHandler.asp Command=CreateSound&d=1221085163229 IE 6.0 ASPSESSIONIDQAQCSCQQ=KNGDHDFAGDIFBPCPMBDAPIGC; +ASPSESSIONIDSCRBSCQR=GELBCEFAJEMMHGEGHOICCBEN; +ASPSESSIONIDQAQCSDRR=JBCNCFFAIMEHBAPPIPAEAEFH
Those are the log entries generated by the following sequence of operations:
- Load the page in Google Chrome, inlcuding the CAPTCHA image
- Click the Reload Button to generate a new image (so we can see the ASP Session cookie used for the Chrome session)
- Click the Speaker icon to get the CAPTCHA sound
As the logfile shows, Chrome forwards the sound CAPTCHA request to Windows Media Player, which for some reason makes the sound request with the wrong ASP Session cookie (or in other cases, with no cookie at all). This was the case in all 10 test runs we did, and if you take a look at your IIS log entries, you will probably find a similar pattern.
Since ASP Session state is dependent on the cookie value, and there is no way to change it (short of writing our own ASP Session replacement), and since we are not sure why does Windows Media Player make the request with an invalid cookie value, there is little we can do to resolve this issue.
Workarounds
Note that the ASP.NET version of BotDetect doesn't have this problem (as you can test on our online demo), since it includes a fix for a similar issue caused by Windows Media Player (details in the FAQ item). Unfortunately, we can not use the same workaround in the ASP version of our product - since the ASP.NET version fixes it by modifying the Session state not to be dependent on cookies, and ASP Session state doesn't provide any equivalent customization options.
One thing you can try is changing the sound CAPTCHA link in your form from:
<a href='LanapBotDetectHandler.asp?Command=CreateSound'
onclick='LBD_LoadSound("SampleForm_SoundPlaceholder",
"LanapBotDetectHandler.asp?Command=CreateSound");return false;'
title="Speak the code">
<img src="speaker.gif" alt="Speak the code"/>
</a>
to
<a href='LanapBotDetectHandler.asp?Command=CreateSound'
title="Speak the code">
<img src="speaker.gif" alt="Speak the code" />
</a>
This will disable the JavaScript automatic playback of the sound file and show the standard file download dialog; since in that case the sound file will first be downloaded by Chrome (using the correct cookie) and only then opened in Windows Media Player, the pronounced code should match the CAPTCHA image. This makes for a less "smooth" user experience, but if Chrome users are a significant portion of your site's users it might be worth the trade-off. Or if you really want to provide full functionality to users with newest browsers, you might consider porting the page you want to protect with a CAPTCHA to ASP.NET.
SSL offloading and audio CAPTCHA in IE
Issue ID
#4220861
Affected products
BotDetect ASP CAPTCHA v2.0.*
Affected clients
IE 6.0, IE 7.0
Status
Pending
Description
If you use SSL offloading, i.e. HTTPS requests to your site are decrypted by a special proxy and forwarded to your web server over plain HTTP , IE users will be unable to use the audio CAPTCHA.
Steps to reproduce
- Open a page using the BotDetect ASP CAPTCHA over HTTPS in Internet Exploree 6.0 or 7.0
- Click the speaker icon - no sound will be played
- Right-click the speaker icon and select "Open link in new tab" - an error will occur, saying IE is unable to download the file
Explanation
The problem is caused by IE file downloads not working if the server sends a file over SSL with the no-cache header. IE interprets the header as a strict prohibition to save the file locally, which means the sound file is not downloaded on the client. Since the sound file first needs to be downloaded to be played, this means the CAPTCHA sound is never played.
In other browsers we tested this against (Firefox, Opera, Safari), this header is interpreted differently, meaning the sound file can be downloaded (and played), but is not reused. IE also works properly when not using SSL. In other words, it's the no-cache + SSL + IE use case that is problematic.
When not using SSL, the no-cache header is required, otherwise there are use cases when changing the CAPTCHA image doesn't result in the equivalent change in the CAPTCHA sound, since the browser reuses the old sound file.
So the solution we used in the latest versions of BotDetect is to send the no-cache header only if SSL is not used. In other words, the code is similar to:
If (Request.ServerVariables("HTTPS")="off") Then
Response.CacheControl = "no-cache"
Response.AddHeader "Pragma", "no-cache"
Response.Expires = -1
End If
Since this code is obviously executed on the web server, this will only work if the request is sent to the web server over SSL. But if the SSL offloading means that SSL requests are made to a special network device, which then decrypts the traffic and sends plain HTTP requests to the web server, the web server will not know the current request is made over SSL.
In other words, Request.ServerVariables("HTTPS") will be set to "off" at the point of execution even though the original request was made over SSL. This in turn will result in the no-cache header being sent to IE clients, returning the original problem.
Workarounds
Our component needs to handle the broadest possible range of browsers and use cases, so the general solution is non-trivial - despite SSL offloading, the web server still needs to know the request was originally sent over SSL, and send the appropriate headers accordingly. This could be achieved by sending a special sound request querystring parameter, which is set in the sound playing JavaScript depending how the client sees the page (HTTPS or plain HTTP), for example. We will investigate this solution in future versions of BotDetect.
You can try looking up your SSL offloading settings, maybe there is an existing solution for cases when the server needs to know it's being accessed via SSL even if it's offloaded. If the ASP built-in Request.ServerVariables("HTTPS") property can be made to work properly, that would solve the problem.
Also, if you are only going to use the CAPTCHA on pages accessed over SSL, you don't have to handle the plain HTTP use case – which means you can remove the SSL-detecting logic from the code altogether and just assume SSL is always used. You can make this change in the LanapBotDetectHandler.asp file your page uses.
