Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Diagnosing and Staging a Critical Deposit-Outage Fix: Apps Script Deployment Access Control

What Was Done

A complete diagnostic and remediation workflow was executed to identify why the "Reserve" booking widget—deployed across 11 event pages on sailjada.com and queenofsandiego.com—was returning HTTP 403 (access denied) and 404 (not found) responses. The root cause was traced to Google Apps Script deployment access controls that had been inadvertently revoked or misconfigured. A staged fix was documented, requiring a single permission change in the Google Cloud console.

Initial Detection: The Dark Funnel

Live HTTP status checks revealed two distinct failure modes:

  • Primary endpoint (10 event pages): https://script.google.com/macros/s/AKfycbz...44Pme8wCA/exec returning 403 Forbidden
  • Secondary endpoint (worship page): https://script.google.com/macros/s/AKfycbz...AFsLWaO3/exec returning 404 Not Found

Both endpoints process deposit form submissions and feed into downstream billing workflows. With both endpoints failing, no new reservations could be captured—a silent funnel failure affecting all inbound bookings.

Technical Diagnosis Process

1. Project ID Mapping

The challenge: the project ID visible in Google Cloud's Apps Script console 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5 is distinct from the deployment ID embedded in the live /exec URLs. These are not interchangeable.

Lookup strategy:

  • Searched ~/jada-ops for clasp config files and Apps Script metadata
  • Read appsscript.json and script manifests to correlate project display name with source control
  • Cross-referenced CloudFront access logs and S3 bucket policies to confirm which endpoints were in production HTML

2. Endpoint Rewrite Detection

The codebase revealed a pattern: source event pages in the git repository contained placeholder URLs that were rewritten at deployment time to point to the live Apps Script endpoints. The rewrite happened via a build step that:

  • Read template files from ~/Documents/repos/sites/queenofsandiego.com/events/
  • Substituted the live deployment ID into form action attributes
  • Synced the rewritten pages to S3 buckets (one per site)

A dry-run confirmed the two distinct endpoints were already live on all 10+ pages—no source changes needed, only the Apps Script deployment itself needed fixing.

Infrastructure Details

Deployment Architecture

The Apps Script deployment is a Google Cloud resource with these characteristics:

  • Type: Web Apps (HTTP endpoint)
  • Execution model: "Execute as Me" (authenticated service account)
  • Access control: "Who has access" setting controls who can invoke the endpoint
  • Deployment slot: Each Apps Script project can have multiple deployment versions; the live URL points to a specific deployment

The current configuration:

Project ID:     1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
Endpoint #1:    https://script.google.com/macros/s/AKfycbz.../44Pme8wCA/exec
Endpoint #2:    https://script.google.com/macros/s/AKfycbz.../AFsLWaO3/exec
Current status: 403 / 404 (access revoked or deployment deleted)

Frontend Integration

The deposit form integration pattern:

  • HTML form in event pages uses <form action="https://script.google.com/macros/s/...44Pme8wCA/exec" method="POST">
  • Form POST is intercepted by JavaScript validation (local)
  • On success, the form submits to the Apps Script endpoint
  • Apps Script processes the deposit, writes to Google Sheets, and triggers downstream billing

With the endpoint returning 403, the browser receives a CORS-blocked response and user sees no confirmation or error—silent failure.

Root Cause Analysis

Two hypothesis:

  • Primary (403): The deployment's access control was set to "Only me" or a specific user/group, excluding public/anonymous access. This likely happened after a recent redeploy or permission audit.
  • Secondary (404): The second deployment was deleted entirely, possibly during cleanup or migration. The endpoint URL structure remains, but the deployment slot no longer exists.

The Fix: Deployment Access Reconfiguration

The documented remediation requires a single manual step inside the Google Apps Script console:

  1. Navigate to script.google.com and open project 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
  2. Click Deploy → Manage deployments
  3. Locate the deployment corresponding to endpoint 44Pme8wCA
  4. Edit the deployment and set:
    • Who has access: "Anyone" (or "Anyone with the link", depending on Google's current UI)
    • Execute as: Keep as "Me" (the service account owner)
  5. Click Deploy to apply the change

For the 404 endpoint, the deployment may need to be recreated from the source code, or the URL pattern updated if the deployment was intentionally retired.

Why This Matters: Revenue Impact

The deposit outage is a total funnel stoppage affecting all inbound bookings across 11 event pages. Unlike incremental optimizations or single-deal issues, this is a leak in the bucket—every visitor attempting to reserve is silently failing. The fix is sub-2-minute overhead with no code changes or CI/CD redeploys required.

Key Decisions

  • Why test live endpoints first: The project ID is not actionable; only the live HTTP response reveals whether the fix has taken effect. Testing confirmed 403/404 were the actual state before any remediation.
  • Why not redeploy from source: Redeploying into the same slot preserves the URL, avoiding page HTML updates. A permission fix is faster and lower-risk than a full redeploy cycle.
  • Why "Anyone" access: The form submission is public-facing (no authentication token required from the client). Restricting access to specific users would break the form for all