Authentication Required loop on scp/login.php (Invalid CSRF Token __CSRFToken__)

Authentication Required loop on scp/login.php (Invalid CSRF Token CSRFToken)

VanGoghGaming

This is a fresh install of Osticket 1.8.1:

I cannot log into "scp/login.php" unless I manually TRUNCATE the ost_session table from PhPMyAdmin and even then the session is rather short, it only allows me a few minutes before it asks me to log in again. It doesn't even check the login credentials, whatever I enter in the username/password boxes, it just loops back to login.php with an "Authentication Required" message.

The system logs dashboard is full of "Invalid CSRF Token CSRFToken" messages but that doesn't help me at all. The only thing I can think about is that my website is behind Cloudflare and that somehow messes with the authentication but I am not knowledgeable enough to make heads or tails of it. It doesn't seem to affect any other authentication like from my PhPBB forums or whatever, they all work fine.

I have already searched these forums and while there are many other similar issues to this one, none of them provides a working solution. I had the same issue on an old "Osticket 1.6 ST" install but I've decided to scrap that one as it was too old and replace it with the latest version. Back then I solved this issue by manually editing "login.php" and adding this line right after "session_start();":

session_start();
setcookie(session_name(), session_id(), NULL, NULL, NULL, 0);

This workaround is no longer working. Can anyone provide some helpful insight as to what I can do to root out the cause of this annoying issue?

KevinTheJedi

VanGoghGaming

Update this in your config file:

https://github.com/osTicket/osTicket/blob/develop/include/ost-sampleconfig.php#L117-L136

Cheers.

VanGoghGaming

Thanks Kevin, in all fairness I did come across this very suggestion in an older post but would you mind being a little bit more specific please? What exactly should I put in there?

define('TRUSTED_PROXIES', ''); // <-- I tried putting the server IP in there and even a single wildcard "*", doesn't work...

KevinTheJedi

VanGoghGaming

Try disabling your Bind Agent Session to IP setting, clear all sessions in database, clear all cookies/sessions in the browser, and retest.

Also, ensure your load balancer/proxy is sending the user's real IP via the HTTP_X_FORWARDED_FOR header.

Cheers.

VanGoghGaming

I've never used the "Bind Agent Session to IP" setting, it is disabled by default.
I have tried:
define('TRUSTED_PROXIES', '*'); as well as define('TRUSTED_PROXIES', $__SERVER['HTTP_X_FORWARDED_FOR']);
in the config file. It doesn't make any difference at all.

The session works for about 5-10 minutes after I empty the ost_session table and then randomly goes into an authentication required loop until I empty the session table again.

Upon inspection, $_SERVER['HTTP_X_FORWARDED_FOR'] holds two IPs: my own IP and the IP of the Cloudflare server.

Why can't you implement a normal cookie-based authentication scheme, like this forum right here? It hasn't required a new login for me all day! 🙂

KevinTheJedi

VanGoghGaming

It's not always that easy lol We have noticed some session issues in specific instances but it's on our bug sheet to look further into. I will say that sessions issues usually don't happen that often; especially every 5 minutes (if it happens it's usually like once a month or even longer).

Have you tried updating your Agent Session Timeout to 0 (which makes it 24 hours)?

Cheers.

VanGoghGaming

Also, while I'm here, I have another smaller issue as well. In the Ticket Attachment Settings -> Config, the "Restrict by File Type" and "Maximum Files" options never get saved in the database when I click "Save":

I have another osTicket install on my local PC (running under XAMPP for testing purposes) and everything works like clockwork there...

KevinTheJedi

VanGoghGaming

Then definitely seems like something going on there with this cloudflare environment. Unfortunately, I cannot see what's going on so I'm unable to give a suggestion.

Cheers.

VanGoghGaming

It doesn't really make sense because ALL other settings are saved correctly in the database except those two. Unfortunately I don't know enough PHP to investigate the code behind the Save button there...

