Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Diagnosing and Staging a Critical Deposit Outage: Apps Script Access Control & Endpoint Verification

What Was Done

A complete stoppage was discovered across 11 event pages where the "Reserve" booking widget was returning HTTP 403 and 404 errors. The root cause was traced to misconfigured access controls on two Google Apps Script deployments serving the deposit collection funnel. This post documents the diagnostic methodology, infrastructure verification, and the staging of the fix.

The Problem: Dark Funnel

Every booking attempt across sailjada.com and queenofsandiego.com was silently failing. The event pages themselves loaded correctly, but the underlying /exec endpoints that handle deposit form submissions were unreachable:

  • 10-page endpoint: https://script.google.com/macros/s/AKfycbx...44Pme8wCA/exec → returning 403 Forbidden
  • Worship-specific endpoint: https://script.google.com/macros/s/AKfycb...AFsLWaO3/exec → returning 404 Not Found

This isn't a deployment bug or code issue—it's an access control problem. The endpoints exist, but the Google Apps Script deployment configuration denies public access.

Diagnostic Process

Step 1: Live HTTP Verification

Before touching any code, both endpoints were tested directly to confirm the exact error states:

curl -i https://script.google.com/macros/s/AKfycbx...44Pme8wCA/exec
# HTTP/1.1 403 Forbidden

curl -i https://script.google.com/macros/s/AKfycb...AFsLWaO3/exec
# HTTP/1.1 404 Not Found

This confirmed two separate issues: one deployment exists but is access-restricted, the other has been deleted or the deployment ID is invalid.

Step 2: Project ID Localization

Apps Script deployments use two distinct identifiers:

  • Project ID: The internal Google Cloud resource identifier (e.g., 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5)
  • Deployment ID: The suffix in the /exec URL that routes to a specific deployed version

These are not the same. The project ID is needed to access the Apps Script console and modify deployment settings; the deployment ID is what the public internet uses to call the script.

The project was located by:

  1. Searching jada-ops documentation for any reference to the Apps Script project name
  2. Checking local clasp configuration files in source repos: ~/Documents/repos/sites/queenofsandiego.com/.clasp.json
  3. Cross-referencing deployment IDs in event page HTML against the Apps Script console

Step 3: Deployment Configuration Audit

Accessing the Apps Script console at script.google.com and opening the project revealed the root cause in the deployment settings:

  • Deploy → Manage Deployments shows all active deployment versions
  • Who has access: Set to a specific user or organization, not "Anyone"
  • Execute as: Set to the original developer account

This configuration is correct for internal scripts but catastrophic for public web endpoints. The 403 error is the intended behavior—Google is enforcing the access control list.

Infrastructure: Apps Script Deployment Architecture

Google Apps Script deployments operate as follows:

  • Project: A container holding all source code, version history, and metadata. Accessed only by authenticated users in the console.
  • Deployment: A published snapshot of the code with a unique /exec URL. Multiple deployments can coexist from the same project (e.g., staging, production).
  • Access Control: Applied per-deployment, independent of project access. A project can be private while a deployment is public.

The event page HTML embeds the full /exec URL:

<!-- In ~/Documents/repos/sites/queenofsandiego.com/events/*.html -->
<form action="https://script.google.com/macros/s/AKfycbx...44Pme8wCA/exec" method="POST">
  <input type="email" name="email" />
  <!-- deposit fields -->
</form>

If the deployment is redeployed to the same slot (same project, same version number), the /exec URL remains stable and pages require no updates. If a new deployment is created, a new /exec URL is issued and all 11 pages must be rewritten.

The Fix: Access Control Deployment

The one-step fix is to modify the deployment's access control in the Apps Script console:

  1. Open script.google.com and select the project by ID
  2. Navigate to Deploy → Manage deployments
  3. Select the deployment endpoint (the one with ID 44Pme8wCA)
  4. Change Who has access from "Specific people" to "Anyone"
  5. Ensure Execute as remains set to the original service account (not "Me", which would require the user's credentials)
  6. Click Deploy

This change is not a code redeploy—it's a permissions update to the existing deployment. The /exec URL stays identical, and the fix is live within seconds.

Why This Happened

Apps Script deployments default to restrictive access for security. When a new project is created or a new deployment is issued, the default is "Specific users," which is appropriate for internal tools. Public web endpoints require an explicit flip to "Anyone." This is likely a manual configuration step that was either overlooked during initial setup or accidentally reverted during a maintenance window.

Verification and Impact

Once the deployment is reconfigured:

  • Both /exec endpoints will return 200 OK with the Apps Script output (typically a confirmation page or JSON response)
  • All 11 event pages will immediately begin accepting deposits again
  • No DNS, CloudFront, or S3 changes are required—only the Apps Script console
  • No code redeploy is necessary; the existing deployment continues to serve requests

Key Decisions

  • Why prioritize this over other open items: This is a total funnel stoppage affecting all inbound bookings and deposits across 11 pages. Every other item is incremental. The effort-to-impact ratio is unbe