Connecting staging sites with HTTP Basic Authentication

Many hosts (WP Engine, Kinsta, Pantheon, SiteGround) ship staging environments with HTTP Basic Auth as the default access gate. The browser shows a username/password dialog before the site loads. Hubbee’s REST calls never see that dialog — the server returns HTTP 401 and the connection fails. There are three working approaches; pick the one that matches your host’s policy.

How to recognise the problem

The Hubbee diagnostic reports basic_auth and the response body contains WWW-Authenticate: Basic realm=… or “Authentication required”. Run curl -i https://your-staging.example.com/wp-json/ from your laptop — if you see HTTP/1.1 401 and WWW-Authenticate: Basic, this is the issue.

Option 1: Exclude /wp-json/ from Basic Auth (recommended)

Most hosting panels let you scope Basic Auth to specific URL patterns. The /wp-json/* REST API path should be excluded so authenticated apps like Hubbee can talk to the site.

WP Engine (User Portal → environment → HTTP Auth):

• Toggle Exclude paths on
• Add: /wp-json/

Kinsta (MyKinsta → environment → Tools → Password protection):

• Click Edit
• Add to Excluded paths: /wp-json/

Pantheon (Site Dashboard → Settings → Security):

• Pantheon’s security tool is on/off only. Use Option 2 or 3 instead.

SiteGround Staging (Site Tools → Security → Password Protect):

• Switch to Whitelist mode and add /wp-json/*

Apache (manual .htaccess):

<FilesMatch "\.php$">
  AuthType Basic
  AuthName "Staging"
  AuthUserFile /path/to/.htpasswd
  Require valid-user
</FilesMatch>

<Files "index.php">
  <If "%{REQUEST_URI} =~ m#^/wp-json/#">
    Require all granted
  </If>
</Files>

Nginx (manual):

location / {
  auth_basic "Staging";
  auth_basic_user_file /etc/nginx/.htpasswd;
}
location ^~ /wp-json/ {
  auth_basic off;
}

After saving, hit https://your-site.com/wp-json/ in a private browser tab — you should get JSON, no password dialog.

Option 2: Allowlist Hubbee IPs

If your host only supports IP-based bypass (no URL exclusions):

1. Copy the Hubbee infrastructure IP set from hubbee.io/legal/datenschutz → Infrastructure providers
2. Add each IP to your host’s Basic-Auth allowlist
3. Save and retry the connection

The Hubbee IP set is small and stable. We commit to 30 days’ notice via the changelog before adding a new outbound IP range.

Option 3: Use a public preview URL

If neither option above works (host policy), some hosts offer a separate public preview URL that bypasses Basic Auth — typically intended for client review. Connect Hubbee to the preview URL instead of the gated URL.

The catch: when the public preview window expires, the connection breaks. Acceptable only for short-lived demos, not for ongoing client work.

Why we don’t support inline credentials

Hubbee deliberately does not accept https://user:pass@host/ style credentials in the site URL. Reasons:

• Browsers strip them from address bars and ban them from forms (RFC 9110)
• The credentials would end up in our logs and audit trails — a security and GDPR exposure
• A single rotation of the staging password breaks the connection silently

Use one of the three options above instead. They keep the credentials on your hosting side where they belong.

Production sites

Once the staging connection works, do not mirror the Basic Auth config to production. Production sites should have Basic Auth off; security is handled by the standard layers (Wordfence, Cloudflare WAF, login limiting). Hubbee detects accidental Basic-Auth-on-production and surfaces a warning in the site detail page.