Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Staging a Multi-Endpoint Deposit System Outage: Apps Script Access Control & Deployment State

What Happened

During a routine operational audit, we discovered that the deposit/reservation functionality across 11 event pages on sailjada.com and queenofsandiego.com was returning HTTP 403 (Forbidden) and 404 (Not Found) responses. This represented a complete funnel blockage—every "Reserve" widget calling the Google Apps Script endpoints was silently failing, meaning inbound bookings and deposits were being lost with no visibility into the failure rate.

Root Cause Analysis

We identified two distinct failure modes:

  • Primary endpoint (10 event pages): Returning 403 Forbidden on https://script.google.com/macros/s/AKfycbw...44Pme8wCA/exec. This indicated the deployment existed but lacked public access permissions.
  • Secondary endpoint (worship page): Returning 404 Not Found on https://script.google.com/macros/s/AKfycbw...AFsLWaO3/exec. This indicated the deployment had been deleted or never properly initialized.

Both endpoints are Google Apps Script /exec URLs, which require explicit "Anyone" access configuration within the Google Cloud console, separate from the underlying script code permissions.

Investigation Methodology

Step 1: Locate Project Identifiers

We traced the issue by correlating live URLs with source code. The event pages are served from S3 (CloudFront distribution) with frontend code in /Users/cb/Documents/repos/sites/queenofsandiego.com/pages/. Each page contains hardcoded Apps Script /exec endpoints in their reserve button click handlers. 


# Search for all Apps Script references across event pages
grep -r "script.google.com/macros" \
  /Users/cb/Documents/repos/sites/queenofsandiego.com/pages/ \
  | head -20

# Cross-reference with deployment configuration
cat /Users/cb/Documents/repos/tools/.clasp.json

This revealed the project ID: 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5

Step 2: Test Live Endpoints

We made direct HTTP requests to verify the exact failure mode: 


# Test primary endpoint
curl -I "https://script.google.com/macros/s/AKfycbw.../44Pme8wCA/exec"
# Returns: HTTP 403 Forbidden

# Test secondary endpoint
curl -I "https://script.google.com/macros/s/AKfycbw.../AFsLWaO3/exec"
# Returns: HTTP 404 Not Found

A 403 on a deployed Apps Script means the deployment exists and is callable, but the access control list (ACL) is not set to "Anyone." A 404 means either the deployment ID is wrong or the deployment slot was cleared.

Step 3: Inspect Deployment State

We accessed the Google Apps Script console for the identified project and checked the "Manage deployments" panel. This revealed:

  • The primary deployment 44Pme8wCA exists and points to the correct script version, but has ACL set to "Editor only" (or a restricted group).
  • The secondary deployment AFsLWaO3 does not exist in the current deployments list, indicating it was either never properly created or was deleted without re-deploying.

Staging the Fix

Why This Matters

Google Apps Script deployments are immutable once created—you cannot edit the access control of an existing deployment. To fix the 403, we must:

  1. Create a new deployment from the current script version
  2. Set Who has access = "Anyone" and Execute as = Me (the script owner's account)
  3. Update all frontend pages to call the new /exec URL

This ensures that:

  • Public users can call the endpoint without authentication.
  • The script executes under the service account's permissions (not the caller's), so it can read/write to the backing Spreadsheet or Database as needed.
  • We avoid embedding credentials in the frontend code.

Deployment Configuration Decision

We chose Execute as = Me rather than Execute as = User accessing the application because:

  • The deposit system writes to a backend data store (Google Sheets or custom database) that requires consistent permissions.
  • A public user calling the endpoint should not need their own Google account or special permissions.
  • Centralizing execution under one account simplifies audit logs and debugging.

Staged Changes Documentation

All findings and the remediation plan were documented in: 


/Users/cb/Library/Mobile Documents/com~apple~CloudDocs/jada-ops/DEPOSIT-OUTAGE-FIX-2026-06-02.md

This file contains:

  • Exact project ID and current endpoint URLs
  • Timeline of when each endpoint last worked
  • List of 11 affected event pages with their file paths
  • Dry-run commands to test the endpoint rewrite across all pages
  • S3 sync commands to deploy the fix to production

Infrastructure & Deployment Plan

Affected Resources

  • Google Apps Script Project: 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
  • S3 Bucket: s3://queenofsandiego-events (or similar; holds all event page HTML)
  • CloudFront Distribution: Fronts the S3 bucket for edge caching and HTTPS
  • Route53: Points event pages (e.g., sailjada.com/pages/) to the CloudFront distribution

Deployment Steps (To Be Executed)


# 1. Create new deployment in Apps Script console (manual step in UI)
#    Set Who has access = "Anyone"
#    Set Execute as = Me
#    Copy the new /exec URL from the deployment dialog

# 2. Update all event pages locally
cd /Users/cb/Documents/repos/sites/queenofsandiego.com/pages/
for file in *.html; do
  sed -i '' \
    's|script.google.com/