The check if certificates exists currently involves file_exists which can throw an WSOD making it impossible to change the values in the ui. It might be a good idea to catch exception like this and deal with them gracefully without causing WSOD.

CommentFileSizeAuthor
#3 samlauth-wsod_obenbasedir_restriction-3300383-2.patch2.84 KBrudi teschner
#2 samlauth-wsod_obenbasedir_restriction-3300383.patch2.84 KBrudi teschner

Comments

Rudi Teschner created an issue. See original summary.

rudi teschner’s picture

rudi teschner commented
StatusFileSize
new samlauth-wsod_obenbasedir_restriction-3300383.patch2.84 KB

Suggestion would be to suppress potential errors/exceptions caused by file_exists and improve the notice - way better then wsod.

rudi teschner’s picture

rudi teschner commented
StatusFileSize
new samlauth-wsod_obenbasedir_restriction-3300383-2.patch2.84 KB

Small autoreplace mistake

  • japerry committed 7497df4 on 8.x-3.x 
    Issue #3300383 by Rudi Teschner: WSOD on file_exists open_basedir...
japerry’s picture

japerry
Location KOMK
commented
Status: Active » Fixed

Looking at the file_exists docs I think this is an acceptable solution. Fixed!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented

I'm not going to revert this (because 'me finding additions of @ without clear reasoning' is not enough reason for that / the addition does nothing bad)... but still this has me wondering...

  • open_basedir restrictions don't cause WSODs or throw exceptions. They emit an E_WARNING.
  • standard Drupal does set_error_handler('_drupal_error_handler'). This does not generally cause a WSOD. (I tested; it just logs to watchdog and adds an ugly-long error message to the screen output.)
  • so it seems to me that your _drupal_error_handler() is throwing a fatal exception, or you've registered another error handler that's throwing one.
  • and... if an error handler causes a WSOD, shouldn't you be debugging/fixing that instead? Because it feels like now you can still get WSODs from E_WARNINGs being emitted elsewhere.

In other words: this is fixing a symptom of a deeper problem on your system. The symptoms just don't occur that often (because Drupal code is quite good about not emitting E_WARNNGs / maybe the samlauth admin screen is the only place your system can get away with having a non-reachable file without being fatally impaired) - so you only see it on the samlauth admin screen. But still it feels like you shouldn't be trying to fix the symptom to suppress the deeper problem (as was done here).