starred/photoprism

Fork 0

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

Security: Disable Login page, except for Whitelisted IPs #792

New issue

Open

opened 2026-02-19 23:16:33 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-19 23:16:33 -05:00

Owner

Originally created by @ScuttleSE on GitHub (Feb 14, 2021).

If you, like me, use Photoprism to share albums publically, the ability to disable the login-page would be nice. If nothing else, to dissuade people who stumble upon your website to try to poke holes into it.

I would suggest a setting where an IP or subnet is whitelisted, and all other IPs gets a landing page with no way to login.

Originally created by @ScuttleSE on GitHub (Feb 14, 2021). If you, like me, use Photoprism to share albums publically, the ability to disable the login-page would be nice. If nothing else, to dissuade people who stumble upon your website to try to poke holes into it. I would suggest a setting where an IP or subnet is whitelisted, and all other IPs gets a landing page with no way to login.

deekerman added the

idea

security

labels

2026-02-19 23:16:33 -05:00

deekerman commented

2026-02-19 23:16:33 -05:00

Author

Owner

@mirisbowring commented on GitHub (Feb 28, 2021):

That would not make much sense.
In Europe for example, you don't have static IPs as an User. The ISP is NATing everything and you cannot grant access to this specific Router (Home of a User).

Probably you want to add htaccess in your webserver / reverse proxy to add HTTP BASIC auth or certificate based authorization for the users.

Alternatively you can setup an Wireguard VPN and invite Users to this VPN - the service will listen on the Wireguard Address instead of the public address. It's available for all Devices.

@mirisbowring commented on GitHub (Feb 28, 2021): That would not make much sense. In Europe for example, you don't have static IPs as an User. The ISP is NATing everything and you cannot grant access to this specific Router (Home of a User). Probably you want to add htaccess in your webserver / reverse proxy to add HTTP BASIC auth or certificate based authorization for the users. Alternatively you can setup an Wireguard VPN and invite Users to this VPN - the service will listen on the Wireguard Address instead of the public address. It's available for all Devices.

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@ScuttleSE commented on GitHub (Feb 28, 2021):

As a resident "in Europe" I can say with confidence that I get a static IP.

And I can absolutely put up an additional required authentication on my reverse proxy, or set up a VPN, or set up a system with 2FA, some kind of ADFS-solution and a whole host of other American Ninja Warrior-esque hurdles for friends and family to easily view an album, but that is not the point here.

Having the ability to disable the login-page on an internet-facing server where the goal is to fast and easily share albums, with no need for a login to view those albums would be fairly trivial, and if I then need to jump through a few hurdles to get to the admin-page I am ok with that.

A filter based on the X-Forwarded-For header would probably be very trivial to set up. And if you don't want to filter traffic, don't?

@ScuttleSE commented on GitHub (Feb 28, 2021): As a resident "in Europe" I can say with confidence that I get a static IP. And I can absolutely put up an additional required authentication on my reverse proxy, or set up a VPN, or set up a system with 2FA, some kind of ADFS-solution and a whole host of other American Ninja Warrior-esque hurdles for friends and family to easily view an album, but that is not the point here. Having the ability to disable the login-page on an internet-facing server where the goal is to fast and easily share albums, with no need for a login to view those albums would be fairly trivial, and if I then need to jump through a few hurdles to get to the admin-page I am ok with that. A filter based on the X-Forwarded-For header would probably be very trivial to set up. And if you don't want to filter traffic, don't?

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@mirisbowring commented on GitHub (Feb 28, 2021):

And what about whitelisting the desired IP-Addresses in the nginx conf of your reverse proxy?
https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-tcp/

@mirisbowring commented on GitHub (Feb 28, 2021): And what about whitelisting the desired IP-Addresses in the nginx conf of your reverse proxy? https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-tcp/

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@ScuttleSE commented on GitHub (Feb 28, 2021):

That blocks access to the whole site. What I'm talking about is not showing the admin login page except from certain IP-addresses or ranges.

@ScuttleSE commented on GitHub (Feb 28, 2021): That blocks access to the whole site. What I'm talking about is not showing the admin login page except from certain IP-addresses or ranges.

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@mirisbowring commented on GitHub (Feb 28, 2021):

Ah, now I understand what you want...

That sounds legit.

@mirisbowring commented on GitHub (Feb 28, 2021): Ah, now I understand what you want... That sounds legit.

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@psa commented on GitHub (May 31, 2021):

As a workaround, you could block access to /login in your nginx.conf.

This should do it:

location /login {
  permit x.x.x.x/32;
  deny all;
}

@psa commented on GitHub (May 31, 2021): As a workaround, you could block access to `/login` in your nginx.conf. This should do it: ``` location /login { permit x.x.x.x/32; deny all; } ```

deekerman commented

2026-02-19 23:16:34 -05:00

Author

Owner

@lastzero commented on GitHub (May 31, 2021):

Note that brute force attacks are not possible in practice as each login attempt takes more time.

@lastzero commented on GitHub (May 31, 2021): Note that brute force attacks are not possible in practice as each login attempt takes more time.

deekerman commented

2026-02-19 23:16:35 -05:00

Author

Owner

@LeehamElectronics commented on GitHub (Jul 9, 2022):

As a workaround, you could block access to /login in your nginx.conf.

This should do it:
location /login {
  permit x.x.x.x/32;
  deny all;
}

sadly this can be easily bypassed as PhotoPrism does a server-side redirect to the auth login page when an invalid URL is entered which bypasses NGINX locations.

@LeehamElectronics commented on GitHub (Jul 9, 2022): > As a workaround, you could block access to `/login` in your nginx.conf. > > This should do it: > > ``` > location /login { > permit x.x.x.x/32; > deny all; > } > ``` sadly this can be easily bypassed as PhotoPrism does a server-side redirect to the auth login page when an invalid URL is entered which bypasses NGINX locations.

deekerman commented

2026-02-19 23:16:35 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 2, 2023):

@LeehamElectronics @ScuttleSE This requires some more thought before we might be able to implement it. In general, it would be possible to hide the login page in the navigation and/or disable the login redirect, however the following questions/concerns remain:

What else to show? It would be easier to implement this if we first had a public image wall or other configurable public landing page.
If you disable the redirect and hide the login in the navigation, the Create Session API endpoint won't be disabled, so logging in would technically still be possible e.g. using a REST API client or smartphone app.
Using the guest role, it is (already partially) possible to share albums with external users who have a username and password, but otherwise minimal privileges. Disabling all external logins would break that as well? Is this intended?

@lastzero commented on GitHub (Nov 2, 2023): @LeehamElectronics @ScuttleSE This requires some more thought before we might be able to implement it. In general, it would be possible to hide the login page in the navigation and/or disable the login redirect, however the following questions/concerns remain: - [ ] What else to show? It would be easier to implement this if we first had a [public image wall](https://github.com/photoprism/photoprism/issues/669) or other configurable public landing page. - [ ] If you disable the redirect and hide the login in the navigation, the Create Session API endpoint won't be disabled, so logging in would technically still be possible e.g. using a REST API client or smartphone app. - [ ] Using the guest role, it is (already partially) possible to share albums with external users who have a username and password, but otherwise minimal privileges. Disabling all external logins would break that as well? Is this intended?