Support

Your tone and demands are unprofessional and unacceptable.

You came here to complain that the third party software you installed in your browser and the way you configured that software and/or your site do not work. If it was just that, okay, it's not ideal but we understand the frustration. Where your ticket crosses line that separates a frustrated support request from a rant is where you accuse us for your configuration (we had nothing to do with it!) and the code in the third party browser extension (we obviously have nothing to do with that). I will look past that, tell you what is going on, and give you a solution, also noting that we would have done that nearly a month ago had you replied to your previous ticket.

> My account is whitelisted and should not be banned !

You CAN NOT whitelist an Joomla user account. The only thing you can whitelist is an IP address which you have not done because a. you would not get blocked in that case and b. you cannot do because you have a dynamic IP address. I know the latter because you said that you reboot the Internet gateway to work around the temporary IP block.

Even if that feature existed, your problem comes from the fact that a third party browser extension tries to access your site's administrator pages AFTER YOUR JOOMLA SESSION HAS EXPIRED which means that you would not be logged in, Joomla would not know which user account is yours (or even if you have a user account!) and the problem would remain.

This is something I have personally documented in https://www.akeeba.com/documentation/admin-tools-joomla/web-application-firewall.html#waf-configure-basic-protection under “Administrator secret URL parameter” and “Browser cookie override for the administrator secret URL parameter”. See numbered point 2 under “Administrator secret URL parameter”. Let me copy and paste it here:

1. As alluded to above, sometimes you may see that your IP is blocked even though you haven't tried visiting your site's administrator, with Blocked Requests recorded from your IP address with the reason “Admin Query String”. This is NOT a bug in Admin Tools. It's how your browser works. Most modern browsers have a pinned sites, reading list and/or frequently visited sites feature which is updated every time you open a new browser window or tab and sometimes also updated in the background, without further interaction from you. This means that your browser is accessing an administrator URL on your site because it appears in one of these features. If this URL does not contain the secret URL parameter and your session has expires a Blocked Request from your IP address is recorded.

   There is no way for Admin Tools (or anything on your server, really) to know that these requests are automated background requests from your browser. As far as your browser is concerned, these are legitimate requests coming from a real browser. Since the Joomla session does not have the administrator secret URL parameter set when this happens they will be treated as requests to be blocked.

   The only thing you can do is either disable these features on your browser (or at least remove any administrator URLs to your site from these features); OR set the “Browser cookie override for the administrator secret URL parameter” to a setting other thanDisabled; OR not use the administrator secret URL parameter.

   In fact, we recommend using the Administrator Password Protection feature instead ofthe administrator secret URL parameter: it is more secure, more reliable, more resistant to Denial of Service attacks and does not suffer from the accidental locking out of your IP address . The downside is that the Administrator Password Protection feature only works on Apache and Litespeed, the two servers which support .htaccess files.

As you can see, it explains the problem AND gives you the solution to it.

> you said its extension,

Correct. Not only it's documented (see above), you were also reminded of this on 8th November by Davide, the other developer of Admin Tools besides me. Here's what he wrote:

> I suspect that there's some kind of extension that is trying to fetch the screenshot of the most visited websites. Since it won't pass the secret param, you will get a security exception immediately, with the result of being blocked.

You confirmed that this is the problem later that day.

Davide asked you to disable one browser extension at a time to see which is causing the problem.

You never replied.

The idea behind Davide's suggestion is that after finding the extension which is causing the problem you can configure it to NOT try to access your site's backend pages and also file a bug report to its developer because they are not using the browser's cookie storage when they perform this kind of background access so they can fix it. Had you replied back that's what we'd have told you.

You see, we already have a solution in our code for this problem and it's based on cookies. Setting the “Browser cookie override for the administrator secret URL parameter” to anything but Disabled will NOT block a request to the administrator missing the secret URL parameter, as per the documentation (see above). The default value is ‘Enabled, remind to use the full URL’.

So, the first thing to check is whether you have set this feature to Disabled. If you have set it to Disabled, you shot your feet. Set it back to ‘Enabled, remind to use the full URL’.

If this is anything other than Disabled then the root cause lies into a browser extension you installed yourself. For this case you said:

> I DONT CARE,

We are not responsible for some third party browser extension developer not using the browser's cookie storage when making a request to your site. This is a bug in their browser extension and you need to take it up with them. Shouting at us will NOT make a difference, nor will it solve your problem. We cannot fix someone else's code. Throwing a temper tantrum about it helps exactly nobody.

If you insist that we have to provide a solution, sure, we can — after all it's already documented!

Use the Administrator Password Protection feature.

Really, that's the solution. It's simple. It's effective.

This creates a .htaccess and .htpasswd file which implement a simple username and password login before you reach the actual Joomla login page. Use a different username and password than the one you use for your Super User account because this will be common for everyone who needs to log into the administrator backend of your site. This is documented in https://www.akeeba.com/documentation/admin-tools-joomla/admin-pw-protection.html

Why will this work? The browser extension trying to access your site's administrator pages will be met with an HTTP 401 Unauthorised response. Since it does not use the browser's password storage or cookie cache it will not know how to go past this error response and will not manage to make a request to your site's backend. As a result your server will not load the administrator/index.php file (Joomla backend entry point), Admin Tools will not be loaded, therefore your IP address will NOT be reset.

> i have to reboot that gateway, and that PISS ME OFF !

Finally, on your point about restarting the Internet gateway. If I had to do that I would also be royally pissed off, as my Internet gateway takes 10' to reconnect. I am looking forward to moving to a new house where I don't have to use this ISP.

