We were commissioned, earlier this week, to integrate reCAPTCHA with JComments on a website belonging to a super-major news company.
Large companies usually have 2 environments, one called dev (for development), and one called prod (for production). Our job was to make the reCAPTCHA work on the development environment, and then, once everything’s OK, move the work to production.
The website was using Joomla 2.5, so all that we needed to do was to set the private and public key in Joomla’s Captcha – ReCaptcha plugin, and then add the necessary code to the right places in JComments (we will explain how we did this in a later post). The reCAPTCHA worked (after a lot of code-struggling) on the development environment: it was displaying properly and it was submitting properly. In other words, when the captcha was wrong, the comment was not saved and the user was requested to re-enter the captcha. When the captcha was correct, it was submitting properly. After the testing was done, we decided to move this to the production server. We thought that everything is going to work smoothly there, right? Wrong!
When the work was moved to production, we all assumed that everything will function as it should, and, at first glance, it did, since the captcha was being displayed properly. However, when we tried to save the comment, the form took forever to submit and eventually an error message told us that the captcha was wrong (even though it was correct). Also, even when the submission was wrong, the form took forever to submit (well, not really forever, but, in our business, 30 seconds is forever)!
After a lot of hair-pulling, nail-biting, and advil-swallowing, we narrowed down the problem to the following line in the file recaptcha.php which is located under the plugins/captcha/recaptcha folder:
while (!feof($fs))
$fs (in case you didn’t have time to read that file), is a socket handle open to the Google’s reCAPTCHA website. So, the problem was that the application was not able to read from that socket. We thought that the problem was related to the PHP instance on the production environment (we suspected that allow_url_fopen was set to No), but, to our surprise, the php.ini file on production was identical to that on development. We then thought that it might be something in the .htaccess file, but again, both .htaccess files were identical (dev and prod).
We then changed the plugin to use curl (instead of fsockopen) to connect to the reCAPTCHA server, and while this worked on the development server, it still didn’t work on the production server. At this point, we became sure that the problem had to do with the firewall.
So, we informed the networking team of the problem, and they discovered the cause: The development environment was bypassing the proxy, while the production environment was running behind the proxy. We did a quick research on the problem, and it turned out that Google knows about this and already has a solution. In short, the networking team had to whitelist some IPs (Google IPs) on the firewall, and they did, and that fixed the problem! Hurray!
If you have problems with reCAPTCHA on your Joomla website, then feel free to contact us. We will fix those problems for a very affordable fee and in no time!