I know that this has been an issue in the past but I'm unable to find a solution. This is a fairly big deal as it's affecting my user's ability to login to the system.

  • Affects all users.
  • Takes one to many attempts to for a user to get to the place where they can access their tickets.
  • All custom code has been disabled.
  • Attempted from multiple computers and multiple browsers, mostly using incognito/private to ensure there is not a cookie issue.
  • Happens to all types of users (local auth, ldap, oauth, any available).
  • Cleared out ost_session table
  • Only happening on the user side, agent login is fine.
  • login.php redirects to tickets.php but still displays the content from login.php
  • If wrong password is typed in, it correctly displays the "Access denied" message.
  • KevinTheJedi replied to this.
  • andrewphilmorgan likes this.

  • KevinTheJedi

    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.

      KevinTheJedi

      I was thinking the exact same thing.

      I created a new db and a new folder and extracted the source into the new folder. Went through the setup just fine. Under Settings->Users I checked the Registration Required and set the Registration Method to Private. I added the http passthru and ldap plugins and configured them appropriately. Then added a user. When I registered the user from the admin panel, I choose Any Available Backend, set a password, and checked the user cannot change password box. I added another user but the only difference was setting auth to just local.

      When I try to login with either user I'm getting the exact same problem. Authentication appears to be good (no red bar saying access denied), the url is tickets.php but the content is the login page.

          KevinTheJedi

          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.

              KevinTheJedi

              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!!

                5 months later

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

                1. Client attempts to sign up via usual process. Taken to location https://site.com/account.php?do=create.
                2. Client enters everything correctly, clicks register. Sent email successfully with activatation instructions and link.
                3. 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.

                    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.

                        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?

                            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.

                                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.

                                      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.

                                        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.

                                                16 days later

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

                                                10 days later

                                                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?

                                                Write a Reply...