Osticket: CSRF token broken when behind reverse proxy

Your reverse proxy should send X-Forwarded-For. Does it?

Yes, the reverse proxy is setting X-Forwarded-For to the correct address. The client is behind a NAT, and so the Javascript could potentially be getting a RFC1918 address, if it's getting bound interface addresses (unclear if that's happening).

Can you verify the cookie settings between the proxies server (where osTicket runs and the client)? Check the cookie domain and cookie path of the returned cookie and ensure that none of the servers in between are mucking with the cookie or cookie settings.

I'll check it out, but that could very well be where the problem lies (internal host domain and domain as proxied are vastly different). I'll update in a couple hours.

I know this post is over a year old, but popped up several times while trying to setup my reverse proxy with osTicket. I'm using NginX as my reverse proxy (I know, not supported, etc etc) with a few tweaks I was able to get passed the "Invalid CSRF Token" error.

in my location block I needed to add a few header settings:

 location / {
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass_header       Set-Cookie;
            proxy_pass <Backend osTicket location>;
        }

The pass_header was what seemed to make it work, but the other settings will make sure your server receives the correct IP address. I believe you could set those settings in the server or http block as well, but this served my needs.

@webbe we don't officially support nginx as the server for osTicket. You can use whatever you want for the reverse proxy. Personally, I prefer HAProxy. Thanks for posting your configuration info, and glad you got your setup working.