User login returns to the login page

sjswarts

@KevinTheJedi - I've experienced the same issue as @glienhard.

Client attempts to sign up via usual process. Taken to location https://site.com/account.php?do=create.
Client enters everything correctly, clicks register. Sent email successfully with activatation instructions and link.
Link takes them to https://site.com/account.php?confirmed but the page is IDENTICAL to the sign up/register page.

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.

KevinTheJedi

sjswarts

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.

sjswarts

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?

KevinTheJedi

sjswarts

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.

sjswarts

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.

KevinTheJedi

sjswarts

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.

glienhard

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.

sjswarts

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.

glienhard

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.

sjswarts

[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 🙂

cherrie

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?

mpev

cherrie I'm seeing the same problem in Chrome even with the sleep code added but it's working from Firefox

glienhard

@cherrie @mpev I only had this issue with the client logins. The only issues I ever had with the agent login was self-inflicted. I currently use both LDAP and Oauth2 for agent logins and not having any issues. I will say, I'm still running v1.18.1