[Feature] Allow sharing of albums without open ALL of Immich to the Internet

[tjedmunds]

The feature

I would like to be able to share Immich albums with external, non users in a limited manner. I'd rather not open up all of Immich and the API to the Internet for security considerations. The generated shared link prefix looked something like https://mydomain.com/shared/.... so I opened up access by URL path in my firewall to just this prefix hoping to limit what could be accessed by the world but It seems the requested page also requires resources from other URL prefixes. It appears that it is not possible to limit Internet access to JUST the shared stuff through my firewall (opnsense and haproxy). I would have to open up the /api/ path and likely all Immich URL paths.

From a security standpoint it seems to make sense to be able to limit external access to just shared URL's. A common URL path prefix is one useful way of doing that - even if that URL is transparently rewritten on the backend.

I though I would offer the idea for thought as a security enhancement for Immich. Thanks!

Platform

• Server
• Web
• Mobile

[brandonkal]

I'd like to be able to do this as well, but run the firewall in the app. If the request comes from a tailscale (or other personal VPN mesh) interface, allow all access with authentication. If it comes from the internet, only allow shared photo access.

[saua]

I'd love to see such a feature.

IMO the strongest implementation of this would be a dedicated "web-shared" image that speaks to the backend just as the normal one and provides access only to shared images. This way there would be a strong separation and it would be easier to check if all security constraints are in-place.

But even just "make sure shared folders only need resources from a single path prefix" (which what OP asked for, if I understood correctly) would be great!

A middle-point would be to provide a separate port on the web server that serves only shared folders. That way the routing/proxy configuration could be simpler still.

[chrneu]

I also like the idea. When I think about this I could also imagine to publish the album like Adobe does it.

1. User creates album
2. Selects (and customize) theme
3. Publish album (In our case move it to a public folder or upload it via https/ftp to external server)

[spogulis]

Indeed, a great idea. Would be nice to display it as an iframe on my personal website or, better yet, display an iframe of shared albums.

[shotor]

I got this to work by allowing these paths in my public reverse proxy:

# for static css and js - these are ok - you need them to run the app
GET /_app/*
GET /custom.css
GET /favicon-16.png
GET /favicon-144.png

# these I would rather avoid - but fairly harmless
GET /api/server/config      
GET /api/server/features  

# these I would definitely like to avoid
GET /api/assets/<id> id != (device, memory-lane, random, statistics)
GET /api/assets/<id>/thumbnail
GET /api/assets/<id>/video/playback
GET /api/assets/<id>/original

The /api/server/* endpoints don't leak much but they seem unnecessary for the app to function in sharing mode. I'm not too bothered by it.

I'm configuring the reverse proxy to be as restrictive as possible. But I'm having to monitor the immich rest api /api/assets documentation in case a new endpoint gets added so I can block it.

To make this easier to use. The /api/assets endpoint would ideally be proxied through /share and only give the required data. Because if you misconfigure you give entry to DELETE,POST,PUT on your media assets as well as all the other endpoints under /api/assets.

[bo0tzz]

I'm closing this request as https://github.com/alangrainger/immich-public-proxy covers it more than Immich ever could.