Great it is, impossible is anything but! Properly written Joomla! software should NEVER, EVER require you to put any exceptions in the server protection. In fact, properly written Joomla! software should only access everything through the index.php/index2.php files in Joomla!'s front- and back-end directories. Anything else means that the software is deliberately
bypassing Joomla! and exposes your site to unknown threats – remember, bypassing Joomla! bypasses all automatic protection offered by Joomla! and Admin Tools' WAF as well. Just to give you an idea of how rare you need to bypass Joomla!, I've written four major components and only had to bypass Joomla!
twice:
1. In Akeeba Backup Professional, in the integrated restoration feature as we are
overwriting Joomla! with the backup. In this case, Joomla! files may be left in a "confused" state while we are extracting the backup, breaking the site. Therefore, we have to bypass Joomla! or we run the risk of the extraction failing.
2. In Admin Tools Core and Professional, the Joomla! update feature. Like a restoration, it replaces core Joomla! files with those from the update package and we have to bypass Joomla! for the same reason.
And that's the final list. Unless you are overwriting Joomla! core files, there is
NEVER, EVER the need to bypass Joomla!. Every develop who doesn't understand that is a dangerous idiot (or he has ported non-Joomla! software to Joomla!, as is the case with eXtplorer and Virtuemart 1.x - not 2.x, that one's written from scratch). Unfortunately, there are hundreds of dangerous idiots with software listed on the Joomla! Extensions Directory.
But even in such a case of software bypassing Joomla!, the files which need to be accessed directly should be stored in a single directory or, at the very list, be a definitive list. This makes it relatively easy to figure out which ones they are and create the exceptions as per the documentation instructions you followed. If you run into new files all the times, it means one thing only: you are using RokGZipper or a similar CSS/JS aggregator and compressor.
Regarding RokGZipper, Andy Miller (the owner of RocketTheme) contacted me a few months ago after I said on Twitter that it's dangerous. I told him that the way it works, it places randomly named PHP files all over the site's directories. This means that the site owner has to allow any arbitrary PHP file anywhere on the site to run, which means that he can not guard against rogue PHP scripts planted by attackers. He didn't look very convinced that it can be done otherwise. I gave him some Proof of Concept code and told him they could use it (it's GPL). They seem to have chosen to ignore me. Their bad. I took my PoC code and put it to the latest dev release of Admin Tools. You can aggregate, minimise and compress CSS and JS files WITHOUT compromising the tiniest bit of your site's security. I really like RocketTheme's templates, but in my humble oppinion RokGZipper is a security nightmare and they don't seem to have the slightest intention to do anything about it. Huge shame :(
Oh, RokGZipper isn't the only plugin doing that. There are plenty of them on the JED. That's how I came to write my Proof of Concept code, tweak it and decided to ultimately include it in Admin Tools ;)
For the record, I had a similar conversation with JoomlArt over a year and a half ago, regarding the relative insecurity of rogue PHP file access. The difference with RocketTheme is that after I talked with Hung, he passed on our conversation to his developers and they had a valid workaround (putting such files in a dedicated, CDN-friendly directory) within 18 hours.
So, back to your site. Do you use a CSS/JS aggregator like RokGZipper? Or, do you use a template which automatically compresses its CSS/JS using PHP? This is the only way you can have the issue you're describing. And if you send me a
Personal Message with a few affected URLs on your site I can certainly give you a workaround.
BTW, using PHP to compress CSS and JS is the single most inefficient thing you can do. If you enable the static media file compression option in .htaccess Maker you can have your webserver (Apache) do that for you, which is MUCH faster (about 2x-3x faster, according to my benchmarks).
I wonder if I should put all of this in the documentation :)
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!