HTTP error 500 on login after PHP 8.1.4 upgrade [SOLVED]

Hi,
I've upgraded PHP on our development server from 7.4.22 to 8.1.4.

The loading page works, LDAP all appears OK using phpinfo and ldapsearch, however, as soon as I enter my credentials to log in and return, an HTML Error 500 not found is returned. Might someone have any suggestions on how to diagnose this issue?

Previous PHP upgrades have gone smoothly (except when LDAP was disabled on the move from 5.4 to 7.3), however, the issues I had then, aren't being replicated in this error.

PHP 8.1 really changed a lot, and we have not yet checked whether Xerte works properly on PHP 8.1 (apparently not).

You should have an indication what goes wrong in the apache error log.

We know that Xerte works fine on PHP 8.0

Having said that, I just installed a new Xerte installation on XAMPP with PHP 8.1.4., the basic functionality all seems to work fine.

So, I would be curious and interested to hear if you can find an error in the apache2/php error log.

I don't have LDAP here to test that.

There wasn't any meaningful info in the logs (/var/log/httpd/error_log), so we went back to 7.4 snapshot that we had, then installed 8.0.17.

Unfortunately, we experienced the same error. i enabled the debug log, which showed the following:

---

Warning: fopen(/var/www/html/error_logs/USERNAME.log): Failed to open stream: Permission denied in /usr/local/projects/xerte/www/html/website_code/php/error_library.php on line 123

Fatal error: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/projects/xerte/www/html/website_code/php/error_library.php:127 Stack trace: #0 /usr/local/projects/xerte/www/html/website_code/php/error_library.php(127): fwrite(false, '<p>9:20:17 - 09...') #1 /usr/local/projects/xerte/www/html/website_code/php/error_library.php(54): write_message('USERNAME', 'ADMIN', 'SUCCESS', 'Succeeded in up...', 'Succeeded in up...') #2 /usr/local/projects/xerte/www/html/website_code/php/user_library.php(230): receive_message('USERNAME', 'ADMIN', 'SUCCESS', 'Succeeded in up...', 'Succeeded in up...') #3 /usr/local/projects/xerte/www/html/website_code/php/login_library.php(431): update_user_logon_time() #4 /usr/local/projects/xerte/www/html/index.php(51): login_processing2() #5 {main} thrown in /usr/local/projects/xerte/www/html/website_code/php/error_library.php on line 127

---

All of the log files in such as USERNAME.log, USERNAME1.log, USERNAME2.log, SUCCESS.LOG, LOGINS.log, all had -rx r-- r-- permissions.
We found that if we changed all of these log files to -rw -rw -rw (666), we could load Xerte. These permissions may not be the best? Also, if there was a new user who hadn't logged in before, they are unable to because a new log file could not be created/written.

This all worked in our previous PHP version, so I'm wondering if the new version is enforcing more security.

Hi,

As far as I know, the permission issue has nothing to do with PHP. It is purely enforced by the OS. A permission of -rx r-- r-- feels very weird to me. I would have expected a permission of rw- r-- r-- on all the files and a permission of rwx r-- r-- on the folder error_logs (if the owner is the user that apache runs on, this would be www-data on Ubuntu for example).

New user not being able to create a new log file has to do with the permission and ownership of the error_logs folder.

This error however might have been handled differently in PHP 7.x:

Fatal error: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given

I am quite sure, that was not a fatal error previously. Again, to fix this, make sure the apache user is able to create a file in the error_logs folder.

Many thanks for your help Tom. The issue was fixed by amending the individual files within the error_logs folder, and changing the permissions on that folder itself, so new files could be created as required.

I did have a typo in my previous post, in that the permissions were originally rw r-- r-- .and not rx r-- r-- as I previously said (which you also thought looked weird).

We remained on 8.0.17, and no other issues were picked up in the extensive testing that was done.