Unable to upload profile photos to S3 after upgrade

[Mister Java]

Hey there, I recently upgraded my community from an ancient 4.3 to the latest 4.7.16. Upgrade mostly went smoothly, with one exception: specifically, we're now unable to upload profile photos to S3 (this previously worked pre-upgrade). Other uploads work: image attachments to posts and cover photos work just fine and upload without issue. It's specifically profile photos that seem to have an issue.

I've attempted to upload multiple gif, png and jpg images with essentially the same result: select a photo, it seems to get uploaded to the S3 bucket under monthly_YYYY_MM, but then upon pressing Continue the POST to /profile/<id>-<username>/photo/?ajaxValidate=1 fails with a 500. Seeing errors like this in our system logs:

InvalidArgumentException:  (0)
#0 /var/www/<path>/system/File/File.php(1577): IPS\_Image::create('????\x00\x10JFIF\x00\x01\x01\x01\x00...')
#1 /var/www/<path>/applications/core/modules/front/members/profile.php(1422): IPS\_File->thumbnail('core_Profile', 240, 240, true)
#2 /var/www/<path>/system/Dispatcher/Controller.php(107): IPS\core\modules\front\members\_profile->editPhoto()
#3 /var/www/<path>/applications/core/modules/front/members/profile.php(84): IPS\Dispatcher\_Controller->execute()
#4 /var/www/<path>/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\front\members\_profile->execute()
#5 /var/www/<path>/index.php(13): IPS\_Dispatcher->run()
#6 {main}

Stepping through the code, it looks like the exception is being thrown on L109 of system/Image/Image.php:

		if ( $imageType === NULL )
		{
			throw new \InvalidArgumentException;
		}

I suspect it's due to the first 4 bytes being "????" so it can't determine the type based on the header "signature" but I'm having trouble determining where things are going wrong to corrupt the header/image in the first place.

I've toggled between both GD and Imagemagick with the same result.

It's worth noting that on a hunch I switched the storage of profile photos to a local directory, and was able to upload photos again. But this isn't a feasible option for us. Worse still, the automated move back to S3 afterwards seems to have corrupted all of our profile photos and they can no longer be viewed in a browser due to "errors". Unfortunately I didn't have bucket versioning enabled so I suspect we're out of luck at getting these back, which is devastating because many of these were uploaded 15+ years ago but that's a separate issue.

Any ideas about what's going on here? Thanks in advance!

Edited April 10 by Mister Java

[Marc Stridgen]

Do you have anything showing up within the support area of your ACP as needing addressing? I would advise on checking this first of all.

[Mister Java]

No, no issues reported in the support section -- when I upgraded it did complain about the database not being utf8mb4 so I ran the converter tool and everything seemed to be fine.

[Marc Stridgen]

Did you change the conf_global.php file as stated, and does it still show this in the support area?

[teraßyte]

It's also possible it's a problem with the image library. Are you using GD or ImageMagick? For example, I've seen people have issues with specific ImageMagick versions.

[Mister Java]

Yes, conf_global.php has been updated and the support section reports no issues. Caches have been cleared too.

teraßyte, I was initially using GD, but I installed and switched to Imagemagick as well just to see if that was the case, with similar results.

The weird thing is that other uploads work -- we can upload image attachments and profile cover photos too. it's just profile photos that are having an issue.

[Marc Stridgen]

Check your storage methods to see if those are being stored in the same location as other uploads

[Mister Java]

Indeed, everything is using my configured Amazon S3 bucket, and I only have a single S3 configuration set up.

[Marc Stridgen]

Please provide the image you are trying to upload so we can take a look.

[Mister Java]

I've tried uploading a handful of images with the same result, but here are a few.

[Marc Stridgen]

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

 

[jair101]

@Mister Java, did you manage to resolve this?

I think I am hitting the similar issue, but it is with a 3rd party app. I believe it is caused by my server environment, but I am unable to identify exactly which component is responsible. A bit more details:

- The app is a video storage app that allows to pull screenshots for the videos either through Youtube API or through upload. 

- Everything works fine with the upload method, where it fails is the API method. 

- The app passes the correct screenshot url, it is fairly simple, the URL looks like this: 
 

https://img.youtube.com/vi/YEXr3c_gKk0/hqdefault.jpg

- When I dump the response from the app I see that the first few bytes of the file are like:
 

????��JFIF����������??�?������
��
������(�����1#%�(:3=<9387@H\N@DWE78PmQW_bghg>Mqypdx\eg

when I open the file with a text editor on my desktop it is:

 

This leads me to believe that everything is fine with obtaining the file, where it fails is when reading it. In particular, the first 4 bytes are needed to identify filetype, they are ???? for the file downloaded by the app and yOya (simplified) when I manually open the file. The latter is also the signature of the JPG file as explained here: https://en.wikipedia.org/wiki/List_of_file_signatures

So right now I am stuck at identifying which server component actually opens and reads this file, I think this is where the source of the problem is. Switching between GD and Imagemagick does not make a difference, moreover when I check the code in Image.php it seems that the file is passed to GD/Imagemagick after the file type is determined, i.e. after already it has been broken. 

I am using PHP 8.3.7, the issue is only with this particular app and only when uploading from URL, all uploads both url and regular work in the core, regular upload also works in the app. 

I know I am breaking many of the "sorry, no support" rules here with the unsupported PHP version and the fact that it happens only on 3rd party app. I am not asking for someone to resolve this for me, I am asking for directions I need to dig on my own. In a nutshell, which server component is responsible to open and read the downloaded file?

Any tips will be appreciated. 

[Jim M]

10 minutes ago, jair101 said:

I know I am breaking many of the "sorry, no support" rules here with the unsupported PHP version and the fact that it happens only on 3rd party app. I am not asking for someone to resolve this for me, I am asking for directions I need to dig on my own. In a nutshell, which server component is responsible to open and read the downloaded file?

I would contact the author. As we don't know how they programmed the application, it is not likely someone here can answer that for you. It could also be it is not compatible with PHP 8.3 whatever they are performing. These are the key reasons why we are unable to provide support to third party applications; we didn't write them so we don't have the responsibility or knowledge about them 🙂 .

[jair101]

It was the PHP version in my case. Downgradet it from 8.3 and everything works. 

 

[Jim M]

Glad to hear you got it resolved.