Skip to content
BOA Documentation

Powered by Grav

Restricting access to your site

Restricting access to your site

Sometimes you don't want the whole internet looking at a site. Maybe it's an intranet for your team, a staging copy you're still working on, or an admin-only area you'd rather nobody stumbles into.

Everything in this family you do from your own account — either by editing a small text file over SFTP, or with nano in your shell. You never touch the server itself, all of it is safe to turn on and easy to undo, and none of it can accidentally lock you out.

Which one do you want

The controls protect different things, and each has its own page:

  • Admin-page protection — a setting that's already on by default for every site. It quietly bounces anonymous bots away from your /admin pages so they can't hammer your login. Most people never need to think about it — but occasionally it gets in the way, and then you'll want to know how to switch it off. That's the rest of this page, just below.
  • Site IP lock — an opt-in that makes a whole site reachable only from a short list of IP addresses (yours, your office, your team). Everyone else gets a plain "403 Forbidden".
  • Login/admin IP lock — like the site lock, but scoped to just the /user and /admin pages: the public site stays open to everyone, while only your listed addresses can reach the login and admin area.
  • AI crawlers and assistants — a per-site policy deciding which classes of AI bot (training crawlers, AI search, assistant fetchers, utility bots) may read a site. Sensible defaults are already in force everywhere.

Pick whichever matches what you're trying to do. They're independent — you can use any, all, or none.

The admin-page protection (and how to opt out)

By default, when someone who isn't logged in asks for one of your admin-ish URLs — anything starting with /admin, plus /logout, /privatemsg, and /approve — the platform sends them straight back to your homepage instead of letting the request reach Drupal.

Why it does this: those pages are never cached, so every hit lands directly on Drupal. Bots love to pound the login page, and this stops them cheaply, before they get anywhere. It costs you nothing and you didn't have to set it up. For nearly every site, leave it exactly as it is.

There's just one situation where you'd want it off. Every so often it can catch a real person: if your own browser is holding an expired session or a stale cookie, you might click something under /admin and find yourself bounced to the homepage even though you thought you were logged in.

If that keeps happening and clearing your cookies doesn't settle it, you can turn the protection off for that one site.

Turning it off

You do this with a single line in your site's INI file. That file lives at:

TXT
sites/<your-domain>/modules/boa_site_control.ini

Open it over SFTP (create it if it isn't there yet), and add:

INI
disable_admin_dos_protection = TRUE

Save, and you're done. There's nothing to click and nothing to run — the change is picked up on its own, usually within about a minute. (The full details of how to find and edit these INI files, and why the short wait, live on the INI settings page — this is just the one setting you need.)

Turning it back on

Either delete that line, or set it back to the default:

INI
disable_admin_dos_protection = FALSE

Same short wait, and the protection is active again. Because the default is "on", even just removing the line restores it — you can't leave your admin pages exposed by forgetting to tidy up.

Careful with this one. Switching it off removes only the homepage bounce. It does not fling your admin pages wide open: there's a second, separate guard at the web-server layer that always refuses a /admin request from a client carrying no session cookie at all (a plain "403 Forbidden") and blocks known bots outright — and that guard stays on no matter what you set here.

So turning the setting off mainly lets a stale-cookie browser (which is the case you're fixing) reach /admin, where Drupal's own "Access denied" then takes over. It's still a small extra bit of exposure, so only turn it off if you actually have the browser-session problem above, and turn it back on once you've sorted it out.

When it's not something you can set

The controls in this family are entirely yours — you own the files, so you own the change. But some access questions live at a level below your account, on the server itself:

  • a firewall block,
  • a country-level ban,
  • blocking a specific abusive IP across all sites on the box, or
  • anything that isn't one of your own sites.

Those aren't things you can reach from your account. If you need one of them, open a support request with your host — that's who has the access to do it.

© 2026 BOA Documentation. All rights reserved.