fix(server): Exclude album assets in shared link payload

[mPyKen]

Description

Removes album asset details when a publicly shared link is opened.

Screenshots at 2500 assets in shared album:
Before

After

Each time when you open a shared link to an album with thousands of assets or navigate to one of these assets afterwards, multiple Megabytes are being sent in a single request (calling /api/shared-links/me?key=...) on each page load, even though this info is never really used. In my case, I have an album with almost 5000 assets which results in 7 MB of payload each time I change the asset I want to look at.

A simple operation of

1. open shared link to an album
2. click on an asset
3. go back to the album view
4. open another asset

results in 4 of these calls, with a rough delay of 500-1000ms each. In contrast, clicking on an asset in the normal album view (i.e. not the shared link) opens the asset instantly.

If we merge this PR as-is, there is one small caveat that the asset count will now exclude the asset count of albums. Let me know how you want this to behave. Some options:

• Ignore asset count of albums (now)
• Include asset count of albums (as before, but calculate that number server-side)
• Instead of displaying asset count of albums, set the description $t('shared_photos_and_videos_count') to sth along the lines "# albums and # individually shared photos & videos."

How Has This Been Tested?

Tested locally and confirmed shared links still work even without the album asset details.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

[alangrainger]

This change sadly causes Immich Publich Proxy to stop working, as it make a non-authenticated request (no API key) using the public share key, to fetch the album assets.

As far as I can see, there is now no way to get the assets contained within a shared album, without requiring an API key.

Originally, the method to fetch assets without API key was suggested by bo0tzz, to remove any API-key related attack surface: alangrainger/immich-public-proxy#3

@mPyKen is there any way in v1.132+ to fetch the list of shared album assets without requiring an API key?

[bo0tzz]

@alangrainger calling the albms endpoint with the share key should work: https://main.preview.internal.immich.cloud/api/albums/eb89401b-4a99-437b-980c-954d775c174f?key=RyRKUG5pe--DEeDiPCRyIwQTXX1M_NwXbGT4X0Nc51rVWjgZhcUtgJdtFkHDw5WSNzQ

[alangrainger]

Thank you @bo0tzz , I've no idea what timezone you're in but you are always right there to point me in the right direction.

IPP now updated and all working. The answer seems obvious in retrospect, sorry to you all for not making that connection! 🫣

[mPyKen]

Sorry for causing a breaking change on IPP. Glad to see it resolved!