Add option to hide login, password reset, etc. for "Restrict global login to allowed IP range" [#3591471]

Problem/Motivation

Thank you very much for this module!

While role-based options of course need to allow accessing the login page, the global "Restrict global login to allowed IP range" option could work well without exposing the login form at all.

Login, Register and Passwort reset could, if enabled, then be hidden behind a 403 or 404 totally for IPs not matching these, reducing server load and other potential attacks on the login form entirely.

Steps to reproduce

Use the global IP restriction to only allow login for certain IPs
Still see the login form from other IPs which has negative side-effects

Proposed resolution

https://www.drupal.org/project/restrict_login_ip implements this similarly, but also see #3591469: Allow showing 404 and protecting other login-related pages for further options.
I think it would make sense to have a setting controlling this, because existing installations might still want the current behaviour and there may be cases where the existing behaviour is also desired. By default, the new 404 / 403 behaviour should be enabled on fresh installations.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Comment #1

22 May 2026 at 07:12

anybody created an issue. See original summary.

Comment #2

darvanen

he/him

English

Sydney, Australia

commented 2 August 2026 at 02:33

Status:

Active

» Closed (won't fix)

Thanks for the suggestion. I can see the appeal, but I don't think this module is the right place for it.

restrict_by_ip is deliberately a login-time firewall: it checks the IP when someone authenticates, and never touches the anonymous login page itself. That keeps /user/login fully cacheable, both in the internal page cache and at the edge.

Hiding the page per IP breaks that. Either the response varies by client IP, which makes those pages effectively uncacheable, or, behind a CDN that caches anonymous HTML, the cached page gets served to blocked IPs anyway and the feature silently fails unless the site excludes those paths at the edge. That is a per-site hosting decision this module can't make, and we would have to deal with the resulting bug reports.

It's telling that restrict_login_ip solves this by setting no_cache on the login routes: the page becomes uncacheable for everyone the moment the module is enabled. That might be a reasonable trade-off for a module whose whole purpose is hiding the page, but I don't want to make that part of this module, even as an option.

Restrict Login Page by IP does work alongside restrict_by_ip (I've tested the combination): this module decides who can authenticate, that one hides the doors. Its stable release covers the login form and the REST login endpoint; registration, password reset and a 404 option are in the 1.1 alpha. I'll add a note about it to the project page so it's easier to find.