starred/photoprism

Fork 0

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

Login Security: Display a static logo page 1st for the base domain before rewriting the URL to /auth/login #1477

New issue

Open

opened 2026-02-20 00:13:17 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 00:13:17 -05:00

Owner

Originally created by @n0hot on GitHub (Jun 26, 2022).

Originally assigned to: @lastzero on GitHub.

Description:
I'm using a free Cloudflare firewall/gateway as a reverse proxy for my public facing Photoprism server that lives in my home. The Photoprism app is publicly accessible. Cloudflare works as a reverse proxy in that I do not have any forwarding rules or any ports open in my home firewall. The cloudflared daemon running on my server establishes the tunnel from my home to Cloudflare.

Solution to Secure the Login Page:
I would like Photoprism to display an initial logo page with a "Login" button (no login fields). Then only after clicking the login button, would the URL be rewritten to the /auth/login page.

The one click to login would provide me the ability to only ALLOW the login page to be displayed from IP addresses that I add to the Cloudflare firewall. I can BLOCK all others from getting to the login page with a regex using /auth/login/. Shared links would bypass the /auth/login and go directly to shared albums as usual.

Thanks for considering this! ...Scott

More info: I have my Photoprism server setup with my own domain. So putting (e.g.) name.net into the URL bar routes thru the Cloudflare gateway to my server as https://name.net Photoprism immediately rewrites the URL to https://name.net/auth/login from the backend. I cannot stop this login page from being displayed to the public. If I refresh the page, it's blocked by my rules at Cloudflare but by then it's too late. I can block all kinds of attacks on a login page with Cloudflare but it would be much better to not display it. A logo page would enable all login attacks to be blocked. Only my IP addresses would be allowed to reach the login page.

Originally created by @n0hot on GitHub (Jun 26, 2022). Originally assigned to: @lastzero on GitHub. **Description:** I'm using a free Cloudflare firewall/gateway as a reverse proxy for my public facing Photoprism server that lives in my home. The Photoprism app is publicly accessible. Cloudflare works as a reverse proxy in that I do not have any forwarding rules or any ports open in my home firewall. The cloudflared daemon running on my server establishes the tunnel **from** my home **to** Cloudflare. **Solution to Secure the Login Page:** I would like Photoprism to display an initial **logo** page with a "Login" button (no login fields). Then **only** after clicking the login button, would the URL be rewritten to the /auth/login page. The one click to login would provide me the ability to only **ALLOW** the login page to be displayed from IP addresses that I add to the Cloudflare firewall. I can **BLOCK** all others from getting to the login page with a regex using /auth/login/. Shared links would bypass the /auth/login and go directly to shared albums as usual. Thanks for considering this! ...Scott **More info:** I have my Photoprism server setup with my own domain. So putting (e.g.) name.net into the URL bar routes thru the Cloudflare gateway to my server as https://name.net Photoprism immediately rewrites the URL to https://name.net/auth/login **from the backend**. I cannot stop this login page from being displayed to the public. If I refresh the page, it's blocked by my rules at Cloudflare but by then it's too late. I can block all kinds of attacks on a login page with Cloudflare but it would be much better to not display it. A logo page would enable all login attacks to be blocked. Only my IP addresses would be allowed to reach the login page.

deekerman added the

idea

security

auth

labels

2026-02-20 00:13:17 -05:00

deekerman commented

2026-02-20 00:13:18 -05:00

Author

Owner

@n0hot commented on GitHub (Jun 27, 2022):

This doesn't seem like a very difficult thing to change. Anyone else worried about SQL injection attacks on the login page?

@n0hot commented on GitHub (Jun 27, 2022): This doesn't seem like a very difficult thing to change. Anyone else worried about SQL injection attacks on the login page?

deekerman commented

2026-02-20 00:13:18 -05:00

Author

Owner

@graciousgrey commented on GitHub (Jun 28, 2022):

Thank you very much for your kind feedback. We will consider this at a later time, as we are extremely busy at the moment.

@graciousgrey commented on GitHub (Jun 28, 2022): Thank you very much for your kind feedback. We will consider this at a later time, as we are extremely busy at the moment.

deekerman commented

2026-02-20 00:13:18 -05:00

Author

Owner

@n0hot commented on GitHub (Jun 28, 2022):

👍🏻

@n0hot commented on GitHub (Jun 28, 2022): 👍🏻

deekerman commented

2026-02-20 00:13:19 -05:00

Author

Owner

@n0hot commented on GitHub (Jun 29, 2022):

Update: After a bit of analysis, I did come up with a solution to create a firewall rule that blocks the POST of the /auth/login page. That effectively mitigates any attempts to login from IPs other than then ones I allow.

@n0hot commented on GitHub (Jun 29, 2022): **Update:** After a bit of analysis, I did come up with a solution to create a firewall rule that blocks the POST of the /auth/login page. That effectively mitigates any attempts to login from IPs other than then ones I allow.

deekerman commented

2026-02-20 00:13:19 -05:00

Author

Owner

@lastzero commented on GitHub (Jun 29, 2022):

Note that the frontend as such is not critical. For security reasons, you should instead block the REST API endpoint POST /api/v1/session. That's where sessions are ultimately created, not in the UI. It only communicates with the API.

@lastzero commented on GitHub (Jun 29, 2022): Note that the frontend as such is not critical. For security reasons, you should instead block the REST API endpoint `POST /api/v1/session`. That's where sessions are ultimately created, not in the UI. It only communicates with the API.

deekerman commented

2026-02-20 00:13:19 -05:00

Author

Owner

@n0hot commented on GitHub (Jun 29, 2022):

Thank you.

@n0hot commented on GitHub (Jun 29, 2022): Thank you.