Improve thumbnail reading performance with more direct access

[CarlSchwan]

Current state

When loading a thumbnail, we do:

• Authentication DB requests
• File system setup DB requests
• Check if the user can read the file
• Load the thumbnail from the appdata or generate the thumbnail and store it in the appdata
• Serve the thumbnail

Idea how to fix it

The general idea is that we communicate a secret token with the clients when they fetch the list of files in a folder. This secret token is unique for each file and only valid for 5 min. When requesting a thumbnail, we need to pass this token to the request and then with it we can skip the authorization and authentication, as it was already done during the file listing.

Technical explanation

Add a new dav property that contains for each image a thumbnail_access_token. The thumbnail_access_token is generated with the following expression: hash(fileId + rounded_time + server_secret) where rounded_time is the intval(current_timestamp / 60 / 5) so that validity of the token is only 5 minutes and secret_server is secret from the config.php (an unique identifier for each instance). For S3, we can use directly pre-signed urls.

When requesting a thumbnail, the clients and the webui would need to provide the thumbnail_access_token that they previously got from the dav request. If the token is valid, we can skip the authentification and the full file system setup call and only do the appdata setup. If it's not valid or for legacy reasons are not set, we do the authentification and the file system setup.

For the web UI, the HTTP header can be set using a web worker. For the mobile and desktop client, it shouldn't be an issue to add an additional header to the requests (I hope)

Advantages

• Performance: A lot less of DB requests are needed. Optimally none are actually needed as the fileid is already provided by the requests and this allows to find the path in the local storage and s3 storage. But I guess it will be a bit complicated to fight against the framework to not fetch that app config
• Backward compatibility: it's not a new API, just an optional new parameter. It also means we can add support progressively to the apps and clients
• Caching friendly: since the token is not part of the URL, the cache won't get invalidated for every request
• Security: The token is only valid for 5 minutes and after that, a user will need the new token to fetch the thumbnail or be authorized by the server. Apps like access_control will send an invalid token, if the user doesn't have access to the dav requests. The only way for unauthorized users to access the thumbnail would be to get the secret token from the server or that an authorized user share the thumbnail_access_token quickly enough (5 min lifetime) but in that case it's easier to just share the file directly.

Disavantages

• This will need some adaptions in every client and app that use thumbnails. Even if it can be done progressively
• ???

[Kuphi]

Maybe encrypted thumbnails can be considered as well: #1967
Thank you!

[juliusknorr]

Makes sense 👍

A few additional thoughts:

• Taking the etag of the file into the hash might avoid the rather low risk that you can get a thumbnail for a file that was updated after as users access has been revoked
• files_accesscontrol might still list the file in the PROPFIND even though access is being blocked, just something to double check that the token is only issued when read permissions are actually there

[T-bond]

I think the token is valid for 5 min maximum, and most of the time less than 5 min.

For example:
Let the current timestamp be 299 in seconds when the token generated, then the rounded time is 0.
Next second (300) the rounded time is 1, so our token was valid for only 1 seconds this this case.

But I like the idea, as loading the previews are very slow for me on web and on mobile too.

[PVince81]

This will need some adaptions in every client and app that use thumbnails. Even if it can be done progressively

would be good to also get feedback from @tobiasKaminsky here then

[PVince81]

clients to adjust eventually (raise tickets):

• viewer app
• photos app
• Android files app
• iOS files app
• Desktop (Windows with VFS)

[tobiasKaminsky]

I see some troubles.

Current state on e.g. Android:

• open a folder with 500 images
• propfind -> all items are stored in db
• quit app and navigate back to said folder
• etag is checked -> same -> no new refresh
• scroll through 500 images -> as soon as an image is visible -> request thumbnail

With new approach this means:

• always update all files in db -> heavy load on server and client for maybe no reason (if e.g. all thumbnails are already fetched)
• scroll through list may not take more than 5min, otherwise we do not benefit from it