Login issue for users on v1.18.2

jeffosjase

Hi
Hoping to get assistance on a strange issue with osTicket v1.18.2.
Some users are unable to log in, they get the authentication error message. The workaround for these users is to clear browser history and after that they can log in successfully. Any ideas what is causing this? We've checked on a few computers and some users can log in without clearing browser history. Our osTicket is hosted on a Windows pc using Microsoft IIS 10.0. MySQL version is 8.0.33 and PHP version is 8.4.4.
Any assistance or how to troubleshoot this would be greatly appreciated.
Thanks

KevinTheJedi

jeffosjase

Sounds like some people's browsers are simply having session/cookies issues. After clearing the cookies and sessions it should work fine. If it's a regular thing then you need to:

Ensure you have a cron job running so sessions are routinely cleaned.
Check your User/Agent session timeouts to see if they are adequate.
Check for any related errors in all possible logs within osTicket and on the server.

Cheers.

mrjr7

Interestingly I just noticed we see a "Session timed out due to inactivity" on our end but same experience.

jlamattina

This has been happening for us as well on the same version. Could you perhaps provide further details to those steps @KevinTheJedi ? Maybe this should be addressed in a future update as well.

KevinTheJedi

jlamattina

Could you perhaps provide further details to those steps ?

What do you need further clarification on exactly?

Maybe this should be addressed in a future update as well.

I would love to address this however I simply cannot replicate the issue myself.

Cheers.

jlamattina

I wanted details for steps one and two. It seems I have figured out step one for Windows Server. Open the Task Scheduler, there was already a task for the Cron job set to once per day at 4AM. I added another Trigger to repeated every 5 minutes indefinitely. Under General I changed the Security options to run regardless of if a user is logged in. I also set it to run with highest privileges. We'll see if that helps.

As for step two, I assume you mean the Agent Session Timeout setting in the Admin Panel -> Settings -> Agents . This is set to 30 minutes by default which seems fine.

It's important to note that this issue only occurs when the timeout is reached. Manual logout does not cause issues. I'm curious if the cron job solution will work. There's clearly some mismatch between server and local sessions. Perhaps some local data is wiped on manual logout but not force logout. The login menu should maybe check for the old data and remove/overwrite that since clearly the user is not logged in anymore. I'll follow up with results.

jlamattina

@KevinTheJedi It seems this did not resolve the issue. I opened the web dev tools and manually deleted OSTSESSID cookie then tried again. It then said I did not have a valid CSRF Token, then I logged in again and it worked.

jlamattina

@KevinTheJedi After further investigation, I believe my assumption was correct. On manual logout, the OSTSESSID is reset. On timeout, it is not. This is probably the root of the issue. Timed out sessions need to reset the local OSTSESSID cookie.

KevinTheJedi

jlamattina

If you revert the below commit and retest does it work or same thing?

https://github.com/osTicket/osTicket/commit/3a5da66bf62ec6913ae94bf8bc638f037b513593

Cheers.

jlamattina

I made those changes and it looks like the OSTSESSID still holds on session timeout. Do I need to restart the service or anything like that?

KevinTheJedi

jlamattina

Okay then I’ll have to do deeper digging; which it will be some time before I can do so. Feel free to go through the commits on GitHub and try reversing some of the latest ones that deal with sessions to see if you can narrow it down.

Cheers.

jlamattina

Hello again @KevinTheJedi . I believe I can resolve the issue. The server-side session data expires, probably from TTL or garbage collection, but the cookie doesn't get cleared or regenerated. The session ID is now stale. There are probably several fixes such as detecting if the session is empty or invalid and clearing and regenerating the cookie if so, or just automatically do it upon every login attempt. It depends on how the cookie is created in the first place.

From testing, it looks like the cookie is created as soon as any of the site is loaded. I'm not familiar enough with all the details of this project or login design in general (yet), but I don't think the login session cookie should be the same as the overall site usage session cookie. The suggestion I made would probably still work, but I think it's a band-aid solution. I'm going to try to find all the details of the login and the session systems. I suspect the more permanent solution would be creating separate cookies and just clearing the session id and data of the login session upon any type of exit (manual or timeout).

Feel free to point me in some direction and let me know what you think. I'm kind of just exploring around and theory crafting.

KevinTheJedi

jlamattina

Once you “get into the weeds of it” you’ll see everything you’re suggesting is already in-place. There is likely just a small bug somewhere throwing this off.

Cheers.

Jsezze

I have been paying attention to this issue since the new version was released. According to my experience and observation, if you open the background address and log in immediately, a session error will often be prompted, but if you wait for a dozen seconds or longer before clicking to log in, there will be no session timeout problem.

KevinTheJedi

Jsezze

If you remove the following two lines does it start working again?

https://github.com/osTicket/osTicket/blob/develop/include/class.usersession.php#L143-L144

Cheers.

jlamattina

Hello @KevinTheJedi ! I believe I've resolved the issue. I'm sure there are methods implemented that should properly automatically log out the user on timeout, but perhaps there is a bug like you mentioned.

I see there is specific code for unsettings the staff token portion of the session and clearing the staff auth portion, but perhaps that's not quite enough. Anyways, hopefully this doesn't mess anything up. I appreciate the help.

Edit: Alright I think I have it completely resolved.

Basically I added two sections, one to class.usersession.php under the "isvalidsession" function and one to logout.php under the "try" section. Basically I copy the CSRF token from SESSION['csrf']['token'], empty the SESSION , then add the CSRF token back to $_SESSION['csrf']['token']. This resets the OSTSESSID on page reload, but maintains the valid CSRF token.

Jsezze

KevinTheJedi This login problem has not occurred in the past month. I will try this method and continue to observe and understand the situation. However, I have encountered another new problem recently. Since CloudFlare SSL/TLS Full (strict) was enabled, the background system log has reappeared the error prompt of stranger visit. I have tried to change the scp path through .htaccess to prevent stranger access, but it will cause errors in the internal function links of the system. If there is any update, I will reply again. Thank you Kevin.