Restricted Site Access

Most commonly, Restricted Site Access is not compatible with some page caching solutions. While the plugin hooks in as early as it can to check visitor permissions, its important to understand that some page caching plugins generate static output that prevents plugins like Restricted Site Access from ever checking individual visitors.

How do I allow access to specific pages or parts of my site?

For instance, to unblock an RSS feed, place the following PHP code in the theme’s functions.php file or in a simple plug-in:

Visitors that are not logged in or allowed by IP address will not be able to browse your site (though be cautious of page caching plugin incompatibilities, mentioned above). Restricted Site Access does not block access to your “real” files, so direct links to files in your media and uploads folder (for instance) are not blocked. It is also important to remember that IP addresses can be spoofed. Because Restricted Site Access runs as a plug-in, it is subject to any other vulnerabilities present on your site.

In 7.3.2, two new filters were added that can be utilized to help prevent IP spoofing attacks. The first filter allows you to set up a list of approved proxy IP addresses and the second allows you to set up a list of approved HTTP headers. For any sites that were using Restricted Site Access prior to version 7.5.0, a handful of HTTP headers are trusted by default. To change this, utilize the rsa_trusted_headers filter to modify the HTTP headers you want to trust. If your site is not running behind a proxy, we recommend doing the following:

This will then only use the REMOTE_ADDR HTTP header to determine the IP address of the visitor. This header can’t be spoofed, so this will increase security. Note that this is now the default for all new installs since version 7.5.0.

add_filter( 'rsa_trusted_proxies', 'my_rsa_trusted_proxies' ); function my_rsa_trusted_proxies( $trusted_proxies = array() ) { // Set one or more trusted proxy IP addresses. $proxy_ips = array( '10.0.0.0/24', '10.0.0.0/32', ); $trusted_proxies = array_merge( $trusted_proxies, $proxy_ips ); return array_unique( $trusted_proxies ); }

add_filter( 'rsa_trusted_headers', 'my_rsa_trusted_headers' ); function my_rsa_trusted_headers( $trusted_headers = array() ) { // Set one or more trusted HTTP headers. $headers = array( 'HTTP_X_FORWARDED', 'HTTP_FORWARDED', ); return $headers; }

I received a warning about page caching. What does it mean?

Page caching plugins often hook into WordPress to quickly serve the last cached output of a page before we can check to see if a visitor’s access should be restricted. Not all page caching plugins behave the same way, but several solutions – including external solutions we might not detect – can ignore the no-caching headers set by WordPress and show cached content to unauthorized users.

In 6.2.0, the behavior in a multisite install changed from allowing any logged-in user to see a site to checking their role for that specific site. This is a safer default given the varying ways multisite is used; however, if you would prefer to rely on the previous behavior rather than explicitly adding users to each site, place the following PHP code in the theme’s functions.php file or in a simple plug-in:

As of version 7.0.0, CLI integration has been added. To see the available commands, type the following in your WordPress directory:

In 7.0.0, the capacity to define a pipe delimited array of whitelisted IP addresses via constant was introduced.

define( 'RSA_IP_WHITELIST', '192.0.0.1|192.0.0.10' );

The following are valid statements:

Restricted_Site_Access::set_ips( array( '192.168.0.1', '192.168.0.2', '192.168.0.3' ) ); Restricted_Site_Access::set_ips( array( 'labelfoo' => '192.168.0.1', 'labelbar' => 192.168.0.2', 'labelbaz' => 192.168.0.3' ) );

Restricted_Site_Access::append_ips( array( '192.168.1.5' => 'five', '192.168.1.6' => 'six' ) );

Restricted_Site_Access::remove_ips( array( '192.168.1.2','192.168.1.5','192.168.1.6', ) ); Is there a constant I can set to ensure my site is (or is not) restricted?

You can force the plugin to be in restricted mode by adding the following to your wp-config.php file:

Or to ensure your site won’t be in restricted mode:

Make sure you add it before the /* That's all, stop editing! Happy blogging. */ line.

How are REST API requests handled?

{"code":"rest_not_logged_in","message":"This site is restricted. You must be logged in to access it.","data":{"status":401}}

Use the restricted_site_access_rest_response filter to change the status (any 4xx or 5xx code), body or headers. A header set to false is removed, and an array of values sends the header once per value. A response in any other shape falls back to the default, so the filter can’t lift the restriction by accident. For example, to point OAuth clients at your protected resource metadata (RFC 9728):

To handle REST API requests like any other request, as in earlier versions, use the restricted_site_access_use_rest_response filter:

When the ‘Discourage search engines