Sharing: Incorrect link redirect when installed on a shared domain

[v-bulynkin]

I have a docker container of Photoprism with

PHOTOPRISM_SITE_URL: "http://docker/photo/"

It sits behind Traefik reverse-proxy:

 labels:
      - "traefik.enable=true"
      - "traefik.http.routers.photoprism.rule=PathPrefix(`/photo`)"

In the admin panel everything work correctly, but there is a problem with sharing links - I make a link where all seems good:

However, when I copy the link (http://docker/photo/s/2pk0fpqoyj/test) and try to open it in a browser, the link transforms to https://docker/s/2pk0fpqoyj/ar0uvkm1ei9j9uwc and I get 404 error:

If I manually add the prefix (https://docker/photo/s/2pk0fpqoyj/ar0uvkm1ei9j9uwc), it works.

Why the /photo prefix disappears and how to prevent this behaviour?
The same thing happens after exiting - it goes not to login page http://docker/photo but to the root http://docker

[lastzero]

We'll take a look at this as soon as possible. It worked when I tested it the last time. Meanwhile, please look through GitHub issues as I remember we had similar issues that could be resolved by clearing the browser cache or changing the proxy configuration.

[v-bulynkin]

Thank you for the response, found it: #425 (comment)

However, I can't figure out how to solve this in Traefik. I read that "Traefik handle websocket, and you don't need any specific configuration for this", and also found a middleware, which didn't help.

[lastzero]

Traefik should automatically handle Websockets, that's one of the advantages. You shouldn't need a middleware, but also I'm not sure if using PathPrefix() has an impact here.

Installing PhotoPrism (and every other app) on a shared domain certainly complicates things, negatively impacts performance, and may also reduce security (see same origin policy). We've implemented this because people were asking for it, not because we recommend it or think it's easy to set up.

https://docs.photoprism.org/getting-started/faq/#can-i-install-photoprism-in-a-sub-directory-on-a-shared-domain

[v-bulynkin]

Yes, I know and completely agree, but I don't have an option of using subdomains because I have been using free DynDNS for more than 5 years where I have only one domain name.
However, if we use containers, doesn't it the same as if we used all services in one web server? Containers are isolated from each other, isn't it better?

[lastzero]

We're using DigitalOcean as dynamic DNS (free) and have a domain with wildcard cert from let's encrypt (also free). Only the domain costs a few bucks a year. Before you invest too much time in the shared domain config, that may be an option. Took 1 hour to set up.

Containers don't help with isolating browser sessions and client-side JavaScript. They also don't remove the browser resource limit per domain.

[lastzero]

We mainly use containers because working with media files requires a ton of dependencies. Helping every user to set up every single tool properly and do remote debugging in case there are problems would kill the project in no time! 👯

[v-bulynkin]

Thanks for the explanation! I will consider this option.
Nevertheless, if the possibility of working under shared domain URL is presented, it would be nice to have a complete working scheme...

[lastzero]

We're super busy right now but doing our best to help! Not sure when we have time for testing as I have to focus on multi user support this and next week. If it's a bug on our side, we'll fix it 👍