Akeeba Ticket System allows users to optionally upload attachments with their tickets and ticket replies. These files are stored on your site, in the directory you configure in the component's Options page. The default is media/com_ats/attachments.
The attachments directory lives under your site's document root, and that is not something we can change. Joomla!™ requires an extension's user-uploaded files to live in a subdirectory of media named after the extension. Everything below therefore describes defence in depth around a directory which is, by default, web accessible. Please read Section3.1, “Protecting the attachments directory”.
Attachment files are stored two directory levels deep, under a mangled name. The name is the SHA-1 hash of the original filename, the current time to microsecond precision, and your site's secret key: 40 hexadecimal characters, with no file extension. The first two character pairs of that same hash form the two directory levels, e.g. media/com_ats/attachments/1f/3a/1f3a….
This is a best-effort mitigation, and it is worth being precise about what it does and does not achieve. The names are drawn sparsely from an enormous search space, so an unauthorised user cannot realistically guess or brute-force one; and because the files have no extension, a correctly configured web server will not execute them as code. What it is not is access control: anyone who obtains the URL by some other means can fetch the file. It is obscurity — useful, deliberate, and not a substitute for actually denying access to the directory.
Akeeba Ticket System ships two files into the attachments directory to deny direct web access: a .htaccess file, which works on most — but not all — Apache™ and LiteSpeed installations, and a web.config file, which works on most IIS™ installations. Whether either takes effect depends on your server's configuration; on Apache, for example, .htaccess files are ignored entirely unless the server is set up to allow overrides. There is no equivalent file for NginX: NginX has no per-directory configuration mechanism at all, so we cannot ship anything that protects the directory there.
Attachments have, by default, the same visibility as the ticket itself. Therefore, attachments in public tickets are visible to everyone and can be downloaded by anyone who has their URL. You can optionally make all attachments private. This means that attachments in public tickets will only be visible to and can be downloaded by the person submitting the ticket they belong to and users with the Support Staff permission.
Akeeba Ticket System has its own set of upload permissions; it does not use the same ones used by the Media Manager. This is intentional. The Media Manager is set up to allow the upload of files which need to be publicly accessible on your site, mostly images, videos, audio files, PDFs, and office application files. Attachments in a ticket system tend to be archives, log files, even executables depending on the nature of the support you are offering through the ticket system. Therefore it makes sense to have a different set of upload permissions to allow for files of a different nature to be uploaded. You can find these settings in the component's Options page.
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.