WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 8 years ago

Last modified 5 years ago

#1335 closed defect (bug) (wontfix)

path info is disclosed

Reported by: anonymousbugger Owned by:
Milestone: Priority: normal
Severity: minor Version: 1.5.1
Component: Administration Keywords: bg|squashed
Focuses: Cc:

Description

Bringing up http://www.yourblog.com/wp-admin/admin-footer.php results in server path info being disclosed. Specifically, you see:
Fatal error: Call to undefined function: bloginfo() in /home/username/public_html/wp-admin/admin-footer.php on line 3

Change History (9)

comment:1 anonymousbugger9 years ago

  • Patch set to No

comment:2 anonymousbugger9 years ago

Re-adding deleted note:

Just turn off display_errors in php.ini!

comment:3 twistedraisin9 years ago

Could this be fixed with something like
ini_set('display_errors','Off');

in the initialization sequence, perhaps based on a debug setting?

perhaps adding

define('WP_OUTPUT_ERRORS',false); to the wp-config.php file, and making it conditional on that, or adding a new option on the admin page, and making it conditional on that, with the default being false?

comment:4 anonymousbugger9 years ago

what sort of fix is this for people that do NOT have access to their php.ini? Sure seems like a lazy solution to something that should be trivia for any software application.

comment:5 twistedraisin9 years ago

ini_set() does not require access to the php.ini file, and it affects only the script as it is running, which is why I suggested it be put in the startup sequence.

As for having it based on a defined constant or on a setting, I think that makes good sense for people who are writing or testing, being able to turn on and off errors to see if the code gracefully fails without affecting headers and output that get shunted out when the error occurs.

comment:6 anonymousbugger9 years ago

twisted raisen, yes youre idea is fine -- it was the first solution I was responding to -- totally unacceptable to me. plugging up Path disclosures and php errors should be handled within the application itself -- NOT by having to modify one's php.ini, which not only can not all people do .. but some ppl LIKE having debugging/error output turned on for other reasons.

comment:7 MC_incubus9 years ago

This strikes me as something that is a universal complaint about PHP. But also consider that without errors shown, it will be very hard for regular users to report bugs in WP or in WP plugins. There will have to be a whole "well, turn on errors by editing this file and changint this constant or commenting out this line" ordeal.

comment:8 markjaquith8 years ago

  • Keywords bg|squashed added
  • Resolution set to wontfix
  • Status changed from new to closed

comment:9 thenlich6 years ago

Related to #1038

Note: See TracTickets for help on using tickets.