Report an issue

Found a bug you'd like to tell us about?

 Here’s what to do…Login, Select an ‘Issue Category’ from below and click on the "New Issues” button.

 Please note that support questions will not be handled here. If you need hands on technical support please take out a subscription.

#196 – IP lockout before log in

Posted in ‘ Ark Editor’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 20 December 2016 10:17 GMT

I was repeatedly locked out of our site's backend by Admin Tools from AkeebaBackup with the reason: Admin Query String. Their response to my report follows. What can you advise?



The URL tells me everything I need. If you visit it with your browser's developer tools turned on you will see that there is a plugin written by someone ... trying to do call these URLs:

I suppose that "arkbootstrap" and "arktypography" come both from Ark Editor.

These plugins seem to injects Javascript on the page. This Javascript is erroneously output in the backend login page ...
That Javascript is trying to use AJAX to communicate to your site's com_ajax component which a frontend only component (does NOT exist in /adminstrator). Unfortunately, the developer really doesn't know at all how Joomla! works, using the JUri::base() API to get a relative URL. In the frontend that works as expected but in the backend it appends the /administrator directory. This causes the Javascript on the page to call an invalid URL in the /administrator part of your website while you are NOT logged in, therefore triggering a legitimate security exception. Remember, you have set up the Administrator URL Secret Word exactly to prevent these requests from being accepted.

Please contact the developers of Ark Editor and explain to them the following:

  • com_ajax is a front-end only component. They MUST NOT try to call it in the back-end.
  • JUri::base() returns the base URL of the current Joomla application. The frontend and backend of Joomla! are two different applications with different URLs. Their code MUST anticipate that if it's supposed to be executed in both applications.
  • Plugins like that MUST NOT run in the administrator login page. The check to ensure so is less than 60 characters long...
  • These plugins MUST NOT output any code when the editor is NOT in use and CANNOT be used. The only acceptable output for these plugins should be when there's an editor instance on the page (hint: they can use onAfterRender to inject the Javascript after they know for sure if there is an editor on the page or not) OR if I am a user with inline editing rights.

These are very basic things any Joomla developer at the level required to write an editor must know. I would like to give them the benefit of the doubt and say these were unfortunate mishaps but I see too many failures in asserting basic Joomla integration and glaring omissions in testing, not in some borderline condition but in the main way the editor is expected to be used! My advice is to not use that editor. When I see so much smoke I expect to see a (security) firestorm in the not so distant future.



Custom Fields
Server type
Web server type
ARK product version
Joomla! version
PHP Version
Web browser
Errors log
Reason: Admin Query String
Steps to replicate the issue
Have backend open at log in screen, e.g. coffee break, but do not log in. Result: locked out!
Tuesday, 20 December 2016 12:02 GMT

Hi David,

Thank you for reporting this to us.

This is a little confusing as there is a check at the start of the plugin which prevents it from loading into the backend so I’m not quite sure how it is loading in on the administration.

For an example:

\plugins\system\arktypography\arktypography.php on line 39 at the very beginning of the function:

$app = JFactory::getApplication();

                                if ($app->isAdmin()) {


This is the same for the arkbootstrap.php file. Also in testing when I checked the source code in the administrator/ area the Ark typography and bootstrap wasn’t being loaded in. So from out testing with version 2.0.2 of the Ark Editor this isn’t happening.

Perhaps to get to the bottom of this we would need to look specifically at your site. If you would like us to do this, please send us your site detail to and could you please reference this ticket.

I have a suspicion that this could be resolved with upgrading and to version 2x of the Ark Editor as the arkbootstrap plugin has been now depreciated. The upgrade to version 2 requires you to uninstall the old version 1.x before installing the version 2.x, please see: To uninstall please see:

Lastly, the arktypography is used to load in key typography styles into your site. This is needed for things like the model lightbox for an example. Without it your images, links and files wouldn’t pop up in a nice lightbox when clicked upon if it wasn’t present.

I hope this will ensure you of our continuing efforts.

Kindest regards,


Paul Franklin



Friday, 13 January 2017 09:50 GMT

Hi Paul. This got very interesting. The bug is not in your code, it seems, so sorry for the time it took you looking in to it. Nicholas at Akeeba has passed on some interesting learnings if you're interested. Here's what he had to say:

Joomla! indeed uses a keep-alive Javascript feature which is erroneously included in the login page. This is a Joomla! bug. It looks like this:

window.setInterval(function(){var r;try{r=window.XMLHttpRequest?new XMLHttpRequest():new ActiveXObject("Microsoft.XMLHTTP")}catch(e){}if(r){"GET","/administrator/index.php",true);r.send(null)}},300000);

