When you use our .htaccess Maker, it writes a .htaccess file which -by default- applies extremely tight security settings. The immediate result is that some third party extensions which use potentially unsafe practices no longer work properly or at all. Don't fear! Fixing them is very easy, carrying out the steps in the following step-by-step guide.
Determining which exceptions are required takes only a few minutes of your time. On the upside, once you determine them on one site you can reuse them on all sites having that extension installed. You will quickly end up with your "master" exceptions list which you'll be able to apply to all of your sites without a second thought.
In the following example we are going to use Google Chrome to detect access issues on a site. Similar tools are built-in in other major browsers.
Our first test case will be a site with the great CssJsCompress JS/CSS minifier plugin installed. The first indication that something went awry is that our site looks like all the CSS is gone.
In order to figure out what is going wrong, we have to find out which of the files referenced by the page are throwing a 404 error (this means that they are filtered out by Server Protection), their naming pattern and location. Provided that you are using Chrome open up the Developer Tools pane by typing CTRL-SHIFT-J (or CMD-OPTION-I on a Mac) while viewing that broken page. Click on the Network tab, then reload the page (e.g. using CTRL-R or CMD-R). The page reloads and a list of files the browser tried to access appears.
The lower part of the window is the console. It kindly informs us that two files, js.php and css.php, failed to load with a status of 404. Bingo! We found the culprits, now let's take a look where they are coming from. Click on the js.php link in the console. The top part of the window changes to display some debugging info about that file.
The interesting part is the request URL:
http://localhost/demo/plugins/system/CssJsCompress/js.php?js=0e5799f64bd805d46c20200986c626e4.js.
As you guessed, the part after the question mark is a URL parameter
and can be removed. We're left with
http://localhost/demo/plugins/system/CssJsCompress/js.php,
but we know that http://localhost/demo is our site's base URL. Remove
it and you're left with
plugins/system/CssJsCompress/js.php. Bullseye! Is there any
change that this file can have a variable name? Nope. Does the file
exist in our file system? Yes. This means that this is the exact file
we need to put in our Allow direct access to these
files list. Doing the exact same process for the css.php
ends up with yet another file we have to exclude:
plugins/system/CssJsCompress/css.php. Note the
capitalization, OK? Copying and pasting those files in that exceptions
option and regenerating the .htaccess file allows
our site to load properly.
That said, sometimes you will see something like a long list of hard to guess filenames like js-abc123456789fed0.php and so on. If the file extension is anything but .php you can add the extension to the front-end or back-end allowed file types list and the directory in the respective list of directories where file type exceptions are allowed. If the culprits are PHP files, you have two options: stop using that extension or add the directory in the "Allow direct access, including .php files, to these directories" list.
How about another example?
The previous example was dead easy to spot as the page looked like a big ugly mess which immediately made us figure out where the culprit is. This is not always the case. Sometimes a feature of an extension stops working with seemingly no explanation. In this test case we'll be using UddeIM. That was a real-world issue I had to deal with and this is the story of how I solved it.
After installing the Server Protection users started complaining that they could not send me messages through UddeIM any more. At first I couldn't understand why, because I could use it without any problem at all. Then, I decided to create a simple unprivileged registered user with the intention to send a message to myself in order to test that. Then, I spotted the problem.
![[Tip]](/media/com_docimport/admonition/tip.png) | Tip |
|---|---|
|
When trying to figure out an issue affecting your users but not yourself, always try using a user with the same attributes as an afflicted user. Ideally, log in with the reporting user's account —with their permission, as you have to change their password— to witness the issue yourself. I got that piece of experience this the hard way. |
There was a broken image icon next to the Security Code. This is where a CAPTCHA should display - but only for Registered users. Why doesn't it get displayed? Time to use the Developer Tools in the browser.
There is a captcha15.php file not loading. Right. Where is it located? Clicking on the filename in the console allows us to figure it out.
So there it is!
components/com_uddeim/captcha15.php. Add it to
the Allow direct access to these files exceptions
list, generate a new .htaccess and that's
it.