Support

Yes, the console errors in your attachment confirm that Admin Tools is blocking Balbooa Forms. The specific request being blocked is:

POST /administrator/index.php?option=com_baforms&task=form.installTemplate

Admin Tools is returning a 403 Forbidden response with its standard "You don't have permission to access this resource" page. This means one of the Web Application Firewall protections has flagged something in that request.

Before we can give you the exact fix we need to know which protection is triggering the block. Please do the following:

1. Go to Components → Admin Tools → Security Exceptions Log.
2. Look for recent entries relating to com_baforms (there should be two, matching the two failed attempts you captured in your screenshot).
3. Note the value in the Reason column for those entries.
4. Reply here with what it says.

Once we know the reason, the fix will involve adding one or more WAF Exceptions (Components → Admin Tools → Configure WAF → WAF Exceptions) to tell Admin Tools to skip that specific check for com_baforms requests. We just need the Security Exceptions Log to tell us exactly which check and which POST parameter to target.

Regarding the activation problem from your own PC: that is almost certainly the same root cause — another com_baforms request being blocked by the same WAF protection. The WAF Exceptions fix should resolve both issues at once.

Thank you for checking the Security Exceptions Log. Since it shows no entry for the blocked request, the 403 is not coming from Admin Tools' Web Application Firewall — Admin Tools always records every block it makes.

The block is happening earlier in the request pipeline, either in the .htaccess file or in the server/CDN configuration. Here is how to narrow it down.

Step 1 — Test whether .htaccess is the cause

1. In your site's root directory, locate htaccess.txt (Joomla ships this as a safe default).
2. Rename your current .htaccess to something like .htaccess.bak.
3. Rename htaccess.txt to .htaccess.
4. Try the Balbooa Forms template installation again.

If the problem goes away, the cause is a rule in the .htaccess that Admin Tools' .htaccess Maker generated. To find which one:

• Go to Components → Admin Tools → .htaccess Maker.
• Our documentation covers each available option. Disable one feature at a time, click Save and apply the .htaccess, and retest until the blocking feature is identified.
• The documentation for the .htaccess Maker can be found at https://www.akeeba.com/documentation/admin-tools-joomla/htaccessmaker.html.

If the problem persists with Joomla's default .htaccess, the block is coming from your server configuration or an external service.

Step 2 — If .htaccess is not the cause

The block is likely coming from a server-side firewall rule (e.g. mod_security2 on your host) or an external CDN/proxy service such as Cloudflare. These rules often match on the content of the POST body — not just the URL — so even a seemingly harmless request can be caught if a firewall signature matches something in the data being submitted.

To help identify the blocked request, first find out your public IP address. Visit a site like https://whatismyipaddress.com and note your IPv4 address (and IPv6 address if shown). You will need both in the next steps.

If you are using Cloudflare or a similar CDN/proxy:

• Log into the Cloudflare dashboard (or your CDN's equivalent) and open the Security → Events (or Firewall Events) section.
• Searching blindly through the log is unlikely to help given the volume of traffic. Instead, filter by your public IPv4/IPv6 address combined with the blocked URL (/administrator/index.php?option=com_baforms&task=form.installTemplate). This will surface the exact rule that triggered the block.
• Once identified, create a firewall exception rule in Cloudflare to allow that specific request through.

If you are not using a CDN, or the CDN shows no block:

• Contact your host (20i) and provide them with your public IPv4/IPv6 address, the blocked URL, and the approximate date and time of the failed attempts. Ask them to search their mod_security2 or server WAF logs for that combination. This will allow them to identify the specific rule responsible.
• Your host will most likely resolve this by either modifying the .htaccess file directly, or by giving you a snippet of code to add to it. Important: if they give you code to add to .htaccess, do not paste it into the file manually. Instead, add it to the Custom .htaccess rules at the bottom of the file field in Admin Tools' .htaccess Maker (Components → Admin Tools → .htaccess Maker, scroll to the bottom). This ensures the override rule is preserved the next time you regenerate the .htaccess file via Admin Tools.

Let us know what you find after testing with the default .htaccess.

That is an excellent and very telling piece of information. If Balbooa's team, working from their own IP address, could install templates without any issue on the very same site, then the block is almost certainly specific to your IP address — not a blanket .htaccess content rule (which would block every visitor equally, including Balbooa's team).

You should still do the .htaccess swap test we described, just to rule it out cleanly. But the evidence now points strongly toward the block being enforced by either Cloudflare (if your site runs behind it) or your host's server-side firewall (20i), and being triggered by your IP specifically — whether because of IP reputation, a previous temporary block that was recorded, or a rule that is sensitive to something in your connection fingerprint.

The steps to resolve this are the same ones we outlined previously, but the IP angle now makes them even more targeted:

1. Visit https://whatismyipaddress.com from the computer you use to manage the site. Note your public IPv4 address (and IPv6 address if shown).

2. If you use Cloudflare or another CDN in front of your site: Log into its dashboard, go to the Security Events (or Firewall Events) section, and filter by your IP address. You should find the blocked request there, along with the rule that triggered it. Create a firewall exception to allow your IP (or that specific request pattern) through.

3. If you do not use a CDN, or the CDN shows nothing: Contact 20i and give them your public IPv4/IPv6 address, the blocked URL (/administrator/index.php?option=com_baforms&task=form.installTemplate), and the approximate date and time of the failures. Ask them to search their mod_security2 or server WAF logs for that IP and URL combination. They will be able to tell you what rule is firing and either remove it or give you a code snippet to override it in .htaccess.

If 20i gives you code to add to .htaccess, remember to paste it into the Custom .htaccess rules at the bottom of the file field in Admin Tools' .htaccess Maker rather than directly into the .htaccess file, so it is not lost the next time you regenerate it.

Glad you got to the bottom of it. The error in the log confirms that the root cause was a bug inside Balbooa Forms itself — specifically in com_baforms/src/Helper/DesignHelper.php — which was causing a PHP fatal condition on PHP 8.2, ultimately resulting in the 403 response. Admin Tools and the .htaccess were never involved.

That said, this falls outside the scope of what we can help with. Our support covers our own software (Admin Tools, Akeeba Backup, and the other products in our portfolio), not third-party extensions. For anything related to Balbooa Forms' behaviour or compatibility, Balbooa's own support team is the right place to turn — and as you've already found, they are responsive.

We are glad the issue is resolved and that Admin Tools is in the clear.