Make list of permanently saved preview thumbnails configurable

[butonic]

Depending on the installed apps preview thumbnails in various sizes are needed. Files needs 36x36, Pictures uses 200x200, Mobile and Tablets also need various sizes.

The current Preview thumbnail generation is quite flexible as you can specify the dimensons you want for the thumbnail. It will be scaled on the fly, which might take too long when the image is 10MB and no thumbnail is available.

The problem with caching ALL generated thumbnails is that it allows a malicious user to fill the disk by generating thumbs in 1000x1000, 1000x999, 1000x998 ... or even 100000x100000 when scaling up.

The current Implementation tries to prevent that by using the next bigger thumbnail to generate a thumbnail. If no Thumbnail exists it will use the original and save the thumbnail in the requested size. That has several drawbacks:

1. if the first requested thumbnail is 1000x1000 no smaller thumbnails will be generated for that image.
2. it still allows filling the disk by requesting 1000x1000, 1000x1001, 1000x1002 ...

I propose adding an optional configuration key to the config file like this:

'permanentPreviewSizes' => array(
    array('x' => 36, 'y' => 36),
    array('x' => 200, 'y' => 200),
    //TODO add mobile sizes
    array('x' => 1000, 'y' => 1000),
),

In addition the API should allow apps to add permanent thumbnail sizes. The Pictures app eg, could then use OCP\Config::addPermanentPreviewSize(200,200); Files could use OCP\Config::addPermanentPreviewSize(36,36); These calls would only add entries to the config array.

This would allow the next ™️ Photo editing app to add new custom thumbnail sizes.

The code generating the thumbnails could then check if the requested size matches a configured permanent size and cache the thumbnail if it does not exist, yet.

@georgehrke @DeepDiver1975 @icewind1991 what dou you think?

[georgehrke]

makes sense,
one point about:

The problem with caching ALL generated thumbnails is that it allows a malicious user to fill the disk by generating thumbs in 1000x1000, 1000x999, 1000x998 ... or even 100000x100000 when scaling up.

We could furthermore remove the explicit exposure of width and height and replace it with smth like type=filelist which then maps to 32x32

e.g.
core/ajax/preview.png?file...&type=filelist instead of core/ajax/preview.png?file...&x=32&y=32

Apps could either register their own types or create their own preview.png

[icewind1991]

We could furthermore remove the explicit exposure of width and height and replace it with smth like type=filelist which then maps to 32x32

The explicit width and height are used on high dpi screens to get the correct resolution previews

[RobinMcCorkell]

Closing due to inactivity. If a better implementation is realized, please open a PR.

[oparoz]

This is how MediaFire is doing it:
http://www.mediafire.com/developers/multimedia_api/images/

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.