Users cannot add attachments, agents can: Page 2

Users cannot add attachments, agents can

HansAlbers

Yeah we have had a thousands of looks at the file permissions but find no reason in it. And as Kevin mentions, why does it work for agents and not for users? It's the same filesystem and permissions. BTW I already changed the test instance to also use file system, and it still works there. Even while the test instance runs on newer PHP that is not yet officially supported by osTicket. I will try and see if I can downgrade the PHP on the test instance to the same as on our production server to see if I can then duplicate the problem there.

Hans

KevinTheJedi

HansAlbers

Ah, I went back and realized you are using NGINX; don't know how I missed that the first time. Compare your NGINX config with the below and see if you are missing anything. If so update yours, run the NGINX test command on the config file to make sure nothing will break, reload NGINX, and retest.

user  nginx;
worker_processes 1;

events {
    worker_connections  1024;
}

http {
    include         mime.types;
    default_type    application/octet-stream;
    sendfile        on;
    charset         utf-8;
    gzip            on;
    gzip_types      text/plain application/xml text/javascript;
    gzip_min_length 1000;

    index index.php index.html index.htm;

    # Rewrite all requests from HTTP to HTTPS
    server {
        listen 80;
        server_name tickets.mydomain.com;
        rewrite ^ https://tickets.mydomain.com permanent;
    }

    server {
        listen 443;
        server_name tickets.mydomain.com;
        ssl on;
        ssl_certificate /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/cert.key;

        keepalive_timeout 70;

        root /var/www/osticket;

        set $path_info "";

        location ~ /include {
            deny all;
            return 403;
        }

        if ($request_uri ~ "^/api(/[^\?]+)") {
            set $path_info $1;
        }

        location ~ ^/api/(?:tickets|tasks).*$ {
            try_files $uri $uri/ /api/http.php?$query_string;
        }

        if ($request_uri ~ "^/scp/.*\.php(/[^\?]+)") {
            set $path_info $1;
        }

        if ($request_uri ~ "^/.*\.php(/[^\?]+)") {
            set $path_info $1;
        }

        location ~ ^/scp/ajax.php/.*$ {
            try_files $uri $uri/ /scp/ajax.php?$query_string;
        }

        location ~ ^/ajax.php/.*$ {
            try_files $uri $uri/ /ajax.php?$query_string;
        }

        location / {
            try_files $uri $uri/ index.php;
        }

        location ~ \.php$ {
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
            fastcgi_param  PATH_INFO        $path_info;
            fastcgi_pass   127.0.0.1:8888;
        }
    }
}

Cheers.

HansAlbers

Hi Kevin,

Took a while to respond cause I had to get with the guy who manages the webserver part (nginx). I gave him your suggestion to edit the nginx configuration and he said he did, made some corrections to what you gave us but after all now it all works again. First of all a big thank you for helping here and pointing us into the right direction.
Just a question out of curiosity: Do you know or can you explain why we ran into this issue on nginx while on our testinstance, that is running on LightSpeed, this was not caused any issue and we didn't need to configure anything to make it work on that instance? When I asked the webserver admin why it was an issue on nginx he said:
"Nginx was not issue, the issue was osticket needs special URI for ajax.php. You can see this URI was accessed: /ajax.php/form/upload/ticket/attach. but there is no such file under ajax.php folder.
I dont know how LiteSpeed handle the URI which is not pointed to actual files".
he also mentioned "Lightspeed has rewrite engine to handle such jobs to rewrite the "fake" request to actual location."

My question, is this a bug in osTicket, accessing wrong URI, that we are now correcting with the nginx configuration or do you see this differently?

Again, big thanks for your help!

Have a good weekend. Cheers, Hans

KevinTheJedi

HansAlbers

The problem is NGINX is not supported out of the box. Go read the osTicket requirements to see what I'm saying. NGINX is supported just requires its own special config (additional setup). Litespeed is a drop-in replacement for Apache which is fully supported out of the box (ie. no custom config needed). We ship with the relevant .htaccess file and web.config files for Apache and IIS respectively. However, NGINX never worked like that as they saw it as tacky and security issue prone. So they make people add it the "right way" which means we can't ship with our own files that just "work out of the box".

Cheers.

HansAlbers

Many thanks again! Hans

« Previous Page