Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Staging a Critical Deposit Flow Outage: Google Apps Script Access Control and Multi-Endpoint Recovery

Executive Summary

During a routine ops session on June 2, 2026, we discovered that the public deposit/reservation funnel across 11 event pages had silently failed. The "Reserve" widgets—critical revenue entry points—were returning HTTP 403 and 404 errors from their Google Apps Script endpoints. This post details the diagnostic process, infrastructure topology uncovered, and the staged fix for complete restoration.

What Was Done

We identified and staged fixes for two separate Apps Script deployment failures:

  • Primary endpoint (10 event pages): Deployment ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5 returning 403 Forbidden due to access control set to a restricted audience instead of "Anyone"
  • Worship endpoint (1 page): Deployment ID appearing to be deleted or access-revoked, returning 404 Not Found

The fix required no code changes, no source repo updates, and no CloudFront/Route53 modifications—only a single access control flip in the Google Apps Script console.

Technical Diagnosis Process

Step 1: Live Endpoint Health Check

We verified both endpoints directly via HTTP request:

# Primary endpoint (serves /reserve endpoint across 10 event pages)
curl -i https://script.google.com/macros/s/AKfyc...44Pme8wCA/exec

# Response: HTTP 403 Forbidden
# Indicates: Project exists, deployment exists, but access control denies this caller

# Worship-specific endpoint
curl -i https://script.google.com/macros/s/AKfyc...AFsLWaO3/exec

# Response: HTTP 404 Not Found
# Indicates: Deployment missing or completely unshared

Step 2: Mapping Event Pages to Endpoints

All 11 event pages (hosted on S3, served via CloudFront) embed one of two Google Apps Script endpoints in their reservation flow. We verified this by:

  • Scanning s3://queenofsandiego-web/events/*.html for <script src="https://script.google.com/..."> references
  • Dry-running endpoint rewrites across all pages to confirm which pages call which deployment
  • Confirming 10 pages point to the primary 403 endpoint, 1 page (worship) to the 404 endpoint

Step 3: Locating Apps Script Projects

We traced the project IDs by:

  • Searching ~/jada-ops/ for Apps Script project references
  • Checking ~/.clasp.json and all appsscript.json files in source repos for matching project IDs
  • Reading deployment metadata to confirm display names matched the intended purpose

The primary project is internal to your Google Workspace and controls reservation processing for all standard events. The worship endpoint appears to be a separate, older deployment that was either removed or had access revoked.

Infrastructure Topology

Current Flow (Before Fix)

User Browser
    ↓
queenofsandiego.com (CloudFront)
    ↓
S3 event page HTML (s3://queenofsandiego-web/events/)
    ↓
<form> calls JavaScript
    ↓
https://script.google.com/macros/s/[deployment-id]/exec
    ↓
Google Apps Script (403 or 404)
    ✗ Reservation fails silently

Why This Matters

Every "Reserve" button across your public event pages is a direct, client-side call to Apps Script. There is no intermediary Lambda, no API Gateway, no fallback. When the endpoint returns 403 or 404, the browser cannot complete the reservation. From a user perspective: they click "Reserve," nothing happens. From your perspective: zero visibility into how many deposits are failing.

Key Decisions and Trade-Offs

Why Google Apps Script for Deposits?

Apps Script deployments allow direct, unauthenticated (public) execution without additional infrastructure. This keeps the architecture simple and reduces operational overhead—no Lambda versioning, no API Gateway throttling, no separate webhook secrets to manage. The trade-off: access control is entirely Google's responsibility, and misconfiguration is a silent failure.

Dual Deployments (Primary + Worship)

The existence of two separate endpoints suggests either:

  • An older, deprecated deployment that wasn't fully retired (worship), or
  • An intentional split for isolated reservation logic (unlikely, given both handle the same flow)

Post-fix, we recommend consolidating to a single deployment if the worship endpoint is no longer needed. This reduces confusion and limits future misconfiguration.

No Source Code Changes Required

The 403 error is not a code bug—it's an access control misconfiguration in the Google console. Redeploying the code would not fix it. The fix is purely a permissions change in script.google.com → Manage Deployments → Access.

The Fix (Staged, Not Yet Applied)

In your browser, navigate to script.google.com:

  1. Open the project with ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
  2. Select Deploy in the left sidebar
  3. Click Manage Deployments
  4. Find the active deployment (the one corresponding to deployment ID ending in 44Pme8wCA)
  5. Edit its settings:
    • Who has access: Change from the current restricted audience to "Anyone"
    • Execute as: Keep as "Me" (your Google Workspace account)
  6. Click Deploy

The deployment URL remains unchanged. The fix takes effect immediately (within seconds). All 10 event pages will resume normal reservation flow without any code changes.

Worship Endpoint

For the 404 endpoint, you have two options:

  • If still needed: Redeploy the worship project or restore from backup
  • If obsolete: Update worship.html to point to the primary endpoint instead

We recommend confirming which before deploying.

What's Next

  • Immediate: Apply the access control fix in the Google console (2 minutes, no downtime)
  • Verify: Hit all 11 event pages in