Fresh install of osTicket 1.15.4. Debian on Buster 4.19.208-1. Various settings changed for agents, sla etc using the interface and two plugins enabled - auth_LDAP, storage-fs. Plugins are working fine except links in tickets to the attachments are in lower-case.

If I use this attachment link in the ticket it fails: Unknown or invalid file
http://serveraddress/file.php?key=xizpjqhii2guaprjyg45bvw584jfvta8&expires=1644364800&signature=84e98fb5a2bac9aa0b97859a7fe4f0753114ef58&id=97

If I copy the key from the database to fix the URL key the file is retrieved fine.
serveraddress/file.php?key=XizpjqHiI2gUaPrjYg45bvW584jfVTA8&expires=1644364800&signature=84e98fb5a2bac9aa0b97859a7fe4f0753114ef58&id=97

So the entries in database are correct, the permissions are correct and the files exist. It is only the URL to the attachments in the ticket thread being in lower case causing the issue. Anyone have any ideas why?

Could it be a Debian / Apache2 changing the URL to lowercase?

osTicket installation information

Database files table.

Apache2 Config
`<VirtualHost *:80>
ServerName helpdesk.aucom.local
ServerAlias helpdesk.aucom.com
DocumentRoot "/var/www/html/ithelpdesk"

<Directory "/var/www/html/ithelpesk">
    Require all granted
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

ErrorLog ${APACHE_LOG_DIR}/ithelpdesk-error.log
CustomLog ${APACHE_LOG_DIR}/ithelpdesk-access.log combined

</VirtualHost>
`

  • ntozier replied to this.

  • SOLVED. I tried changing the database collation from utf8mb4_bin to utf8mb4_general_ci and received a duplicate key error on one of the users. I discovered one user had two accounts - one in lower case, one in mixed case. I moved all the tickets from one user to the other and then deleted the duplicate user. I subsequently reapplied / changed the database collation to utf8mb4_general_ci without error - and tada - the attachments links started working.

    AuCom Could it be a Debian / Apache2 changing the URL to lowercase?

    That would be my first guess. The string is case sensitive, changing it from what it should be to all lower case would make it not match.

    This could be a Apache/http config thing, or an .htaccess thing.

    Maybe something like
    RewriteCond %{REQUEST_URI} [A-Z]
    RewriteRule ^(.*.aspx)$ ${lc:$1} [L,NC]

      The cause is a setting stored in the database!

      I created a new installation from scratch on the same server using the same virtual host conf. No plugins. Attachments worked correctly using DB for storage. I then added, configured and enabled storage-fs. Attachments were stored to mixed case folders and files and the links - though all lower case - also continued to work. This ruled out Debian and Apache2 being the cause.

      I then swapped out the ost-config.php file with the one from the installation having issues. The webpage updated accordingly with the other sites tickets etc. I updated the storage-fs config to the new location and tested a new ticket with attachments. The files appeared in the correct location and using mixed case.
      Clicked on the link in the ticket - file not found!

      Changed back the ost-config.php file and tested with a new ticket and attachments. The links in the tickets are all lower case and the files in mixed case. AND the links work again implying this issue has to be some setting stored in the database.

      Where oh where do I go next? Some conflicting php code or is there some special setting in the database?

      @AuCom

      If it works on a new, vanilla install but not on your current install then I'd assume there are differences in code or something. Are you sure you installed the new storage-s3.phar on the current install?

      Cheers.

        KevinTheJedi I changed the clean install to use the existing database - and that broke it. So error not in the code - something in the database.

          SOLVED. I tried changing the database collation from utf8mb4_bin to utf8mb4_general_ci and received a duplicate key error on one of the users. I discovered one user had two accounts - one in lower case, one in mixed case. I moved all the tickets from one user to the other and then deleted the duplicate user. I subsequently reapplied / changed the database collation to utf8mb4_general_ci without error - and tada - the attachments links started working.

          Write a Reply...