Support

This is a bug (actually three, all in one place!) with Dropfiles. Their developers have done ridiculous mistakes, as thought they don't know how Joomla works at a fundamental level. I've replied to this exact question quite a few times in private tickets, finally I get to do it on a public ticket as well.

The problem is that when you click on a download link it redirects you to this kind of URL:

index.php?format=&option=com_dropfiles&task=frontfile.download&catid=32&id=29&template=dropfilesfrontend&Itemid=1000000000000

This is… bad. As in “does this person even knows how Joomla works the last 14 years” bad.

The first problem is what gets it blocked, it uses template=dropfiles.

Joomla uses the template URL parameter to select a different site template to display a page. This is blocked by Admin Tools' “Block template=foo site template switch” in Configure WAF, Hardening because there is no such template on the site. Using the template URL parameter to detect when your extension is running is categorically wrong, especially when you have the option parameter in the URL.

Probably, they meant to use tmpl=component which is a completely different thing; it tells Joomla to use the component.php file of the template instead of its index.php. However, even that is irrelevant when you're downloading a file, as we will see later.

Next up, format= is equivalent to format=html, or not using that URL parameter at all (Joomla has a fallback when the format is empty or invalid; the fallback is html). So, that part of the URL is pointless, and it tells me that these developers never read Joomla's source code and do not understand how Joomla works.

What they probably meant to do is format=raw. But even that is irrelevant, really.

All they actually need to do is call \Joomla\CMS\Factory::getApplication()->exit() after sending the file data, just like we've been doing in Akeeba Release System since 2010, therefore making it irrelevant what the template, tmpl and format parameters in the URL are. Since they discard anything already done by any other plugin and closing the application immediately after pushing the file data the URL parameters governing the HTML rendering of the page are, of course, completely irrelevant. They could maybe add tmpl=component&format=raw to prevent broken, badly written 3PD plugins from interfering, but that's about it.

The final problem is that the Itemid value of one trillion(!!!) is not just wrong, it's also potentially insecure. I have seen many things done wrong in Joomla! extensions, but this one takes the cake. This is so mind-bogglingly wrong I can't even.

The Itemid corresponds to the menu item ID, the first field (id) in the #__menu table. That field is an INT field in MySQL which means that it can accept values between -2147483648 and 2147483647. As you can see, the maximum value it can be is just over two billion, nearly three orders of magnitude lower than what the developer of your extension uses in their URL. This will cause an integer overflow. Essentially, you'll very likely end up with a completely different Itemid than the value passed in the URL. It's only by sheer dumb luck that he has not slammed head first into that problem already.

The correct way to implement that is not passing and Itemid at all. Joomla 4 and later will use the default menu item. This means that he needs to provide values for the option, controller, view, and task URL parameters to avoid interference from the default menu item, what he tried but actually failed to do here. So, basically, add option=com_dropfiles&task=frontfile.download&controller=frontfile&view=frontfile. In fact, the controller URL parameter is redundant, it's only there to prevent third party plugins from doing something stupid. The view should be redundant, assuming his frontfile controller is written correctly, i.e. sends a file without ever rendering a view.

Please ask the developer of that extension to fix all those problems.

I don´t think they will change the architecture and behaviour of their extension.

It has nothing to do with changing the architecture, at all! They only need to change how they generate that URL so it's not a hot mess.

Here's what:

• There's no need to use template in the URL. This is only used to control how to render HTML. This is a file download URL. No HTML is rendered. Therefore, having a URL parameter to control something which does not happen is pointless at the very least. They can remove that completely.
• Using format= is the same as not using it at all. Since their extension works as-is they can just remove it.
• Using Itemid=1000000000000 causes an integer overflow and can become a security issue. They need to replace that with controller=frontfile&view=frontfile.

Three small changes in the way they produce their URL, their extension keeps working without refactoring anything, and it no longer gets you blocked URLs. It's about 5' of their time.

And as i have to deal with Dropfiles on this site - is there a possibility to set an exception for Dropfiles in AdminTools till I migrate to another download extension?

There are two possibilities. Add an exception for Dropfiles, or toggle a parameter to let it work.

If you add an exception for Dropfiles you will be turning off quite a lot of Admin Tools' protections. With another extension I'd consider it acceptable. Seeing that this extension's developers don't seem to have a grasp on the fundamentals of Joomla and resort to insane “solutions” I won't accept doing that. It's far too risky for me to suggest in good conscience.

So, let's go with the other possibility which, in the grand scheme of things, is far less risky. Go to Components, Admin Tools, Web Application Firewall, Configure WAF, Cloaking and set “Allow site templates” to Yes. The protection you are disabling is marginal / paranoid, meaning that your site's security is not seriously compromised by this change.

Awesome! I’m glad they are fixing it.

Have a great day :)