Photoprism: Hidden settings still accessible through URL route

Created on 18 Aug 2020  Â·  3Comments  Â·  Source: photoprism/photoprism

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.

done todo

Most helpful comment

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.

All 3 comments

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.

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 :)

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nguyenxndaidev picture nguyenxndaidev  Â·  5Comments

ToeiRei picture ToeiRei  Â·  4Comments

uLUViL3gCs picture uLUViL3gCs  Â·  3Comments

bugs181 picture bugs181  Â·  3Comments

brokencode64 picture brokencode64  Â·  5Comments