Trouble with new install

houstonbofh

I am now on the second day of trying to install osTicket. Ubuntu 22.04 with the ppa for php8.2 and osTicket 1.18 from February. I get it installed, and get email working. I shut down to take a backup of the image, and when I came back to log in it would not take the password. So I wiped the database and started again, but added a second admin user this time. And once again, after email is working and cron is up and emails are importing, I took a backup and came back later and could not log in. To either account. The first time I tried resetting the password with the bcrypt hash, but it did not work, and now that two user accounts both fail I don't think that is worth trying. Any ideas why a working system suddenly decides not to accept my password?

KevinTheJedi

houstonbofh

Did you try clearing all cache/cookies/sessions? Did you try incognito window or even a new device/browser?

Cheers.

houstonbofh

KevinTheJedi Yes, tried different browser and different device.

KevinTheJedi

houstonbofh

Like you encountered the issue on one device so you immediately tried logging in on a new device and encountered the issue straight away? Even clearing all cache/cookies/sessions doesn’t let you login?

Cheers.

houstonbofh

KevinTheJedi My default browser is firefox with Ublock Origin so it can case issues. I am used to immediately trying Edge as it is un-molested. No luck. So I tried my tablet and laptop. Same behavior. I am useing nginx to proxy to the outside, and I thought that was the issues, but the second install I have not used the proxy yet, only internal in case the issue was caused by hacking.

But now for the bizarre part... This morning it works? No changes, it just allowed me to log in. (Was going to take a screenshot) But this is actually worse. I can not roll it out when I can not know if an agent can log in... So I need to know what is happening. The only thing I see in the logs at this time is;

Invalid CSRF Token CSRFToken

Invalid CSRF token [7d372c6559f352392ec3135bf897bbdacbee59ac] on http://192.168.64.138/scp/login.php
Log Date: Friday, November 28, 2025 at 3:18 PM IP Address: 192.168.64.94

Does the token change on reboot but not age out of the browser? That makes a reboot scary...

KevinTheJedi

houstonbofh

What do you mean exactly? If you reboot the server the CSRF would be invalidated. If you immediately visit the browser and attempt a request it would fail due to invalid CSRF token. You have to refresh the page first so the application can recognize the outdated session and generate a new one with a new CSRF.

Edit:
Actually by default sessions are stored in the database so they should be persisted after reboot.

Cheers.

KevinTheJedi

houstonbofh

You can also try this as it may be related:

https://forum.osticket.com/d/107217-access-token-mailed-to-my-user-wont-work-sometimes/2

Cheers.

houstonbofh

So... Some progress. I went to get groceries and when I came back, the web browser I left open kicked me to a login screen on refresh. I tried to log in and failed. So I opened Edge and successfully logged in. Looking at the logs, I am failing with error but different tokens...

Invalid CSRF token [c3a84cfbf14f471d192a1a0fa9d552399950c899] on http://192.168.64.138/scp/login.php
Invalid CSRF token [b72b1b80e2177da59b943b9f314a0d0b535b73c7] on http://192.168.64.138/scp/login.php
Invalid CSRF token [bed3ec28e465c894b67a85c8c8ff7d16492283d3] on http://192.168.64.138/scp/login.php
Invalid CSRF token [fa49bec1956042f4c6e450e317153a0dcf7bc05b] on http://192.168.64.138/scp/login.php

These are all within 5 minutes.

Could this be something about leaving it open?

KevinTheJedi

houstonbofh

If you didn’t revert the patch like I posted above in an earlier comment and you let the session expire then yea it would potentially crap out and would require you to clear all cache/cookies/sessions (or use a new browser) to login again. There is a known bug with authenticated session that is fixable by reverting a specific patch (explained in the link I posted earlier).

Cheers.

houstonbofh

I thought that was just for guest sessions, and not agent sessions. My misunderstanding.

So to be clear, I go to include/class.ostsession.php and change the line "$this->ttl = $ttl ?: ($maxlife ?: SESSION_TTL);" to "$this->ttl = min($ttl ?: ($maxlife ?: SESSION_TTL), $maxlife);" specifically adding $maxlife to the end? There is a comment added as well, correct?

KevinTheJedi

houstonbofh

It’s more than just adding the variable on the end. You replace the stuff in green with the stuff in red. The comment isn’t required; it’s simply a comment.

Cheers.

houstonbofh

Do I need to reload anything or reboot to apply the change?

KevinTheJedi

houstonbofh

Yes, your webserver and php-fpm if you run it.

Cheers.

houstonbofh

Applied the changes and restarted the web server, and left open stale screens and it seems to be working now. Thank you for all your help!