The last number is the time to wait in milliseconds. In this case it is 300 seconds or 5 minutes (this number is different on each site and depends on the session timeout you have set in Global Configuration). If the page isn't refreshed in this many seconds the browser issues an AJAX request to the administrator/index.php page which will refresh the session. Even worse, this will run every 5 minutes, not just after 5 minutes. The reason why this becomes a bad thing will be discussed below.

If you are already logged in that's not a problem. Accessing the administrator/index.php while logged in will NOT result in a security exception. All is well.

The problem is when that happens BEFORE you login or AFTER you log out. That is, if you have any administrator pages open, you get logged out for any reason and this code runs Admin Tools registers a security exception. After all it is an attempt to access to administrator login page without providing the secret word.

And here is where things get hairy. Let's say that your session timeout is 15' and Joomla is set to run that AJAX keep-alive code every 5 minutes. Let's say that 4 minutes into your session your computer goes to sleep. After 20' you come back and log back into your computer and don't touch the browser for a minute or so. Guess what happens now? The browser AJAX code runs, since the time elapsed is calculated based on how long the browser runs (in the background or foreground), NOT on wall clock time. However, since the 15' Joomla session time has elapsed your login session is expired, i.e. you are logged out. Therefore that code has generated an Admin Tools security exception. As you are happily working on other stuff your browser keeps generating one Admin Tools security exception every 5'. Depending on your IP auto-ban settings you might now end up being locked out of your site because of so many triggered security exceptions. Even worse if you had 5 or 10 administrator tabs open. Within the first 5' of your computer resuming to sleep they will all trigger security exceptions on your site. This flood of security exceptions is guaranteed to lock you out under most automatic IP blocking configurations.

The only solution of that is employing proper browser hygiene. When you are not using an administrator tab / window, close it. Before closing the last admin tab, log out. When you resume your computer from sleep close all administrator tabs you had forgotten open (but it's best that you DO NOT leave admin tabs open to begin with!). No matter if you are using Admin Tools or not this is the advisable thing to do. Never leave admin tabs open longer than you need to perform admin work. It's a fundamental security principle.

I then asked, if its a Joomla bug, why doesn't it hit all sites? Nicholas replied:

I have checked all my dev sites and all my live sites, all of them running Joomla! 3.6.5. The keep-alive Javascript code is there in the login page of all sites. What I observe is that the timeout (how long it takes before it runs again) depends on the session timeout you've specified in Global Configuration. The lower the session timeout, the lower the (repeating) timeout in the Javascript.

This has many interesting implications.

When your session timeout is long (30 minutes or more) this code will only run every 20-odd minutes. The security exceptions are raised very far apart and you may never notice them.

The other factor is that IP auto-blocking in Admin Tools is decided based on how many security exceptions are raised from the IP within a specific time limit. See where this is going? The default settings require 3 failed attempts in a minute which is kinda hard to happen unless you have multiple tabs which timed out and at least three of them end up calling that Javascript within the same minute. If you use "wider net" settings (e.g. 3 security exceptions in an hour) it's very likely that once your session expires you'll get your IP banned in a matter of a few minutes. More so when your session timeout is short and this Joomla Javascript is called quite often (like every 3 minutes in your case).

Also, there is a small bug in older versions of Joomla where a logged out session would still have one more load attempt for the URL currently open in the browser before Joomla figured out the session was killed. This gave you double the timeout before raising a security exception. As far as I can tell this bug is fixed since sometime in the 3.6 series.

So, it does take quite the perfect storm to get locked out of your site: new version of Joomla, relatively short session timeout, "wide net" settings in Admin Tools' IP auto-ban, a long lunch break and a couple of open admin tabs in your browser. When you put it all together it makes sense, doesn't it?

There are other factors at play. The site with the issue had a timeout of 60mins, but triggered security exceptions at 5 min intervals. Another site has a timeout of 15mins and never triggers an exception. Nevertheless, I think we're close enough to an understanding and a workround for you to close the ticket.

Many thanks

Friday, 13 January 2017 14:15 GMT

Hi David,

Thanks for the update and pleased to hear that you found your answer.

If you want to show your appreciation for our support you can do so here:

Many thanks,


Paul Franklin :-)

This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.
WebxSolution Ltd is not affiliated with or endorsed by the Joomla! Project or Open Source Matters. The Joomla! name and logo is used under a limited license granted by Open Source Matters the trademark holder in the United States and other countries.

Copyright © 2009 - 2016 WebxSolution Ltd
Powered by JoomlaWired


Cron Job Starts