Password-protected areas
Putting a password in front of a directory, or a whole website, in the web server rather than in the application. Whatever is inside never runs for somebody who does not have one, which is what makes this the right tool for a staging site and for the admin path of something you do not fully trust.
Where it is
A website, then Security, then Passwords.
Press Protect a directory. Leave the path empty to protect the whole website, which is the usual answer for a staging copy.
You can protect a directory on any website, whatever it runs: the check happens in the web server, so it does not matter whether the thing inside is PHP, a Node.js application or static files.
Why in front rather than inside
The request is refused before your application sees it.
An application’s own login page is code: it runs, it connects to a database, it has plugins, and it has a version with a known problem in it one day. A password here is checked by the web server before any of that happens, so a request without one costs a refusal and reaches nothing.
That is why this works on a staging site that is a copy of production, on the admin path of an application you inherited, and on a directory of files that are not meant to be public but are sitting in the website anyway.
It is not a replacement for the application’s own accounts. It is one password for everybody who should get past the door, and it says nothing about who they are once they are through.
Before you rely on it
Without a certificate the password is sent in the clear.
A browser asked for one of these sends it with every single request to that area, not once at sign-in. On a website with no certificate, that is the password travelling in plain text dozens of times a page. The panel says so on the page rather than letting you find out.
Issue the certificate first. It takes a few seconds and renews itself: see Certificates and HTTPS.
The inputs
What each box means, and what it refuses.
| Field | What it means | Limits |
|---|---|---|
| Path | The directory inside the website this covers, relative, with no slash at either end. Empty protects the whole website. | One area per directory. Protecting the same path twice is refused. |
| Prompt | What the browser shows in its password box. Name the site, not the secret. | At most 80 characters, plain text. No quotes, semicolons or line breaks, because it is written inside quotes in the web server’s own configuration. |
| Username | A name that may sign in. | At most 32 characters: letters, digits, and . - _ @. The same name twice in one area is refused. |
| Password | Set when you add somebody, and replaced by setting it again. | Stored as a bcrypt hash. The panel never holds the password, and cannot show it to you later. |
| People per area | How many names one area may list. | 100 |
| Areas per website | How many areas one website may have. | 40 |
Where the passwords live
Hashed, in a file only the web server reads.
Each area has a file of bcrypt hashes, written by root, readable by the web server’s group and by nothing else on the machine. The panel keeps the usernames so it has something to list, and does not keep the passwords, so there is nothing to show you and nothing to leak.
bcrypt rather than the single unsalted pass that password files have historically used. The cost is the library default on purpose: the web server checks this on every request to the area, so a higher number would be a page that waits.
The file is named by the panel’s own identifier for the area rather than by its path, which is why you can rename the directory an area covers without the live configuration pointing at a file that has moved.
A worked example
A staging site, and one admin path.
A staging copy of a shop, closed to everybody but two people, is one area with an empty path:
Path (empty, the whole website) Prompt Staging Users rob, dana
A live site whose administration path you would rather not have found is a second area on the same website:
Path wp-admin Prompt Site administration Users rob
Those two can coexist because they cover different directories. A second area also covering wp-admin would be refused: one area covers one directory, so there is never a question about which password applies.
With WordPress specifically, protecting wp-admin also blocks admin-ajax.php, which parts of the public site may use. Check the front end after you turn it on rather than assuming.
What this is not
Three neighbouring tools, and when each is the right one.
Refusing addresses is on the same Security tab under Blocked addresses. Use it to turn away a specific source. It is a list of up to 250 addresses or ranges; a longer list belongs in the firewall.
Hardening the website is the set of switches beside it: never run a script from an upload directory, refuse files that are never content, refuse the paths scanners ask for, and the rest. Those apply to everybody, including people who have the password, and most websites should have them on whether or not anything here is protected.
Keeping files out of the website is better than protecting them in it. A directory of invoices under private is not served at all, by anybody, with or without a password. See The file manager for which trees are published and which are not.