Because the attachments directory has to live under your document root, and because the files we ship into it only work on some servers, we strongly recommend denying direct web access to media/com_ats/attachments in your server configuration. This is the only method which is guaranteed to work, because it does not depend on your server choosing to honour a file we placed in a directory.
Denying access here does not stop your users from downloading their attachments. Akeeba Ticket System serves attachments through Joomla!™ itself, after checking that the person asking is allowed to see them. Only the direct, unchecked path to the raw file is being closed.
In every example below, replace the path with the real path to your site.
The .htaccess file we ship already does this, provided your server is configured to honour it — that means AllowOverride set to All (or at least Limit) for that part of the filesystem on Apache, and the equivalent "Allow Override" setting enabled in the LiteSpeed administration console or your hosting control panel. If you are not sure whether it is being honoured, test it: see below.
To be certain, or if you cannot enable overrides, put this in your virtual host configuration instead:
<Directory "/path/to/your/site/media/com_ats/attachments"> Require all denied</Directory>
The web.config file we ship uses request filtering to refuse every file extension in that directory. If you would rather configure it centrally, add the following to your site's main web.config, inside <configuration>:
<location path="media/com_ats/attachments"> <system.webServer> <security> <requestFiltering> <hiddenSegments> <add segment="attachments" /> </hiddenSegments> </requestFiltering> </security> </system.webServer></location>
NginX has no per-directory configuration file, so nothing we ship can protect this directory. You must add the following to your site's server block:
location ^~ /media/com_ats/attachments/ { return 404;}The ^~ modifier matters. It tells NginX to stop looking once this prefix matches, which prevents any regular-expression location — most importantly the one which hands .php files to PHP — from taking the request instead.
Reload NginX after editing the configuration (nginx -s reload, or your service manager's equivalent).
Whichever server you are on, verify it worked rather than assuming. Find the mangled_filename of any attachment in the #__ats_attachments database table — say it begins 1f3a — and request it in a browser:
https://www.example.com/media/com_ats/attachments/1f/3a/1f3a…
You should get a 403 or 404 error. If the file downloads, the directory is not protected and the configuration change has not taken effect.