Hidden settings still accessible through URL route #394

New issue

Closed

opened 2026-02-19 23:08:07 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-19 23:08:07 -05:00

Owner

Originally created by @svengreb on GitHub (Aug 18, 2020).

Originally assigned to: @lastzero on GitHub.

Apart from the actual topic of this issue I'd like to thank all creators and maintainers of this fantastic project. I've searched some years ago for a well thought and non-cluttered self-host solution for my image and photo libraries, but unfortunately I didn't find anything at the time that matched my needs. Maybe I also stumbled over PhotoPrism, but it was in a too early development state.
The development process of PhotoPrism reflects my personal workflow and is well structured, the documentation is extensive including complete user & developer guides and the communication of project goal against community requests is handled with care. And it is written in my most favorite programming language of all time 😜 I will definitely try to contribute when I have a little more time again.

I've set PhotoPrism up on my server with Traefik as reverse proxy and Authelia as authenticator (patiently waiting with anticipation for #98) so I can host it for my family and friends. It works great and smoothly imported ~100GB in an astonishingly quick time, without any errors and a perfectly indexed gallery.

Last thing I must note before going into the actual issue topic: I feel a little flattered that my Nord project is listed as design inspiration for the web UI, it's nice to see that it is used in so many different projects and areas.

➜ Start to read here to skip the off-topic content

While setting up my PhotoPrism instance, I came across the PHOTOPRISM_SETTINGS_HIDDEN environment variable that allows to hide the “Settings“ sidebar entry that also sets settings into read-only. This is a simple way to hide UI elements that are not relevant for “normal“ users while there is no explicit user role management available, but a user that knows about the /settings route can also simply access the settings again. Even though the settings are read-only, I guess this is not intended and the route should not be served at all. If I'm wrong with my assumption this issue can be closed immediately because it then works as designed.

Originally created by @svengreb on GitHub (Aug 18, 2020). Originally assigned to: @lastzero on GitHub. Apart from the actual topic of this issue I'd like to thank all creators and maintainers of this fantastic project. I've searched some years ago for a well thought and non-cluttered self-host solution for my image and photo libraries, but unfortunately I didn't find anything at the time that matched my needs. Maybe I also stumbled over PhotoPrism, but it was in a too early development state. The development process of PhotoPrism reflects my personal workflow and is well structured, the documentation is extensive including complete user & developer guides and the communication of project goal against community requests is handled with care. And it is written in my most favorite programming language of all time 😜 I will definitely try to contribute when I have a little more time again. I've set PhotoPrism up on my server with [Traefik][] as reverse proxy and [Authelia][] as authenticator (patiently waiting with anticipation for #98) so I can host it for my family and friends. It works great and smoothly imported ~100GB in an astonishingly quick time, without any errors and a perfectly indexed gallery. Last thing I must note before going into the actual issue topic: I feel a little flattered that [my _Nord_ project is listed as design inspiration for the web UI][c], it's nice to see that it is used in so many different projects and areas. ➜ **Start to read here to skip the off-topic content** While setting up my PhotoPrism instance, I came across the `PHOTOPRISM_SETTINGS_HIDDEN` environment variable that allows to hide the “Settings“ sidebar entry that also sets settings into read-only. This is a simple way to hide UI elements that are not relevant for “normal“ users while there is no explicit user role management available, but a user that knows about the `/settings` route can also simply access the settings again. Even though the settings are read-only, I guess this is not intended and the route should not be served at all. If I'm wrong with my assumption this issue can be closed immediately because it then works as designed. [authelia]: https://www.authelia.com [c]: https://docs.photoprism.org/developer-guide/frontend/design/#colors [traefik]: https://containo.us/traefik

deekerman

2026-02-19 23:08:07 -05:00

closed this issue
added the
enhancement

released
labels

deekerman commented

2026-02-19 23:08:08 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 18, 2020):

Taking a look at this asap, easy to fix if needed. In general, certain settings must be public like language and theme. Feature flags probably don't hurt as well. Paths, API keys etc should be hidden.

@lastzero commented on GitHub (Aug 18, 2020): Taking a look at this asap, easy to fix if needed. In general, certain settings must be public like language and theme. Feature flags probably don't hurt as well. Paths, API keys etc should be hidden.

deekerman commented

2026-02-19 23:08:08 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 19, 2020):

We didn't disable the route so that the UI was easier to debug (without looking at JSON data). Since PhotoPrism is about to get stable, it was a good idea to disable the route. Going to get merged to master soon.

Appreciate your kind feedback! We've been working on this for more than 2 1/2 years, so glad people notice how much time & energy was invested :)

@lastzero commented on GitHub (Aug 19, 2020): We didn't disable the route so that the UI was easier to debug (without looking at JSON data). Since PhotoPrism is about to get stable, it was a good idea to disable the route. Going to get merged to master soon. Appreciate your kind feedback! We've been working on this for more than 2 1/2 years, so glad people notice how much time & energy was invested :)

deekerman commented

2026-02-19 23:08:08 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 19, 2020):

PS: Authelia looks like something we can also use for our backend infrastructure. Simple forward auth should be easy to add to PhotoPrism, maybe similar to https://docs.traefik.io/middlewares/forwardauth/?

More complex permission checking - with different user roles and ACLs - is something we try to avoid for now. First, to reduce code complexity and get more other features implemented instead. Second, to offer better performance compared to Enterprise asset management systems that have to implement all of this by default.

@lastzero commented on GitHub (Aug 19, 2020): PS: Authelia looks like something we can also use for our backend infrastructure. Simple forward auth should be easy to add to PhotoPrism, maybe similar to https://docs.traefik.io/middlewares/forwardauth/? More complex permission checking - with different user roles and ACLs - is something we try to avoid for now. First, to reduce code complexity and get more other features implemented instead. Second, to offer better performance compared to Enterprise asset management systems that have to implement all of this by default.

deekerman referenced this issue

2026-02-20 00:09:12 -05:00

Index: More accurate and resilient handling of related files and photo stacks #1259