Does anyone know if it’s possible to achieve this? Possibly with an external service that syncs the two?

Basically, the last feature immich can’t do that google does is to share albums. Sometimes my family wants to have albums after events, and my ones live in a silo.

  • AzuraTheSpellkissed@lemmy.blahaj.zoneEnglish
    71·
    2 days ago

    Using a reverse proxy / ingress, you can configure only share links to be publicly available, while keeping the rest of immich exclusive to your private-network. Optionally combine with something like Cloudflare Tunnel if you’re worried about leaking your server’s IP.

    • Pika@sh.itjust.worksEnglish
      5·
      2 days ago

      this right here. If you have immich setup behind a reverse proxy, just route any requests that use the /share/ and /s/ (the custom link version) on the proxy manager to route to the immich instance, and have it 403 on anything else when the request is not via the vpn

      Just be aware that immich uses links like share-* as well so be sure to have that trailing / to make it so only shared links and albums can be.

      edit: Actually looking into this route further, it looks like immich as a whole needs more than just the /share/ and the /s/ endpoints exposed to function correctly. I will update this in a little when i figured out more on what is actually needed

      update: So it seems immich will not support this style setup without quite a bit of hands on. You need to give at minimum /share/, /s/, /_app/ and /api/ in order to actually go this route. and at that point since you’ve given /api/ you’ve essentially publicly opened the instance anyway. While you can go through and individually do each endpoint. It requires access to /api/albums /api/assets and a few other endpoints, these endpoints do seem to need auth or some form of verification tho

      for anyone wanting to still go through with it. You can reverse proxy it by allowing the endpoints

      • _app/ a bunch of immich internal files for serving content
      • api/
        • server/
          • config: shows basic infomation about the server
          • media-types: shows what media types the server supports
          • features: discloses what features the server supports
        • shared-links/me: 401, 403’s or shows what links the user account can sign into
        • albums/: 403’s on any album endpoint that doesn’t also include the album’s public slug in the URL
        • timeline/
          • buckets: displays timeline buckets. 401 or 403’s on no auth
          • bucket/: displays timeline info on the requested resource. 401 or 403’s on info unless info is provided about what its trying to access
        • assets/: 401 or 403’s on any request that doesn’t contain a public slug in the url

      The nginx location regex I used for my testing(although not very read friendly) was

      location ~ /(api/(server/(config|media-types|features)|shared-links/me|albums/|timeline/(bucket|buckets)|assets/)|(share|s)|_app/){
  proxy_pass *immich instance*;
}

      note: this was found just by basic testing using NPM on my environment, I may have missed some more specific calls especially regarding videos as I don’t really do any video photography to allow for testing.

      Additional note: You may end up confusing your users with the UI though, as since lets you click on the immich banner to get to login, but everything would be blocked. You may just want to use the immich public project that was linked later in this discussion…