User login returns to the login page: Page 2

User login returns to the login page

KevinTheJedi

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

sgticket

I was having a similar issue with the log-in not always working, and returning users to the log-in page.
It turns out OSTicket doesn't like it if the session ID is a different length to what it expects, or contains non-alpha-numeric characters.
You can of course configure this in your php-fpm.d/php.ini etc, but you can also set (potentially more conveniently depending on your hosting arrangement) in the /include/ost-config.php by adding:

ini_set('session.lazy_write', '0');
ini_set('session.sid_length', '32');
ini_set('session.sid_bits_per_character', '4');

... to the end of the file.
Hope this is helpful to some one.

glienhard

sgticket That's an interesting find. We have continued to have intermittent problems and I'm thinking it could be this session ID thing you found. I'm going to add your suggestions to the ost-config.php file and see if that resolves what we are seeing.

« Previous Page