starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Viewer: Open pictures directly based on the URL in shared albums #1991

New issue

Open

opened 2026-02-20 01:03:58 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 01:03:58 -05:00

Owner

Originally created by @Penknife0915 on GitHub (Dec 31, 2023).

Same-Session Access:

In a shared album (http(s)://domain.name/s/<secret>/<album>), clicking on a photo directs to its expanded view. The URL changes to http(s)://domain.name/library/albums/<another-secret>/<album>#&gid=<n>&pid=<n>.
Attempting to open this /library/albums/... URL in a new tab within the same browser session results in displaying the album's gallery view, not the specific photo.

External Access or Post-Data Clearance:

Accessing the /library/albums/... URL externally or in the same browser after clearing data redirects to the login page (http(s)://domain.name/library/login), instead of showing the photo.

The expectation is that /library/albums/... URLs, being derived from public shared album links, should function as accessible direct links to individual photos, both in the same session and externally. Their current behavior — redirecting to the album view or login page — limits the utility of these links for sharing specific photos.

Originally created by @Penknife0915 on GitHub (Dec 31, 2023). **Same-Session Access:** - In a shared album (`http(s)://domain.name/s/<secret>/<album>`), clicking on a photo directs to its expanded view. The URL changes to `http(s)://domain.name/library/albums/<another-secret>/<album>#&gid=<n>&pid=<n>`. - Attempting to open this `/library/albums/...` URL in a new tab within the same browser session results in displaying the album's gallery view, not the specific photo. **External Access or Post-Data Clearance:** - Accessing the `/library/albums/...` URL externally or in the same browser after clearing data redirects to the login page (`http(s)://domain.name/library/login`), instead of showing the photo. **The expectation is that** `/library/albums/...` URLs, being derived from public shared album links, should function as accessible direct links to individual photos, both in the same session and externally. Their current behavior — redirecting to the album view or login page — limits the utility of these links for sharing specific photos.

deekerman added the

idea

sharing

labels

2026-02-20 01:03:58 -05:00

deekerman commented

2026-02-20 01:03:59 -05:00

Author

Owner

@lastzero commented on GitHub (Dec 31, 2023):

This is not yet implemented, but should be shipped as part of the new viewer:

https://github.com/photoprism/photoprism/issues/1307

Note that our next milestones will be to (1) add more authentication options before (2a) implementing batch editing and (2b) improving facial recognition:

https://github.com/orgs/photoprism/projects/5

@lastzero commented on GitHub (Dec 31, 2023): This is not yet implemented, but should be shipped as part of the new viewer: - https://github.com/photoprism/photoprism/issues/1307 Note that our next milestones will be to (1) add more authentication options before (2a) implementing batch editing and (2b) improving facial recognition: - https://github.com/orgs/photoprism/projects/5

deekerman commented

2026-02-20 01:03:59 -05:00

Author

Owner

@eerison commented on GitHub (May 3, 2024):

I am facing this issue, I'm trying to expose
s/* and library/albums/*, for easy sharing, but I'm getting issues when it's redirecting 🥲.

@Penknife0915 did you find any alternative solution for your case?

@eerison commented on GitHub (May 3, 2024): I am facing this issue, I'm trying to expose `s/*` and `library/albums/*`, for easy sharing, but I'm getting issues when it's redirecting 🥲. @Penknife0915 did you find any alternative solution for your case?

deekerman commented

2026-02-20 01:04:00 -05:00

Author

Owner

@new112211 commented on GitHub (Dec 7, 2024):

I am facing this issue, I'm trying to expose s/* and library/albums/*, for easy sharing, but I'm getting issues when it's redirecting 🥲.
@Penknife0915 did you find any alternative solution for your case?

Facing the same issue, apps on pause until a solution for this is created.

@new112211 commented on GitHub (Dec 7, 2024): > I am facing this issue, I'm trying to expose `s/*` and `library/albums/*`, for easy sharing, but I'm getting issues when it's redirecting 🥲. > @Penknife0915 did you find any alternative solution for your case? Facing the same issue, apps on pause until a solution for this is created.

deekerman commented

2026-02-20 01:04:00 -05:00

Author

Owner

@czarnyxtimon commented on GitHub (Jun 19, 2025):

Hi, I’d like to share a serious privacy issue related to shared links in PhotoPrism.

When a user receives a public share link like:

https://albums.example.com/s/8q97eu5bs5/my-album

they are correctly redirected to:

/library/albums/<album-id>/view

However, once this redirection happens, the user is considered authenticated (probably via a session or cookie), and they can then:

Manually modify the URL and access:
- /library/albums/ – listing all albums
- /library/photos/ – viewing all photos
- etc.

This effectively grants global guest-level access, rather than restricting the session to only the shared album.

We’ve tried mitigating this using reverse proxies (e.g. Nginx + basic auth on exact paths), but once PhotoPrism accepts the /s/... token and sets a session, we lose control. Even blocking /library/ doesn’t help, since the app uses redirection logic internally.

Why this is a problem:

Users assume that a shared album link only exposes that one album – not their entire library.

This is especially risky in family or semi-public sharing scenarios.

Suggested improvements:

A shared /s/... link should create a temporary session limited to that album only
Any manual navigation to other routes (outside of the shared album) should result in a 403 or redirect to login
Alternatively: Provide an option to sandbox shared sessions

Thank you for an amazing project — just want to help make it safer!

@czarnyxtimon commented on GitHub (Jun 19, 2025): Hi, I’d like to share a serious privacy issue related to shared links in PhotoPrism. When a user receives a public share link like: https://albums.example.com/s/8q97eu5bs5/my-album they are correctly redirected to: /library/albums/<album-id>/view However, once this redirection happens, the user is considered authenticated (probably via a session or cookie), and they can then: - Manually modify the URL and access: - `/library/albums/` – listing all albums - `/library/photos/` – viewing all photos - etc. This effectively grants **global guest-level access**, rather than restricting the session to **only the shared album**. We’ve tried mitigating this using reverse proxies (e.g. Nginx + basic auth on exact paths), but once PhotoPrism accepts the `/s/...` token and sets a session, we lose control. Even blocking `/library/` doesn’t help, since the app uses redirection logic internally. ### Why this is a problem: Users assume that a shared album link only exposes **that one album** – not their entire library. This is especially risky in family or semi-public sharing scenarios. ### Suggested improvements: - A shared `/s/...` link should create a temporary session **limited to that album only** - Any manual navigation to other routes (outside of the shared album) should result in a 403 or redirect to login - Alternatively: Provide an option to sandbox shared sessions Thank you for an amazing project — just want to help make it safer!

deekerman commented

2026-02-20 01:04:01 -05:00

Author

Owner

@graciousgrey commented on GitHub (Jun 19, 2025):

@czarnyxtimon Thank you for sharing.

I cannot reproduce this issue.

If I open a share link in an incognito window or in a browser where I am logged in with a user with the role guest. I do see the shared album. If I navigate to /library/albums/ I do only see the shared album. Please note that if you have shared other albums in the past with this guest user or if you use the same secret on multiple share links he will have access to those as well (until the share link is deleted or expires).

Is it possible that you have opened the share link while being logged in with a user that has a role that allows access to all albums such as admin, user or viewer? Or do you run PhotoPrism in public mode?

@graciousgrey commented on GitHub (Jun 19, 2025): @czarnyxtimon Thank you for sharing. I cannot reproduce this issue. If I open a share link in an incognito window or in a browser where I am logged in with a user with the role guest. I do see the shared album. If I navigate to /library/albums/ I do only see the shared album. Please note that if you have shared other albums in the past with this guest user or if you use the same secret on multiple share links he will have access to those as well (until the share link is deleted or expires). Is it possible that you have opened the share link while being logged in with a user that has a role that allows access to all albums such as admin, user or viewer? Or do you run PhotoPrism in public mode?

deekerman commented

2026-02-20 01:04:01 -05:00

Author

Owner

@czarnyxtimon commented on GitHub (Jun 19, 2025):

I’d like to provide a clear reproduction scenario:

📌 Test setup:

Two separate albums: Album A and Album B
Each album is shared using its own unique shared link (with different secret tokens)

🧪 Reproduction Steps:

Open a fresh incognito/private browser session.

Paste and visit the shared link to Album A:

https://yourdomain.tld/s/<token-A>/album-a

The album opens as expected — only Album A is visible.
Even if you modify the URL manually (e.g. /albums, /calendar, etc.), PhotoPrism still only displays Album A. ✅
Open a second incognito/private window (not tab!) to avoid sharing browser session data.

Paste and visit the shared link to Album B:

https://yourdomain.tld/s/<token-B>/album-b

Album B opens correctly — again, only Album B is shown.
However, now click on the sidebar menu and go to "Albums" (/library/albums).
❗ You will now see both Album A and Album B, even though:
- You never entered any credentials
- You only opened Album B in this session
- The shared link was supposed to grant access to just one album

⚠️ Expected Behavior:

Each /s/<token>/<slug> link should only authorize access to the specific shared album. Sessions created via these links should be strictly sandboxed — the user should not be able to browse any other content outside the scope of the shared token.

Thank you!

@czarnyxtimon commented on GitHub (Jun 19, 2025): I’d like to provide a clear reproduction scenario: ## 📌 Test setup: - Two separate albums: Album A and Album B - Each album is shared using its own unique shared link (with different secret tokens) ## 🧪 Reproduction Steps: 1. Open a fresh incognito/private browser session. 2. Paste and visit the shared link to **Album A**: ``` https://yourdomain.tld/s/<token-A>/album-a ``` 3. The album opens as expected — only **Album A** is visible. 4. Even if you modify the URL manually (e.g. `/albums`, `/calendar`, etc.), PhotoPrism still only displays Album A. ✅ 5. Open a **second incognito/private window** (not tab!) to avoid sharing browser session data. 6. Paste and visit the shared link to **Album B**: ``` https://yourdomain.tld/s/<token-B>/album-b ``` 7. Album B opens correctly — again, only Album B is shown. 8. However, now click on the sidebar menu and go to **"Albums"** (`/library/albums`). 9. ❗ You will now see **both Album A and Album B**, even though: - You never entered any credentials - You only opened Album B in this session - The shared link was supposed to grant access to **just one album** ## ⚠️ Expected Behavior: Each `/s/<token>/<slug>` link should only authorize access to the specific shared album. Sessions created via these links should be **strictly sandboxed** — the user should not be able to browse any other content outside the scope of the shared token. Thank you!

deekerman commented

2026-02-20 01:04:01 -05:00

Author

Owner

@graciousgrey commented on GitHub (Jun 19, 2025):

@czarnyxtimon Which browser did you use? As far as I am informed at least chrome (other browsers might do as well) does share the session between multiple incognito windows. That's why you see both albums as they have been opened in the same session.

For further questions please open a discussion here as this seems not to be related to this issue. Thank you :)

@graciousgrey commented on GitHub (Jun 19, 2025): @czarnyxtimon Which browser did you use? As far as I am informed at least chrome (other browsers might do as well) does share the session between multiple incognito windows. That's why you see both albums as they have been opened in the same session. For further questions please open a discussion [here](https://github.com/photoprism/photoprism/discussions/categories/q-a) as this seems not to be related to this issue. Thank you :)