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.

Search engines and your login pages

Search engines follow the "Log in" links your theme prints, so Googlebot and friends regularly ask for /user and /user/login. The platform's bot guard turns those requests away before they reach Drupal — that's what it's for — but the refusals can show up in Google Search Console as crawl errors, and they spend your crawl budget on pages you never wanted indexed anyway.

The reason the crawlers keep coming back: Drupal's stock robots.txt only disallows the slash-suffixed forms (like /user/login/), not the bare /user, so those URLs stay fair game for crawling.

The clean fix is one line in your site's own robots.txt — and on this platform you don't need to touch the platform copy, because the web server looks for your override first, at:

TXT
sites/<your-domain>/files/robots.txt

Fetch your current live file from https://<your-domain>/robots.txt, save it, add this line to the existing Disallow: list, and upload the result to that path over SFTP:

TXT
Disallow: /user

Two things to keep in mind. The override replaces the platform file entirely, so always start from a copy of the live one — a one-line file would throw away all the stock rules. And if you serve several domains from one site, a per-domain variant named <domain>.robots.txt in the same folder wins over the plain robots.txt (the robotstxt module is honoured too, if you prefer managing the rules from within Drupal).

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.