You should try all the following together:
If not then you will have to wait until I can test which will be a while from now.
Cheers.
I got to thinking about this and I didn't see where any of that would affect the problem. Since the authentication is working it is just the code not handling the session correctly. I ended up running across another thread (https://forum.osticket.com/d/95841-user-login-issue/29) and the suggestion here has almost totally solved the problem
Add this line to the top of the index.php and tickets.php files, before any other php code is processed.
sleep(2);
For me I added it right under the comments at the top but before the include statements. If you are not using OAUTH2 then you only need to add it to the tickets.php file. Since OAUTH2 redirects to the index.php file, it has to be there too for that to work.
One other thing to add...
This whole thing got me to thinking about why this is happening on our new system and never happened on the old one. The old version was v1.12.x and we never had this problem. Yet when I search on it, I find others that have reported it all the way back to v1.9.x. So what is different between the old and new systems. Both systems are VM running in the same cluster so the physical hardware is the same. The old VM only had one processor and 1Gb RAM assigned to it. The new VM has two processors and 4Gb RAM assigned to it. There is a very noticeable performance difference in page loads and interacting with the server in general.
I believe what's happening is that the server is processing page loads so fast that it is over running the session id stuff. Especially since I know that authentication is working correctly and it is correctly redirecting to the next page after login, but since the session id cookie stuff isn't getting there before the page loads, the PHP assumes you are not logged in and therefore is displaying the login content again.
Hopefully this help for future development in getting everything to process in order and consistently display correctly.
@KevinTheJedi if you want to DM me I'm happy to help out with this in any way I can.
Cheers!!
@KevinTheJedi - I've experienced the same issue as @glienhard.
Surely this should take them to Account Confirmed page?
I have not tried to use the "work around" advised by glienhard.
Happy to do any testing.
Yes it’s supposed to take you to an account confirmed page hence the ?confirmed in the URL. They the fix and see as I am unable to replicate this; even with fast servers.
Definitely sounds session related though.
Cheers.
KevinTheJedi They the fix and see as I am unable to replicate this; even with fast servers.
Can you please elaborate? What does "They the fix" mean?
I've just spun up a vanilla installation on the same hosting and the sign up form works as expected. So something is wrong with my installation. I've been using osTicket for many many years. Any hints on figuring out how to resolve this?
lol That was a typo. I meant “Try the fix” as in the “workaround” above you touched on.
If you retry a new user registration, manually copy the full link you receive in the email (the pwreset.php link), paste it in an incognito/private window, and try to visit it does it work then?
Cheers.
KevinTheJedi lol That was a typo. I meant “Try the fix” as in the “workaround” above you touched on.
Ah. That makes more sense 
KevinTheJedi If you retry a new user registration, manually copy the full link you receive in the email (the pwreset.php link), paste it in an incognito/private window, and try to visit it does it work then?
Yeah that's my default process when investigating. No joy however. 
I am happy to try the work around, but I presume it will be wiped next update.
Is there any other way I can narrow it down? I've checked logs (PHP, osTicket, etc) nothing there.
Well being that it works on the new install you did I’d compare settings to see what’s different. Not only system settings but templates, sever settings, etc.
Cheers.
In my case the only thing I can come up with is that my new server has more resources and is running faster/more efficient than the old server and is responding back faster than the code is expecting. This is why I was getting the login page again. Once I added the sleep statements to all pages where authentication redirects to then it was working correctly.
glienhard - I've tried your fix, perhaps I'm placing in the wrong location. I placed it here on both tickets.php and index.php
@KevinTheJedi - The weird thing is that the registration works, the end user is shown the next page advising them to check email. But when they click the link in their email it takes them to the registration page again.
However in osTicket I can see that they are registered. But the password they set doesn't work.
You mentioned looking at templates. They are pretty much stock standard. I can't remember editing them at all.
sjswarts the sleep statement needs to go on the pages that are redirected to after login (open.php tickets.php view.php). I did also include it on both index.php and login.php in the beginning but I don't think it needs to be there. I put the sleep right after the opening comments of the file, before any of the required files are declared.
[unknown] - I've followed your advice. Thank you. Although I changed the sleep time to 1 second instead of 2.
I've placed it in:
public_html\index.php
public_html\login.php
public_html\open.php
public_html\tickets.php
public_html\view.php
It is now working as expected. Which is weird because a fresh install also works without the sleep code.
Bring on v2.0
Having similar problems and still not working only in chrome. Firefox seems fine. Never had this problem prior to installing 18.1.2.
I use osticket only for internal purposes and no clients are logging in. Although I activated the OAuth2 plug in, I haven't set up the functionality for any of the emails yet (which wasn't a problem before).
Primarily, I use the agent ticket webpages. After login on firefox, I correctly go to ticket/scp/index.php and no problems.
On chrome, I get the bounce back to the login page. I added the sleep (2) code to ticket/scp/index.php but still a problem on chrome. Same sproblem with sleep(1)
Any ideas?
