Add redirects and password protection

Two jobs belong in the web server rather than in your application: sending visitors from an old address to a new one, and asking for a password before a page loads. SrvYard puts both on the site's Network tab. Rules are written into the site's Nginx configuration, tested with nginx -t and applied with a reload, so they work even for paths your application knows nothing about, such as an old WordPress URL or a static file.

This article explains the Redirects and Security pages: how to add, import, disable and remove redirect rules, how regular-expression redirects capture parts of the address, how to protect a site with Basic authentication, and the limits that apply.

Before you begin#

• A ready site on Nginx. Rules need a site whose Nginx configuration SrvYard generates.
• Permission. Redirects need the permission to manage redirects and password rules the permission to manage security. Owners and admins have both.
• A site that uses the generated configuration. If you replaced the whole Nginx text in the site's editor, both pages show This site uses its own Nginx configuration. Rules are kept but take effect only when the generated configuration is back in use. Reset it in the Nginx editor, or add the directives to your own text.
• HTTPS for passwords. Basic authentication sends the password with every request, in an easily decoded form. Use it only on a site that forces HTTPS.

1. Open the Network tab#

Open the site and choose Network. Two sub-pages sit under it: Security and Redirects.

1. Redirects. The sub-page for redirect rules. Security is next to it.
2. Add redirect rule. Opens the form in step 2.
3. Import from CSV. Adds many rules at once (step 3).
4. A rule. Each row shows from -> to, the type (Temporary (302) or Permanent (301)), a regex badge for pattern rules, an Enabled switch and a row menu with Edit and Delete.

The switch turns a rule off without deleting it: SrvYard removes it from Nginx and keeps it in the list. Use Search redirects... and the Type filter to find rules in a long list. A site can have up to 300 redirect rules.

2. Add a redirect#

1. From. The old path, starting with /, for example /old-pricing. It may use letters, digits and . _ ~ @ : , + = / -, up to 200 characters.
2. To. The new place: a path such as /pricing, or a full http:// or https:// address. It may not start with //, contain .., spaces, quotes, ; or braces.
3. Type. Temporary (302) tells browsers and search engines the move may change. Permanent (301) tells them to replace the old address in their records. Prefer 301 when the move is final; browsers cache it for a long time.
4. Regular expression. Treat From as an Nginx pattern that starts with ^. Use $1 to $9 in To for the groups it captures.

Press Add redirect rule. The toast says "Redirect added and Nginx reloaded." If Nginx rejects the configuration, the change is rolled back and you see "Nginx did not accept the change." A second rule from the same path is refused with "There is already a redirect from ...".

Pattern rules#

Turn on Regular expression to redirect a whole family of paths. For example, ^/blog/(.*) as From and https://blog.acme-studio.example/$1 as To sends /blog/launch to the same path on the blog domain, as in the screenshot above. A pattern must start with ^, may capture up to nine groups, may use $ only at the end and must compile as a valid expression. If To uses $3 but the pattern captures only two groups, SrvYard says so.

3. Import many redirects from a CSV file#

1. CSV. One rule per line in the order from,to,type,regex. The type is 301, 302, permanent or temporary (default 302); the regex column is true or false (default false). A header row is optional. The example lines show the placeholder format.
2. Choose a file. Loads a file into the box instead of pasting.
3. Check the file. Reads the rows and shows what would be imported and what is wrong, line by line, without saving anything. Rows that repeat a rule already on the site are marked as duplicates.

Then press Import rules. One import reads at most 300 rows and 256 KB. Rows with errors are skipped and counted in the toast. If nothing new remains, SrvYard says "There is nothing new to import."

4. Protect the site with a password#

Open the Security sub-page.

1. Network. The tab that holds both sub-pages.
2. Add security rule. Opens the form. The page explains that "Passwords are hashed before they leave SrvYard and can never be read back."

1. Name. The text shown in the browser's password prompt. Letters, digits, spaces, ., _ and -, up to 60 characters, starting with a letter or digit. It defaults to "Restricted Access".
2. Path (optional). Empty protects the whole site. A path such as /admin protects it and everything below it. Only one rule can protect the whole site, and only one can protect a given path: "Another rule already protects ...".
3. Username. Letters, digits and . _ @ -, up to 64 characters. Press Add credential for each person or service that needs access, up to 25 per rule. The same name cannot appear twice in a rule.
4. Password (8 to 72 characters). Printable ASCII only. The eye shows what you typed. SrvYard hashes it before storing it and never shows it again.

Press Add security rule: "Security rule added and Nginx reloaded." A rule without credentials is saved but protects nothing until you add one.

On the list, the Credentials column shows how many users a rule has, the Enabled switch turns it off ("The site becomes publicly reachable again.") and the row menu edits or deletes it.

Troubleshooting#

• "Nginx did not accept the change." The generated configuration failed nginx -t; SrvYard rolled the rule back. Check the path or pattern for a typo, then try again. A custom Nginx file can also be the cause.
• A rule is saved but nothing happens. The site uses its own Nginx text (see the notice at the top of the page), the rule is switched off, or a security rule has no credentials.
• The browser keeps asking for the password. The username or password does not match, or the page loads other paths covered by the rule. Check the Path.
• "A site can have 20 security rules." Merge rules by path, or remove old ones. The limit for redirects is 300.
• A regular expression is refused. It must start with ^, use only the allowed characters, capture at most nine groups and not end with a backslash.
• The redirect loops. The target address is itself matched by a rule, for example a pattern that also matches the destination path. Make From more specific, or switch the rule off and test.
• Old pages still redirect after deleting the rule. A permanent (301) redirect is cached by the browser. Clear the cache or test in a private window.

Related#

• Force HTTPS and HSTS: send visitors to the secure address before a password is asked.
• Add a domain, a free subdomain and DNS records: the www redirect lives on the domain, not here.
• Customise Nginx with templates: when rules are not enough.
• Deploy hooks, health checks and release retention: keep checks working behind a password.