r91106 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r91105‎ | r91106 | r91107 >
Date:20:24, 29 June 2011
Author:btongminh
Status:resolved (Comments)
Tags:
Comment:
Add wfUnserialize() wrapper around unserialize to prevent E_NOTICE and use it in ExifBitmap.php. There are probably many more places that could use this. This should fix Platonides' problem at r90421, but also added a check for $wgShowExif to prevent the test from failing.
Modified paths:
  • /trunk/phase3/includes/GlobalFunctions.php (modified) (history)
  • /trunk/phase3/includes/media/ExifBitmap.php (modified) (history)
  • /trunk/phase3/tests/phpunit/includes/GlobalFunctions.php/GlobalTest.php (modified) (history)
  • /trunk/phase3/tests/phpunit/includes/media/FormatMetadataTest.php (modified) (history)

Diff [purge]

Index: trunk/phase3/tests/phpunit/includes/media/FormatMetadataTest.php
@@ -1,11 +1,17 @@
22 <?php
33 class FormatMetadataTest extends MediaWikiTestCase {
44 public function testInvalidDate() {
 5+ global $wgShowEXIF;
 6+ if ( !$wgShowEXIF ) {
 7+ $this->markTestIncomplete( "This test needs the exif extension." );
 8+ }
 9+
510 $file = UnregisteredLocalFile::newFromPath( dirname( __FILE__ ) .
611 '/broken_exif_date.jpg', 'image/jpeg' );
712
813 // Throws an error if bug hit
914 $meta = $file->formatMetadata();
 15+ $this->assertNotEquals( false, $meta, 'Valid metadata extracted' );
1016
1117 // Find date exif entry
1218 $this->assertArrayHasKey( 'visible', $meta );
Index: trunk/phase3/tests/phpunit/includes/GlobalFunctions.php/GlobalTest.php
@@ -879,6 +879,12 @@
880880 // are less consistent.
881881 );
882882 }
 883+
 884+ public function testUnserialize() {
 885+ $this->assertEquals( '', wfUnserialize( 's:0:"";') );
 886+ $this->assertEquals( false, wfUnserialize( '0' ),
 887+ 'Invalid input to unserialize()' );
 888+ }
883889
884890 /* TODO: many more! */
885891 }
Index: trunk/phase3/includes/GlobalFunctions.php
@@ -3549,3 +3549,17 @@
35503550 function wfRunHooks( $event, $args = array() ) {
35513551 return Hooks::run( $event, $args );
35523552 }
 3553+
 3554+/**
 3555+ * Unserialize a string to a PHP value without throwing E_NOTICE. Simply a
 3556+ * wrapper around unserialize()
 3557+ *
 3558+ * @param $data string The serialized string
 3559+ * @return mixed
 3560+ */
 3561+function wfUnserialize( $data ) {
 3562+ wfSuppressWarnings();
 3563+ $result = unserialize( $data );
 3564+ wfRestoreWarnings();
 3565+ return $result;
 3566+}
Index: trunk/phase3/includes/media/ExifBitmap.php
@@ -109,7 +109,7 @@
110110 return false;
111111 }
112112
113 - $exif = unserialize( $metadata );
 113+ $exif = wfUnserialize( $metadata );
114114 if ( !$exif ) {
115115 return false;
116116 }

Follow-up revisions

RevisionCommit summaryAuthorDate
r91127(follow-up r91106) Explicitly compare against the self::BROKEN_FILE constants....bawolff22:24, 29 June 2011
r91581Partial revert of r91106: followup to r91127....brion18:47, 6 July 2011

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r90421(bug 29471) Exception thrown for files with invalid date in metadata...btongminh21:38, 19 June 2011

Comments

#Comment by Brion VIBBER (talk | contribs)   21:00, 29 June 2011

Hmm... well shouldn't ExifBitmap *not be trying to unserialize* its disabled-metadata marker in the first place?

#Comment by Bryan (talk | contribs)   21:31, 29 June 2011

There is something icky about ExifBitmapHandler::isMetadataValid() in particular ExifBitmapHandler::BROKEN_FILE handling.

#Comment by Platonides (talk | contribs)   21:48, 29 June 2011

Yes, I don't follow why a BROKEN_FILE is good metadata. That's why I opened bug 29644

#Comment by Bawolff (talk | contribs)   21:50, 29 June 2011

I believe the intention is that if metadata is bad, we go to the file and get new metadata. If the file is broken we'd re-get the metadata on each page view because it'd never be good, which would be bad for efficiency. (I agree that the whole isMetadataValid thing could be better)

#Comment by Bryan (talk | contribs)   07:37, 30 June 2011

Follow-up by Brian in r91127.

#Comment by 😂 (talk | contribs)   18:36, 6 July 2011

This rev shouldn't be necessary anymore with that, right?

#Comment by Brion VIBBER (talk | contribs)   18:48, 6 July 2011

I took out wfUnserialize() and the call to it in r91581. The tweak to disable the exif tests when required libraries are unavailable is kept.

#Comment by Bawolff (talk | contribs)   19:44, 6 July 2011

Most other calls to unserialize are wrapped in wfSuppressErrors anyways. If bad data ever got into the db (which should not happen), it would generate an E_NOTICE. I'd prefer to leave the error suppression in, but don't have strong opinions.

#Comment by Bawolff (talk | contribs)   19:47, 6 July 2011

Or actually we do a validity check before the unserialize that would catch that, so I guess there's no way for there to be an E_NOTICE at this point, so nevermind what i just said :)

#Comment by Brion VIBBER (talk | contribs)   20:10, 6 July 2011

In this particular case we don't need generic validation/error handling for our expected cases, since there's a particular symbolic value we're looking for that indicates we shouldn't try to unserialize. :)

But some others check to see if the item could be unserialized and then have some error-handling code (skip this item, recalculate, whatever). This might feel clearer with a wfUnserialize() wrapper that suppresses the notice on failure but throws an exception -- which can be caught by callers that need error recovery, or left to kill the process & log the exception for cases that weren't expecting it.

Status & tagging log