Support

This is a SEF URL, not an actual directory on your site.

WebCRON uses Wget to trigger the URL-based CRON jobs. By default, Admin Tools will block Wget.

Go to Components, Admin Tools, Server Config File Maker, User agents to block -> remove Wget. Click on Save & Create .htaccess.

Please try the following to narrow this down:

1. Rename your site's .htaccess file to something like .htaccess-bak, then rename htaccess.txt (Joomla's default, unmodified .htaccess template that ships in the site root) to .htaccess.
2. Trigger the WebCron job again (or wait for the next scheduled run) and check whether the 403 still occurs.

• If the 403 still happens with Joomla's default .htaccess in place, the block is not coming from our .htaccess Maker at all, but from something else on the server (e.g. the host's own web server configuration or a security module). In that case this would not be something we can fix on our end, and you would need to speak to your host.
• If the 403 goes away, one of the .htaccess Maker's options is causing it. In that case, restore your original .htaccess and then, in Admin Tools' Server Config File Maker, disable one option at a time (saving and recreating the .htaccess after each change) until you find the specific option responsible. Let us know which one it turns out to be so we can confirm.

When you reinstalled the extension your old Secret Word was no longer valid. Have you created a new secret word and updated your CRON job?

That was my next question, but you preemptively answered it :)

One correction, though. There are no disallowed characters per se. You can use whatever you want: latin lower- and uppercase characters, Arabic numerals (digits), punctuation, Greek, Chinese, emoji, any Unicode character will do. If your server can convey it to PHP, Akeeba Backup can use it. If you want to use Føδ*🧑🏻‍💻c❤︎裡32 as your secret word you can. In the URL it would actually appear URL-encoded as F%C3%B8%CE%B4%2A%F0%9F%A7%91%F0%9F%8F%BB%E2%80%8D%F0%9F%92%BBc%E2%9D%A4%EF%B8%8E%E8%A3%A132. I have an integration test for it as something you can (but probably won't) do, proving that the engine accepts "crazy" character combos just fine.

That said, a problem using something complex lies on the server, not our code.

Most servers run some kind of server protection – typically mod_security2 wit the OWASP CRS – which misunderstands complex passwords and especially those containing punctuation any characters outside basic latin without accents and diacritics as something malicious going on. 

This is why when you generate a secret word in Akeeba Backup the built-in rules are to use a-z, A-Z, 0-9, and dash. This is also why there's a password quality metering algorithm implemented: I know that 99% of users trying to set up their own password will be frustrated by their server, ending up with something like JustBloodyWorkAlready which is most definitely NOT a good password for what is a Super User-equivalent feature.

Hence the advice in the documentation to always use a-z, A-Z, 0-9, dashes, and underscores with enough characters to have enough entropy. It's not a limitation in our software, Joomla, PHP itself, or the web server. It's a limitation of how production web servers are typically configured.