Force login to make the site private - Gozer
| 开发者 |
fernandot
ayudawp |
|---|---|
| 更新时间 | 2026年7月3日 14:49 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- One-click activation - Enable force login with a single checkbox
- Admin bar toggle - Quick on/off switch directly from the toolbar
- System exceptions - Keep REST API, WP-Cron, WP-CLI, and AJAX working
- SEO-friendly - Allow search engine bots, sitemaps, and robots.txt
- Verified bots - Optionally confirm crawlers by reverse DNS so nobody can fake being Googlebot
- Custom paths - Define specific pages that should remain public
- Advanced IP whitelist - Supports individual IPs, CIDR notation, and wildcards, with configurable IP detection for sites behind Cloudflare or a reverse proxy
- Temporary bypass tokens - Generate shareable links for temporary access
- User agent rules - Grant access to monitoring services
- Flexible redirects - Choose login page, 403 error, or custom URL
- Lightweight - No bloat, just the features you need
- Individual IPs:
192.168.1.1 - CIDR notation:
192.168.1.0/24or10.0.0.0/8 - Wildcards:
192.168.*or10.*.*.*
- Client reviews of staging sites
- Sharing with contractors or agencies
- Temporary access for support teams
- Preview links for stakeholders
- Private company intranets
- Client staging sites
- Membership communities
- Development and testing environments
- Employee portals
- Educational platforms
安装:
- Upload the
gozerfolder to/wp-content/plugins/ - Activate the plugin through the 'Plugins' menu in WordPress
- Go to Settings > Gozer to configure options
- Enable the "Require login to access the site" checkbox
- Configure exceptions as needed
屏幕截图:
常见问题:
Will this break my site?
The plugin is designed with safe defaults. Critical functionality like REST API, WP-Cron, and AJAX are allowed by default to prevent breaking the block editor or scheduled tasks.
Can search engines still index my site?
Yes, if you enable the "Search engine bots" option. Major search engine bots (Google, Bing, etc.) will be able to access and index your content.
Can someone fake being Googlebot to see my private site?
If "Search engine bots" is enabled (the default), yes: bots are recognized by their user agent, which any visitor can set freely, so a curl request claiming to be Googlebot gets through. If your site must stay private to everyone except real search engines, enable "Verify bots by reverse DNS": Gozer then confirms the claim with a forward-confirmed reverse DNS lookup against the engine's official domains (Google, Bing, Yahoo, Yandex, Baidu, and Apple) and blocks impostors, as well as bots that cannot be verified this way (such as social network preview fetchers). If the site should be completely hermetic, disable the "Search engine bots" exception altogether.
I am behind Cloudflare or a reverse proxy and my allowed IPs stopped working
Since 2.1.0 Gozer reads the visitor IP from the direct connection by default, because trusting proxy headers on sites not behind a proxy allowed anyone to impersonate an allowed IP by forging a header. Behind Cloudflare or a reverse proxy, the direct connection is the proxy itself, so go to Settings > Gozer > "Visitor IP detection" and select the header your infrastructure sets (CF-Connecting-IP for Cloudflare, X-Real-IP or X-Forwarded-For for other proxies). Your IP whitelist will work as before.
How do I allow specific pages to be public?
Go to Settings > Gozer and add paths to the "Allowed paths" field. Enter one path per line, like /contact/ or /about/.
How do I whitelist an entire IP range?
Use CIDR notation (e.g., 192.168.1.0/24 for a /24 subnet) or wildcards (e.g., 192.168.* for all IPs starting with 192.168).
How do bypass tokens work?
Generate a token in Settings > Gozer, then share the generated URL. Anyone with that link can access the site without logging in until the token expires.
Can I use it on a multisite network?
Yes, the plugin works on multisite installations. Each site can have its own configuration.
Why "Gozer"?
Gozer the Gozerian is the supernatural entity from Ghostbusters (1984) who asked "Are you a god?" before denying access to mere mortals. Just like our plugin does with your site visitors.
Why can a logged-in user still not see my site?
If you set a "Minimum access level" higher than the user's role, logged-in users below that level are treated like logged-out visitors and shown a 403 page. This front-end restriction is independent from the WordPress dashboard: a Subscriber can still reach their profile screen but will not see the front-end. Set the access level back to "Any logged-in user" to allow every logged-in user through.
I enabled private mode but old pages still load without logging in
A page cache (a caching plugin, your host, or a CDN) can serve pre-generated HTML without running WordPress, so Gozer never sees those requests. Gozer purges the major caching plugins automatically when you activate the plugin, toggle private mode, or save settings, but if your host or CDN caches HTML you may need to purge it once after enabling Gozer.
更新日志:
- New: "Visitor IP detection" setting. Choose where Gozer reads the visitor IP: direct connection (the new default), Cloudflare's CF-Connecting-IP, X-Real-IP, or X-Forwarded-For. If you use the allowed-IPs exception behind a proxy or CDN, select your header so the whitelist keeps working.
- New: Optional verification of search engine bots. With "Verify bots by reverse DNS" enabled, a visitor claiming to be Googlebot, Bingbot, Slurp, YandexBot, Baiduspider or Applebot must pass forward-confirmed reverse DNS against the engine's official domains (verdict cached per IP). Bots that cannot be verified this way, like social preview fetchers, are blocked while it is on.
- Improved: The "Search engine bots" setting now states plainly that bots are recognized by their user agent, which anyone can forge, so you can decide whether to disable the exception or verify crawlers on sites that must stay hermetic.
- Improved: Recommendations banner synced with the AyudaWP catalog (updated plugin names and descriptions).
- Fix: Security hardening of the allowed-IPs exception. The visitor IP was read from client-controlled proxy headers (CF-Connecting-IP, X-Real-IP, X-Forwarded-For) even on sites not behind a proxy, so a visitor could impersonate an allowed IP by forging a header. The IP now comes from the direct connection unless a proxy header is explicitly selected, and X-Forwarded-For uses the address added by the proxy instead of the client-editable first entry.
- New: Minimum access level. Require a minimum role (Subscriber, Contributor, Author, Editor, or Administrator) for logged-in users to view the front-end. Lower-privileged users are shown a 403 page instead of the content, so an intranet can keep subscribers out while letting editors in. The front-end access level is independent from WordPress dashboard capabilities.
- New: Custom 403 block screen. Set your own title and message (basic HTML allowed) for the 403 mode without editing your theme. A theme 403.php template still takes precedence if present.
- Improved: Page cache hardening. When a visitor is blocked, Gozer now sets DONOTCACHEPAGE and sends no-cache headers on every block path (login redirect, custom URL, and 403) so page caches and CDNs never serve the block response to the wrong visitor. Public exceptions stay fully cacheable, and known page caches are purged automatically when the plugin is activated or deactivated and when private mode or the settings change.
- Improved: The REST API, XML-RPC and AJAX system exceptions now take effect for logged-out visitors instead of being informational. With the site private and the exception off, /wp-json/ stops exposing your content to anonymous requests and XML-RPC is disabled; logged-in users and the IP, user-agent and bypass-token exceptions are always respected.
- Fix: An "Allowed paths" entry of "/" exposed the entire site instead of just the homepage it promises. It now matches the homepage only, on root and subdirectory installs alike.
- Fix: On subdirectory installs, the login redirect built the return URL with the site path doubled (e.g. /site/site/), landing visitors on a 404 after signing in.
- Fix: WordPress' virtual robots.txt was blocked on sites using "plain" permalinks (served as /?robots=1) even with the robots exception enabled. Both the virtual and the physical robots.txt are now recognized.
- Fix: "Allowed paths" rules were ignored on subdirectory installs because the request path includes the subdirectory. Rules now also match with the install base prefixed, so "/contact/" matches "/site/contact/".
- Fix: IP whitelist wildcards now work as documented. A pattern like 192.168. matched no real address before (it expected a single octet); a trailing * now covers the rest of the address, so 192.168. allows the whole 192.168.x.x range.
- Fix: The "Redirect to custom URL" option now works with external URLs. wp_safe_redirect only allowed the site's own host, so an external address silently fell back to wp-admin; the configured host is now allowed. For older changelog entries, please check the changelog.txt file