Attachment file size sometimes ignored?

[snoopy5]

Hi,

XF 2.2.12

I have set in ACP/attachments the maximum file size to 20MB and pixel to 1600.

Some users are able to upload successfully large jpegs of i.e. 19MB. So far so good. But I (as admin) have problems to upload images larger than 5MB and now also a PDF of 7.6 MB.

My webhoster does allow up to 200MB uploads.

What could be the reason for this on the XF side?

 

[AndyB]

Add this to your config.php file:

$config['maxImageResizePixelCount'] = 1000000000;

 

[snoopy5]

Add this to your config.php file:

$config['maxImageResizePixelCount'] = 1000000000;

This worked! Thank you so much!

If I do upgrade the software in the future, will this change in config file stay or do I have to add it again after each upgrade?

 

[Kirby]

$config['maxImageResizePixelCount'] = 1000000000;

There are no 1000 MP consumer cameras (that I am aware of), so this is IMHO (currently) a dangerously high value - I would therefore strongly recommend not to use a such high value as it could easily open a DoS attack vector.

 

[snoopy5]

There are no 1000 MP consumer cameras (that I am aware of), so this is IMHO (currently) a dangerously high value - I would therefore strongly recommend not to use a such high value as it could easily open a DoS attack vector.

Which value would you recommend then or is there another way to solve this problem?

For me it looks like a bug, If I have to add a code in the config file to make sure that the ACP settings work properly.

 

[Kirby]

Which value would you recommend then or is there another way to solve this problem?

Depends on your audience and your server resources - if you expect your users to upload 1000 MP images and you can afford to spend ~ 4 GB RAM for processing a single image the above setting is fine; if not I'd lower the value to smth. reasonable (IMHO 50 MP should work fine in most though not all cases).

For me it looks like a bug, If I have to add a code in the config file to make sure that the ACP settings work properly.

It's not a bug, it's working as designed.

To protect you from overloading your server XenForo will not resize images that are larger than the defined maximum pixel count:

To resize an image (with GD) it has to be fully decoded into RAM - a 1000 MP image requires roughly
1.000.000.000 pixels * 4 bytes per pixel = 4.000.000.000 bytes, eg. roughly 4 GB of RAM to resize it.

This is a lot (especially keeping in mind that a usual XenForo page with OpCache will require < 10 MB of RAM to generate output) and is usually more than most installations can (or are willing) to afford for processing a single image.

 

[snoopy5]

To resize an image (with GD)

ok. How about ImageMagick? Is that better in this case than GD?

 

[Kirby]

Depends, IM can be slow on large images and require a lot of RAM.

It also is somewhat famous for security issues like

ImageTragick

imagetragick.com

PSA: ImageMagick information disclosure vulnerability CVE-2022-44268

ImageMagick just released a patch for a serious information disclosure vulnerability. I haven't tested whether this affects XenForo, but it probably does. You should disable ImageMagick and use GD instead, if possible; ImageMagick is prone to serious vulnerabilities. If that isn't an option...

xenforo.com

If you want to process really large images with low memory footprint you'd probably need VIPS

Lack of interest - Add support for libvips

Most likely not going to happen due to "Lack of Interest", but anyway: It would be nice if XenForo could support libvips besides well-known GD and ImageMagick

xenforo.com

 

[Suzanne O]

That's too small mate.