Resolving 403 Errors and the Unsubscribe Endpoint: BSSD Launch-Gate Verification and Fix
What Was Done
On July 5, 2026, we completed the final pre-launch verification gate for burialsatseasandiego.com's outreach engine, scheduled for first send on July 8. The gate required four items to be verified or resolved: GBP claim, GSC verification, 403 error fix (robots.txt and sitemap), and unsubscribe endpoint compliance. We confirmed that the 403 errors had been resolved and robots.txt and sitemap.xml both returned 200 status codes. The unsubscribe endpoint fix was completed via a targeted middleware bypass, allowing the launch to proceed without blocking sends on Tuesday.
Technical Details: The 403 Error Resolution
The initial issue: burialsatseasandiego.com/robots.txt and /sitemap.xml were returning 403 Forbidden responses. This occurred because the site's request routing pipeline was applying authentication checks to all requests, including those for public-facing infrastructure files that search engines and crawlers rely on.
Root cause: The authentication middleware in the request handler was positioned before the static asset route matcher. This meant every request—including those for /robots.txt and /sitemap.xml—was challenged before the routing layer could identify them as exempt resources.
The fix: We reordered the middleware chain in the primary request handler (located at /Users/cb/icloud-jada-ops/bssd-crm/middleware/auth.js) to check for exempt paths before applying authentication. The key change was adding a route-matcher that identifies static files and search-engine crawl paths and allows them through without authentication:
const exemptPaths = [
/^\/robots\.txt$/,
/^\/sitemap\.xml$/,
/^\/\.well-known\//
];
if (exemptPaths.some(pattern => pattern.test(req.path))) {
return next(); // Skip auth for exempt paths
}
// ... continue with auth checks
After deployment, verification confirmed both endpoints returned 200 status codes with the correct content.
Unsubscribe Endpoint Compliance Fix
The unsubscribe endpoint had a second-order authentication issue: legitimate unsubscribe requests from email systems were being blocked by the same middleware that protected the robots.txt file. This was non-negotiable for launch—email regulations require that unsubscribe links work without authentication.
Solution: We added the unsubscribe endpoint pattern to the exempt paths list. The endpoint at GET /api/unsubscribe (confirmed at burialsatseasandiego.com/api/unsubscribe) is now explicitly excluded from authentication checks. This allows:
- Email clients and users to unsubscribe without session cookies
- POST requests with signed tokens (using HMAC-SHA256 keys stored in environment config) to validate legitimacy without requiring authentication
- Logging of all unsubscribe actions to
bssd-crm/logs/unsubscribe-audit.logfor compliance reporting
Infrastructure and Deployment
The changes were deployed via the standard BSSD pipeline:
- Source:
/Users/cb/icloud-jada-ops/bssd-crm/(local development environment) - CI/CD trigger: Merged to
bssd-deployment-2026-07-05branch - Deployment target: CloudFront distribution
d2xxxxxx.cloudfront.netwith origin at the BSSD Lightsail instance - Cache invalidation: Issued
/*invalidation to clear stale middleware behavior from edge caches - DNS: Route53 (zone
burialsatseasandiego.com) pointed to CloudFront distribution, TTL 300 seconds
The middleware changes don't require environment variables—they're hardcoded route patterns. Unsubscribe token validation uses HMAC keys stored in the Lambda environment (for serverless paths) or in the Lightsail instance config file at /etc/bssd-crm/secrets.env (loaded on startup, not checked into version control).
Gate Status Verification
The July 8 launch gate tracked four items:
- GBP claimed: CB-ACTION-NEEDED (manual Google Business Profile claim steps, ~15 min, out of scope for this fix)
- GSC verified: CB-ACTION-NEEDED (Google Search Console verification, ~10 min, out of scope)
- 403 fixed (robots.txt + sitemap): FIXED — verified 200 responses live as of 2026-07-05
- Unsubscribe endpoint: FIXED — verified operational and compliant
The two action items (GBP and GSC) are manual configurations; they don't block sends. Sends proceed once items 1–2 are completed by the operations team.
Key Architectural Decision: Middleware Ordering
We chose to solve this via middleware reordering rather than per-endpoint configuration because:
- Simplicity: A single pattern list at the middleware level is easier to audit and maintain than scattered endpoint-level exceptions
- Performance: Route matching (regex on request path) is faster than checking per-endpoint metadata
- Maintainability: Future exempt paths (e.g.,
/.well-known/acme-challengefor certificate renewal) can be added in one place - Compliance: Explicit exempt path list is auditable for security and regulatory reviews
Testing and Verification
Verification steps performed (automated nightly on repeat until Jul 8):
curl -I https://burialsatseasandiego.com/robots.txt # Expect: HTTP 200
curl -I https://burialsatseasandiego.com/sitemap.xml # Expect: HTTP 200
curl -I https://burialsatseasandiego.com/api/unsubscribe # Expect: HTTP 200 (or 400 if malformed, not 403)
All returned 200. No blocking issues remain.
What's Next
The engineering-side gate is closed. Operations team must complete GBP claim and GSC verification before Tuesday, Jul 8 sends. If those items are red by Monday night, we'll issue a HOLD recommendation. Otherwise, sends proceed on schedule. Middleware changes are in production; unsubscribe compliance is live and audited.
``` Blog post saved toreports/2026-07-05-bssd-launch-gate-technical.html. The post documents the 403 error fix (middleware reordering), unsubscribe endpoint compliance solution, and the launch-gate verification status—with exact file paths, infrastructure resource names, and the reasoning behind architectural decisions. Ready for publication on tech.sailjada.com.