However, do note that this is NOT something we asked you to do. What you should do instead is documented in Admin Tools' Web Application Firewall (WAF) locked you out of your site which is the troubleshooting page for this issue and part of our official documentation. It is far easier and far more efficient, especially if your site can send email and you get to use the Rescue Mode feature.

Do not communicate with us in that tone of voice. It will NOT be tolerated. This is your FINAL warning. If you communicate in this tone of voice again your account will be immediately terminated without further warning or a refund for violating our Terms of Service, as explained in the Terms of Service you accepted when you subscribed.

As per the documentation I pointed you to and quoted, the problem has to do with the fact that your browser extension does not make use of the cookies in your browser's cookie cache. As a result your site does NOT know if there is a user logged in. This is how site logins work. This is an objective statement of fact, one you can easily verify by looking at Joomla's source code, a large of which I have written myself.

Your site DOES NOT log you in by your IP address, nor does it ever store your IP address linked to your user account, for two blatantly obvious reasons:

• Logging in from a shared connection (e.g. a business, or an academic institution; or the more modern use case of shared WiFi in a bank, cafe, airport, etc) means that all browsers across all devices connected to the same shared connection have the same public (Internet-facing) IP address. The server would not be able to distinguish which device makes the request, therefore EVERYONE on that connection would be connected as your user account. This would of course mean that logging into your site from ANY connection would immediately make your site effectively compromised (hacked). This problem has been known long before there was such a thing as Internet, let alone World Wide Web, back in the olden days of time-share systems and dial-up connections between academic institutions in the 1970s.
• IPs can and do change over time. If yours doesn't, congratulations, you are on an ISP which is an exception to the rule. Don't kid yourself, you are not on such an ISP, as witnessed by the fact that your IP does change whenever your gateway restarts as per your own words.

The mechanism through which your site knows you are logged in is a user session. The user session is identified by a cookie sent by your browser to your server, called a login cookie (I think the reason for its name is beyond obvious). This cookie is installed to your browser when you log into your site, it has an expiration date, it is NOT attached to an IP address, the server DOES NOT store your IP address, and the cookie is uninstalled (destroyed) when you log out, or when a new session is created e.g. after your previous session expires.

Now let me address your absurd and ignorant insinuation that Admin Tools should magically know it's you based on your IP address. As I explicitly stated above, linking an IP address to a user account is horrifically insecure, if not outright stupid. It would expose your site to attackers every time you log into your site from a shared network or your IP address changes. This is the reason why this has not been implemented and will never be implemented. Demanding that a security extension implements a feature which makes your site insecure is like asking for a secure door manufacturer to make it possible that the door unlocks if you jiggle it the right way: it is ignorant, moronic, and completely beats the purpose!

If you really want to shoot your feet, we do let you set up IP whitelisting for your domestic Internet connection if you want to. Remember that this is DANGEROUS: any request appearing to come from your IP address will bypass Admin Tools. This holds true for any device connecting to your network including malware that makes it to your devices, or malicious or compromised devices connected to your network. This is documented in https://www.akeeba.com/documentation/admin-tools-joomla/waf-ip-whitelist.html, see “Notes about using Dynamic IP Address Domain Names”. I do NOT recommend this. It is horribly insecure except in very specific use cases which do not apply to you. This is why I never mentioned it before. I would never give you advice which deliberately undermines your security just to get rid of you, no matter how bellicose or absurd you get with me. I am here to help y'all improve your sites' security. If you cannot understand that then we have nothing to say to each other. Go to some other vendor who's happy to sell you snake oil "security", telling you to make your site insecure just to get you off his back when you get too demanding. We know who they are, we refuse to be like them.

Your problem is trivial, it is not our problem to fix (it's the third party browser extension's fault which you refuse to understand, let alone contact them for a much-needed fix), and it has a number of trivial workarounds I have already documented and explained to you. As per our Terms of Service, we can only tell you what the problem is and how to solve it. If you choose to not follow our troubleshooting steps it's your choice but then the liability of the problem lies on you, and you will no longer receive further support about it.

As a result, your ticket is now closed per our Terms of Service. Opening any further ticket about this issue will be closed without a reply.

Goodbye.

At 2022-12-03 03:06 EET you sent a pre-sales contact form with the following content (with all the grammar and spelling mistakes copied verbatim):

> hi, i guess you are very good technicaly but you are a morron with serious psychological issue,

> i'm system engineer level 2 piece of crap, dont talk to me like that,

> cu

It's hard to believe that anyone decided to be so vile and self-destructive after being given a full explanation of the problem and several alternative solutions.

Moreover, it beggars belief that a "level 2 engineer" has no clue how logging into a site works, the fact that IPs and logins cannot be connected for reasons known for the past 50+ years, or understand that we do not control third party software we have absolutely no affiliation with. I don't believe you. Nobody with this propensity for abuse and lack of basic technical knowledge and common sense can be an engineer, let alone a customer-facing level 2 systems engineer. With this lack of basic knowledge and your demeanour you wouldn't have made it past your first ticket before being terminated for gross incompetence without severance a long, long time ago.

In any case, I had given you two warnings to not be abusive and keep it professional, as I had to per our Terms of Service. Not only you didn't take that last chance offered, you decided to submit a contact form where made an ad hominem attack. As per our Terms of Service, “Keep it professional” section, this behaviour leads to your account being terminated without a refund or other warning. Any further accounts we suspect are created by you, your employer, co-workers, or parties related or affiliated with you in any way will be terminated without any warning and without a refund as well, as per our Terms of Service.