Support

Let's make sure that the problem is indeed caused by Admin Tools. In order to do so, try the following:

1. Try setting the Error Reporting level in your Global Configuration to "None". Many errors are caused by harmless PHP Notices and Warnings being output to the browser, breaking anything which requires HTTP header manipulation such as Joomla!'s session management, AJAX calls and download systems.

2. Try to replicate the issue after disabling the "System - Admin Tools" plugin. If you can still replicate the issue, it is not caused by Admin Tools. Disabling that plugin means that Admin Tools code (including the Web Application Firewall) is not running on your site.

3. If you suspect an issue with the .htaccess file, replace its contents with the contents of the stock htaccess.txt file shipped with every version of Joomla!. If you are on GoDaddy please wait for 1-30 minutes for the changes to be effective. Then, retry loading the problem page. If you can still reproduce the error, then it is not caused by .htaccess Maker.

If doing any of the above resulted in the issue still occurring, it's not related with Admin Tools and we can't help you. If doing any of the above did stop the issue from occurring, we'll have to do some troubleshooting.

First go to Admin Tools, Web Application Firewall, Configure WAF. Make sure "Log security exceptions" is set to Yes; if it's not, set it to Yes and click on Save. Now try reproducing your issue. Immediately after that, please go to Admin Tools, Web Application Firewall, Security Exceptions Log. The latest log entry at the top should have the date and time of when the issue occurred. Please copy the Reason and Target URL here so that we can further help you.

If, however, you do not see a log entry, or the Date and/or IP address do not match your last access, this problem is not caused by Admin Tools' WAF. In this case, you will have to do some .htaccess troubleshooting. You may need to read the general .htaccess troubleshooting page, as well as the page on finding out necessary .htaccess exceptions.

I think that your integration is trying to save the Joomla user object for a user account that has administrative privileges (Manager, Administrator or Super User). This is potentially dangerous that's why we give you the option to catch it as a security exception.

If you ware absolutely certain that you are handling this the right way you can use the WAF Exceptions feature to add an exception for your integration component.

I can tell you how exactly this is triggered to help you narrow down your search. We install a handler that Joomla calls right before creating a user. Joomla passes us an array of the data to be used for creating the user. Part of that is the groups key, itself a simple array of the Joomla user group IDs which will be assigned to the user. If one or more of these groups have the backend access privilege we consider it creation of a privileged user or user privilege escalation and block the request.

So, somewhere, sometimes, somehow your integration is sending a user group that's not safe as it has backend privileges. Most likely it sends the correct user group ID but there's an oversight in this group's privileges in Joomla, accidentally giving it more access than you should have.

That'd depend on what that code does. You can't really have a race condition if both pieces of code run inside the same page load since PHP code runs linearly.

Instead of wondering you can turn on the logging in Admin Tools and examine the log after the fact. The entire request will be stored there, including the user group assignment that triggered the security exception.

Your screenshot is most definitely not something that Admin Tools created or showed to you. Again, you need to turn on logging in Admin Tools and examine the log it generates after the fact. The entire request will be stored there, including the user group assignment that triggered the security exception. Here's how.

Components, Admin Tools, Web Application Firewall, Configure WAF. Click on the Logging & Reporting tab. Set "Keep a debug log file" to Yes.

Wait for the issue to happen again.

Correlate the log entry in the Security Exceptions Log with the contents of the file YOUR_LOG_DIRECTORY/ admintools_breaches.php where YOUR_LOG_DIRECTORY is your Joomla log directory, typically set to administrator/logs under your site's root. This file contains the entire request which was blocked by Admin Tools. Show that to your developer.

For info on that option please read the documentation at https://www.akeebabackup.com/documentation/admin-tools/web-application-firewall.html#waf-configure-logging-reportingwafconfopt-debug-log

We established that your request is blocked because of a Frontend Edit Admin User exception. I explained, in detail, how this feature works. If you don't believe me the code is right there for you and your developer to see.

I told you that the best way forward is to see what exactly is the data that your site is receiving so you can understand both why the request is being blocked and help you troubleshoot your CRM integration which I did not write and I have nothing to do with. In fact, I told you twice how to do it.

At this point I'd like to explicitly state what is painfully obvious to anyone looking at your screenshot. It only tells you which URL the POST was sent to and the HTTP response received. It DOES NOT tell you which data it sent. Please re-read everything I told you from here and up to this reply here very carefully. The key to understanding the problem is in the data that you see neither in your CRM's callback history nor in Admin Tools' Security Exceptions Log. You need the raw POST data that was sent to your site and I've already explained, twice, how to get it.

Show this thread to your developer. They will know how to proceed from here.

Ultimately, this is not an issue in Admin Tools. I have re-run the automated tests we have for that feature and did several manual tests myself. It is not triggered unless a user is being saved and either the user belongs to a group with backend login privileges or saving the user would assign them to any group that has login privileges.

I think at this point I will have to close the ticket because we are having a circular conversation about something that's well outside the purview of our support.