Yeah I've also set Agent Session Timeout to 0, doesn't make any difference. As soon as the "Invalid CSRF Token CSRFToken" messages start to creep up in the logs, I get logged out and then I need to clear the ost_session table to be able to log in again (all browsers behave the same in this regard, tried Chrome, Edge, Firefox).

VanGoghGaming

As far as I've been able to assess with my limited PHP knowledge is that there are way too many "header()" redirects in your code, jumping from one PHP file to another and that's bound to be the root of these authentication tokens being lost somewhere in the process... I may be talking nonsense though, haha!

KevinTheJedi

VanGoghGaming

It all depends on what you mean by "too many redirects". It shouldn’t redirect much at all; only when necessary. It could be webserver rules or maybe some cloudflare rules causing the excessive redirects.

As far as that setting not saving goes it could simply be a bug.

Cheers.

VanGoghGaming

Yeah it could be a bug but a rather insidious one as it saves correctly on my local XAMPP server.

I am not talking about excessive redirects but it is my understanding that a header() redirect can cause issues between HTTP -> HTTPS conversion and parameters getting lost. Sorry I can't be more literate in this regard.

VanGoghGaming

Is there any chance this issue could be looked into in the near future? I'm sure there are many people using Cloudflare on their sites.

This issue also extends to the "Open a New Ticket" page (/open.php). For example, if the "ost_session" table hasn't been cleared then it is not possible to create new tickets. As soon as the "Create Ticket" button is clicked (without even entering any information in the new ticket page) the page is simply redirected back to "/index.php". It doesn't even attempt to check the input fields or the captcha for valid information...

KevinTheJedi

VanGoghGaming

People have been using osTicket with cloudflare for years so I’m not sure what your particular issue is. Like I said before we have seen session issues with specific instances but they are nowhere near as bad as your case. We do have this on our bug sheet to look into at a later date. If I were you I would google osTicket with cloudflare to see if there are any guides, etc. to see if you are missing something.

Cheers.

KevinTheJedi

VanGoghGaming

You can see here that a recent user resolved this by disabling the bind agent session to ip setting (which is what we saw with the other instances with session issues I mentioned above):

https://github.com/osTicket/osTicket/issues/6645

We also saw that here:

https://forum.osticket.com/d/103989-keep-getting-logged-out-of-admin-panel-almost-immediately

Cheers.

VanGoghGaming

It's none of those things, as I said above the same thing happens for a client trying to open a new ticket without needing any sort of authentication.

I've managed to narrow it down and the problem is the $_SESSION['csrf'] variable is getting lost somewhere in all those redirects, it becomes NULL. So that's the cause for all those "Invalid CSRF Token" messages in the logs.

Do you have any insight as to why isn't the session preserved? I do have a ".htaccess" redirect for all pages from "tinyminer.com" to "https://www.tinyminer.com" although I'm not sure whether this plays a part or not...

KevinTheJedi

VanGoghGaming

If using Apache you should have a proper VirtualHost config with the 443 block configured and set an HTTP -> HTTPS redirect in the main 80 block. That’s the proper way to do HTTPS redirects at the webserver level.

You should also ensure cloudflare is preserving all headers and session variables. Do you have another site like Wordpress running on the same server/setup? If so that and any plugins might be affecting this flow.

Cheers.

Jsezze

This feature work for me, my web server is apache2.

VanGoghGaming

To be honest, the issue was much more mundane than I could've imagined. It didn't have anything to do with Cloudflare or HTTP -> HTTPS redirects at all.

It turns out the problem was caused by a "Header set Set-Cookie" instruction in ".htaccess" that was effectively overwriting all others headers and so the "$_SESSION" variable was lost causing all sorts of authentication issues.

Changing "Header set Set-Cookie" to "Header add Set-Cookie" promptly fixed everything and it's been smooth sailing ever since. Sorry for the trouble! 🙂