Staging-Sites mit HTTP Basic Authentication verbinden

Viele Hoster (WP Engine, Kinsta, Pantheon, SiteGround) liefern Staging-Environments mit HTTP Basic Auth als Default-Access-Gate. Der Browser zeigt einen Username/Passwort-Dialog. Hubbees REST-Calls sehen den Dialog nie — der Server returnt HTTP 401 und die Connection schlägt fehl. Drei Approaches; nimm den, der deiner Host-Policy passt.

Wie du das Problem erkennst

Hubbee-Diagnose meldet basic_auth und Response-Body enthält WWW-Authenticate: Basic realm=… oder “Authentication required”. curl -i https://your-staging.example.com/wp-json/ von deinem Laptop — wenn du HTTP/1.1 401 und WWW-Authenticate: Basic siehst, ist das die Ursache.

Option 1: /wp-json/ aus Basic Auth ausschließen (empfohlen)

Die meisten Hosting-Panels lassen dich Basic Auth auf bestimmte URL-Patterns scopen. Der /wp-json/* REST-API-Pfad sollte ausgeschlossen sein damit authentifizierte Apps wie Hubbee mit der Site reden können.

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

• Toggle Exclude paths auf an
• Adde: /wp-json/

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

• Click Edit
• Zu Excluded paths: /wp-json/

Pantheon (Site Dashboard → Settings → Security):

• Pantheons Security-Tool ist on/off. Nutze Option 2 oder 3.

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

• Switch zu Whitelist mode und adde /wp-json/*

Apache (manuelle .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 (manuell):

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

Nach Speichern: https://your-site.com/wp-json/ in Private-Tab — solltest JSON sehen, keinen Password-Dialog.

Option 2: Hubbee-IPs whitelisten

Wenn dein Host nur IP-basiertes Bypass unterstützt (keine URL-Excludes):

1. Kopier das Hubbee-Infrastruktur-IP-Set von hubbee.io/legal/datenschutz → Infrastructure providers
2. Adde jede IP zu deiner Host-Basic-Auth-Allowlist
3. Speichern und Connection retry

Das Hubbee-IP-Set ist klein und stabil. Wir committen zu 30 Tagen Vorlauf via Changelog bevor wir neue Outbound-IPs adden.

Option 3: Public-Preview-URL nutzen

Wenn keine der obigen Optionen klappt (Host-Policy), bieten manche Hoster eine public Preview-URL die Basic Auth bypassed — typisch für Client-Review. Hubbee dann mit Preview-URL verbinden statt mit Gated-URL.

Catch: Wenn das Public-Preview-Window abläuft, bricht die Connection still. Nur für kurze Demos, nicht für dauerhafte Kundenarbeit.

Warum wir keine Inline-Credentials supporten

Hubbee akzeptiert explizit nicht https://user:pass@host/-Style Credentials in der Site-URL:

• Browser strippen sie aus Address-Bars und bannen sie in Forms (RFC 9110)
• Credentials würden in Logs + Audit-Trails landen — Security- und GDPR-Exposure
• Eine einzige Rotation des Staging-Passworts bricht die Connection still

Nutze eine der drei Optionen oben. Die halten die Credentials auf Hosting-Seite wo sie hingehören.

Production-Sites

Sobald die Staging-Connection funktioniert, nicht den Basic-Auth-Config auf Production spiegeln. Production-Sites sollten Basic Auth aus haben; Security via Standard-Layern (Wordfence, Cloudflare WAF, Login-Limiting). Hubbee erkennt accidental Basic-Auth auf Production und zeigt Warning im Site-Detail-Page.