KevinTheJedi I may be misunderstanding my institutions issue with it. I'll ask and see what I can figure out.

    @awstech did you ever have any further luck with this? Making some progress at my institution but it's coming slowly.

    KevinTheJedi That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

        Fixed!!!!

        Workaround was to unphar auth-ldap.phar, point the database to the folder, and set isphar=0. Honestly, still not entirely sure what the issue is in the first place...Dunno if the workound hints at that.

        Sounds like phar is disabled on the machine in php.

        @rgonig2

        That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

        Thank you for the suggestion. I will add this to the list of requested features for future versions.

        Cheers.

        On the link that you provided...
        Look at Configure Command section.
        about 60% of the way down you will spot '--disable-phar'

        (Yes I know it says later in the Phar section that it is enabled... but passing that at commandline should disable it)

          ntozier Ah, okay. I did notice that but saw that the plugin enabled later and assumed that meant it ended in an enabled state

            3 years later

            The same problem happened to me, changed the ownership after copying from root to www-data, I am able to configure.
            sudo chown www-data:www-data auth-ldap.phar
            sudo chmod 777 auth-ldap.phar

            2 years later

            Same here I just changed Chown for storage-fs.pfar is the plugin started to work. ¸

            I use MC (Midnight Commander)

            Write a Reply...