Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Broken User login after testing and removing passthru plugin


We are still in the testing/evaluation phase of using osTicket 1.10.1. So far we like the overall design, feature set, and work flow. I have run into several issues testing the LDAP/AD and pass-through auth plugins, but will focus here only on the problems we are experiencing now that they are disabled and uninstalled.

First, a user created an account by registering on the Landing page, and opened a ticket.

Then I installed and configured the LDAP/AD plugin. I created an Agent associated with the same user through LDAP. He was then able to log in using his AD credentials as a User and see the ticket that he had opened prior to the plugin being installed, and log in to the Agent portal and respond to tickets.

Then I installed and tested the Pass-Through Authentication plugin. I was able to make the Agent login work, but the User login did not. It logged this error:

PHP Fatal error:  Uncaught ObjectNotUnique: One object was expected; however multiple objects in the database matched the query. In fact, there are 2 matching objects. in /var/www/html/osticket/include/class.orm.php:1176\nStack trace:\n#0 /var/www/html/osticket/include/class.orm.php(545): QuerySet->one()\n#1 /var/www/html/osticket/include/class.client.php(295): VerySimpleModel::lookup(Array)\n#2 /var/www/html/osticket/include/class.auth.php(656): EndUser->getAccount()\n#3 /var/www/html/osticket/include/class.auth.php(143): UserAuthenticationBackend->login(Object(ClientSession), Object(UserHttpAuthentication))\n#4 /var/www/html/osticket/login.php(117): ClientCreateRequest->attemptAutoRegister()\n#5 {main}\n  thrown in /var/www/html/osticket/include/class.orm.php on line 1176

In order to continue testing, I disabled and uninstalled the pass-through authentication plugin for now. However, this multiple object return seems to persist, causing breakage in a number of places.

The worst is what happens when the above User tries to log in. Using his AD credentials in the web form now throws this error, which also exposes his AD credentials (redacted here):

PHP Fatal error:  Uncaught ObjectNotUnique: One object was expected; however multiple objects in the database matched the query. In fact, there are 2 matching objects. in /var/www/html/osticket/include/class.orm.php:1176\nStack trace:\n#0 /var/www/html/osticket/include/class.orm.php(545): QuerySet->one()\n#1 /var/www/html/osticket/include/class.user.php(1152): VerySimpleModel::lookup(Array)\n#2 /var/www/html/osticket/include/class.auth.php(1203): UserAccount::lookupByUsername(*redacted_username*)\n#3 /var/www/html/osticket/include/class.auth.php(235): osTicketClientAuthentication->authenticate(*redacted_username*, *redacted_password*)\n#4 /var/www/html/osticket/login.php(52): AuthenticationBackend::process(*redacted_username*, *redacted_password*, Array)\n#5 {main}\n  thrown in /var/www/html/osticket/include/class.orm.php on line 1176

The fact that the password is exposed in the error log is the most concerning part of this. I have now disabled and uninstalled the LDAP plugin. If we do move forward I will only enable it with Pass-Through working so that osTicket never receives the password.

There are other odd symptoms throughout the interface, but the errors in the log are basically this same multiple-object return, so there isn't much point in describing them in detail.

My questions for you are:

  1. It is a serious concern to me that a data error would expose the user's credentials in the error log. Do you share this concern?
  2. It is also a concern that the Pass-Through Auth plugin is apparently capable of corrupting the user data to make it unusable. Do you understand what is going on here? I would think the object interface would be abstracted enough to prevent this.
  3. Do you know what I need to change in the data to relieve the error so I can resume testing? I could just wipe the database and start over, but I would feel better about this if I could understand what went wrong.


  • Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.

    No environment details.
    No versions etc.

    1. no.  Properly configured PHP does not display the error message on the screen.  
    Additionally a properly secured system would require escalated privs or to log into an account to view the logs anyway.

    2. I never got HTTP pass through working in my environment, it does not change a users account however so... there is no corruption possible.

    3. No idea.
  • Thanks for your response.

    Sorry for the missing details. Ubuntu 16.04.3, PHP 7.0.22, Apache 2.4.18, FWIW.

    With respect to 1, the fact I have admin rights to a web server (or its syslog target) does not mean I have the right to view the AD passwords of others in the company. It is not ethical for an admin to be asking for or viewing the passwords of users.

    I would also think the corruption would not be possible, but something corrupted it. If I figure it out I'll let you know.

  • I found the data error. Apparently the Pass-Through Auth plugin caused a second row to be created in ost_user_account for user_id 4. The first row ended up with a NULL username, but retained the password. The second one had the appropriate username but no password. I deleted the second row and updated the first one to have the right username. The username must be unique, so I had to do the delete first.

    So something allows duplicates to be created in ost_user_account by user_id, but when querying for them, duplicates are not allowed so it throws an error.

    Not sure why the auth plugin causes a second ost_user_account row to be created.

  • I did a bit more testing. The pass-through and LDAP plugins are enabled again, and all is working as expected.

    This is a problem which should be highly unlikely in production because the work flow to generate it is to create a user with local auth, switch to LDAP and log in, and then switch to pass-through or back to local auth. Generally you would have one authentication scheme and never change it.

    However, this represents 3 serious bugs:

    1. Errors in authentication should be trapped and logged with useful information, taking extreme care not to dump the array containing the password in the error log. Passwords by their nature should never be exposed. Even domain administrators do not have access to view user passwords.
    2. Duplicate ost_user_account rows represent data corruption which should be handled sensibly. Crashing with an unhandled exception generates a server 500 error which causes all sorts of odd behavior. For example the Users listing was actually missing the affected user and contained duplicates of a different user. Viewing the ticket from the affected user only partly rendered the page, so the replies were missing, and some menu options were broken. Rather than completely breaking the application, corruption of a single account's data should only impact retrieving the data for that account and generate a warning.
    3. Nothing in the LDAP or pass-through backends explicity creates a database row. This is inherent to the AuthenticationBackend class. It should not modify account data in a way that it will subsequently not be able to read it.

    I bring this to your attention in an effort to be helpful. We are hoping this application will work well for us.

Sign In or Register to comment.