Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Uri/Uri.php on line 141
CAPTCHA - Macrotone Blogs

Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

CDN hosted sites, Tor browser and Captcha

We were recently making a modification to our IP Mapping component to support CDN sites such as Cloudflare as a result of a recent forum post, and we discovered the answer to a observation that we had seen a few times that we thought worth sharing.

We occasionally use the Tor browser to access web sites, usually to give us a random set of IP addresses that we can test upon a site, when using IP Mapping.  It is a very convenient way in which one can test access to a site, and appear to be coming from somewhere else in the world. We had observed that occasionally we were presented with a captcha page on some sites as shown below:

 20160502093024 Cap1 2

In the example shown we are accessing the Cloudflare site itself.

We hadn't worked out why this was occurring but now believe that it is something that sites hosted by Cloudflare sometimes display.  We think this is Cloudflare itself that is intercepting the IP address that the Tor browser is using, i.e. the specific Onion exit IP point, and that Cloudflare is then deciding to display the captcha.  If is probably not that difficult to do, and only requires a mechanism to keep track of all the possible Tor access points, and if the browser is coming from one of these IP locations present the captcha challenge.

Of course this makes some sense since Cloudflare is presumably protecting the sites it is hosting, but to a visitor (using the Tor browser) it is not evident or always known that Cloudflare is hosting the site, so it may come as somewhat of a surprise.

Of course other CDN sites may also be using such a mechanism as well so if you see such a captcha mechanism in place it may not be the site you are accessing that is the source of the captcha but the CDN site itself.

We have only observed this behaviour when using the Tor browser, and note that Cloudflare has a mechanism to let the hosted site decide what action to take when the Tor browser is used.  Other CDN based sites and other browsers may exhibit similar ‘opportunities’ but of these we are not (yet) aware.

Problems with ReCaptcha display

ReCaptchaWe have been seeing a strange problem on our site where the ‘ReCaptcha’ challenge was not always being displayed when it should have been. Most notably this is/was seen on the site registration page, but was not just restricted to that page. A complete page refresh often resolves the problem and shows the Captcha block.

We today saw that a change is proposed for the next Joomla update. It is mentioned in this post from OSTraining, which in turn refers to the fix itself which is extracted from this joomla.org doc.

The basic problem seems to be that Google changed the URL’s of the Recaptcha API location, which doesn’t completely explain what we are/were seeing, but implementing the fix cannot do any harm and may even resolve the problem.

We will watch it for a while and see whether it completely solves the problem, but recommend it is implemented on your sites if you are experiencing ReCaptcha problems.  It does require FTP or SSH/Telnet access to change the plugin code.

Update 29/11/2013: Doesn't solve the display problem, so still investigating.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries