Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Preview Image When Sharing Album Links #16525

Open
3 of 4 tasks
twirley opened this issue Mar 3, 2025 · 8 comments
Open
3 of 4 tasks

Missing Preview Image When Sharing Album Links #16525

twirley opened this issue Mar 3, 2025 · 8 comments
Labels

Comments

@twirley
Copy link

twirley commented Mar 3, 2025

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

Issue Description

When sharing an album link from Immich via messaging apps, the link doesn't include a preview image of the album cover. This makes the shared links less engaging and recognizable compared to other photo sharing services.

Expected Behavior

When sharing an album link, messaging apps should display a preview image (typically the album cover) alongside the link, similar to how Google Photos links appear.

Actual Behavior

Immich shared links appear as plain text URLs without any preview image.

Platform

  • Web
  • Mobile

Additional Context

I've attached a comparison screenshot showing how Google Photos links (top) include preview images while Immich links (bottom) do not.
Image

The OS that Immich Server is running on

Debian

Version of Immich Server

v1.128.0

Version of Immich Mobile App

v1.128.0 build.186

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#
name: immich
services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false
  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:905c4ee67b8e0aa955331960d2aa745781e6bd89afc44a8584bfd13bc890f0ae
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always
  database:
    container_name: immich_postgres
    image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: >-
        pg_isready --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" || exit 1;
        Chksum="$$(psql --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" --tuples-only --no-align
        --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')";
        echo "checksum failure count is $$Chksum";
        [ "$$Chksum" = '0' ] || exit 1
      interval: 5m
      start_interval: 30s
      start_period: 5m
    command: >-
      postgres
      -c shared_preload_libraries=vectors.so
      -c 'search_path="$$user", public, vectors'
      -c logging_collector=on
      -c max_wal_size=2GB
      -c shared_buffers=512MB
      -c wal_compression=on
    restart: always
volumes:
  model-cache:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=./library
# The location where your database files are stored
DB_DATA_LOCATION=./postgres

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
# TZ=Etc/UTC

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces

# The values below this line do not need to be changed
###################################################################################

Reproduction steps

  1. Create a shared album in Immich, set the album cover image
  2. Copy the share link
  3. Paste the link in a messaging app (e.g., WhatsApp, Telegram, Signal, etc.)
  4. Observe that no preview image is displayed with the link
  5. Repeat the same steps with Google Photos for comparison, where a preview image is shown

Relevant log output

Additional information

No response

@bo0tzz
Copy link
Member

bo0tzz commented Mar 3, 2025

This happens because the opengraph tag generation at https://github.com/immich-app/immich/blob/main/server/src/services/shared-link.service.ts#L194 doesn't take into account the request HOST, but only uses the externalDomain from the Immich config, meaning if that config is empty the opengraph image link points at localhost:2283.

@bo0tzz
Copy link
Member

bo0tzz commented Mar 3, 2025

Should be a straightforward fix by passing req.hostname down and using that if there's no externalDomain configured.

@redwanulsourav
Copy link

redwanulsourav commented Mar 4, 2025

@bo0tzz Would the following process be a valid way to test locally with two machines in same network?

Machine A: Host immich (Assuming IP: 192.168.1.80)
Machine B: Client

At first get the thumbnail URL by visiting the shared album link (with machine B, localhost:3000 is replaced with 192.168.1.80:3000): inspect the page to find a <meta> tag with property="og: image". content attribute contains the URL for the thumbnail. Then next step is to check if I can access the thumbnail.

If above is the correct process, I have found the that on machine B, the tag contains, <meta property = "og:image", content: <192.168.1.80>:3000/api/assets/<base64id>> that is the hostname is seems to be replaced with the correct address. The issue seems to be with authentication. The thumbnail only loads if the authentication is done first. For a publicly shared album (no password), is authentication needed?

@bo0tzz
Copy link
Member

bo0tzz commented Mar 4, 2025

Authentication happens at the top of the function I linked, based on the shared link key.

@redwanulsourav
Copy link

redwanulsourav commented Mar 6, 2025

The meta tag containing content="og:image" seems to have an URL like that points to 192.168.1.80:3000/api/assets/<id>/thumbnail, which seems to be handled in asset-media.controller.ts and in asset-media.service.ts both require authentication.

As a hack, I created a new route to handle album covers /assets/<id>/album_cover, which successfully returns the image without authentication. With this solution, now I need to change the meta tag to have correct URL, something like /assets/<id>/album_cover, which I thought was handled in, shared-link.service.ts , but I found changing that does not change the meta tag. Also, there is a question of security, as the URL doesn't check for authentication, should I check the permissions dynamically?

@redwanulsourav
Copy link

redwanulsourav commented Mar 6, 2025

Maybe creating a sharable (similar to link for album) link for the asset (when the album is shared) might be a good solution?

@piyush97
Copy link

piyush97 commented Mar 6, 2025

I can take care of this opengraph tag generation issue, can you assign it to me?

@bo0tzz
Copy link
Member

bo0tzz commented Mar 6, 2025

I think @redwanulsourav has already been working on this?

I believe there shouldn't be any need for new routes or whatever. The code I linked already handles adding the share key to imagePath.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants