CORS-Fehler wenn Hubbee deine Site nicht erreichen kann

Hubbees Calls an WordPress sind Server-zu-Server. Strenggenommen unterliegen sie nicht Browser-CORS-Rules — sind keine Browser-Requests. Aber mehrere Setups packen CORS-aware Middleware dazwischen die den Call trotzdem rejected, und das Symptom sieht im Diagnose-Tool aus wie ein CORS-Error.

Wie du das Problem erkennst

Diagnose meldet cors_blocked. Response-Body oder Headers enthalten:

• Access-Control-Allow-Origin
• not allowed by Access-Control-Allow-Origin
• CORS policy: No 'Access-Control-Allow-Origin' header is present

Wenn du in WP-Browser-DevTools → Network die OPTIONS-Preflight an /wp-json/bz/v1/* mit 403 oder 405 siehst, hast du ein CORS-Issue.

Root Causes (nach Häufigkeit)

1. Cloudflare Workers die Responses transformieren. Manche Account-Level-Workers strippen oder rewriten REST-API-Headers, brechen den Dialect den Hubbee erwartet. Worker bound an /wp-json/* deaktivieren und retry.

2. WordPress-Security-Plugin ersetzt REST-Server. Wordfence, Sucuri und iThemes können eigenen REST-Handler substituieren. Siehe Firewall- und Security-Plugin-Konflikte.

3. Custom rest_pre_serve_request Filter. Theme oder Custom-Plugin kann REST-Response overriden und Headers vergessen:

grep -r "rest_pre_serve_request" wp-content/plugins/ wp-content/themes/

Fix: entweder Customization entfernen oder erweitern damit */wp-json/bz/v1/* Pfade unverändert durchgelassen werden.

4. Hard-coded Access-Control-Allow-Origin in .htaccess / nginx.conf. Manche “Hardening”-Guides empfehlen den Header auf einen einzigen Origin zu pinnen. Bricht Server-zu-Server Clients wie Hubbee. Rule entfernen oder scopen:

# Schlecht — blockt Hubbee
Header set Access-Control-Allow-Origin "https://your-site.com"

# Besser — scope auf Browser-facing JS
<LocationMatch "^/wp-json/wp/v2">
  Header set Access-Control-Allow-Origin "https://your-site.com"
</LocationMatch>

5. Reverse-Proxy stripped Authorization-Header. Manche Reverse-Proxies (especially homegrown nginx-Setups) strippen Authorization-Header bevor sie an WordPress geben. Hubbee nutzt Bearer-Tokens — ohne Header returnt WordPress 401, Diagnose fällt auf Closest-Match (oft cors_blocked wenn OPTIONS-Preflight auch fehlschlägt). Verify:

curl -i -H "Authorization: Bearer test" https://your-site.com/wp-json/bz/v1/ping
# Expect: 401 mit { "code": "bz_unauthorized" }
# Wenn: 401 mit { "code": "missing_authorization" }, Header wird gestrippt

Nginx-Fix:

location / {
  proxy_set_header Authorization $http_authorization;
  proxy_pass http://php-fpm;
}

Quick-Test: Bypass + Confirm

Jeden Layer einzeln temporär deaktivieren:

1. Cloudflare → Development Mode für 3 Stunden (skippt die meisten Rules, gut für Tests)
2. WordPress → alle Security-Plugins deaktivieren
3. Hosting → Reverse-Proxy-Level WAF bypassen (Sucuri, Host-Managed-WAFs)

Nach jedem Step Site → Diagnose starten. Der erste der cors_blocked zu null flippt ist der Culprit. Layer wieder aktivieren und tunen.

Warum Diagnose manchmal CORS meldet wenn Ursache anders ist

Unser diagnose-site EF pattern-matched den Response-Body. Wenn der Body das Wort “CORS” enthält — auch nur in Debug-Log-Line von Security-Plugin — surfacen wir als cors_blocked. Wenn Suggested-Fix nicht zu Symptomen passt, check Probe-Details-Dropdown unter Result: zeigt Raw-HTTP-Status und Response-Snippet damit du echte Ursache siehst.