Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Managing Multi-Site Infrastructure: GA4 Authentication, Daemon Health Monitoring, and SEO Content Deployment

This session involved a comprehensive infrastructure review spanning analytics authentication, remote server health monitoring, and multi-property content deployment across three distinct web properties. Here's what was accomplished and the technical decisions that drove the work.

Google Analytics 4 Authentication and Data Access

The primary objective was establishing authenticated access to GA4 data for the dangerouscentaur@gmail.com account across multiple properties, specifically to enable programmatic reporting and analytics integration.

What was built:

  • Created /Users/cb/Documents/repos/tools/auth_ga.py — a Python-based OAuth2 authentication handler for GA4 Data API access
  • Leveraged google-auth-oauthlib library to manage the OAuth2 flow without hardcoding credentials
  • Stored reusable authentication tokens in a locked-down secrets directory rather than session-based credentials
  • Verified that existing client_id and client_secret from prior jada daemon authentication could be reused, reducing credential sprawl

Why this approach: Rather than embedding API keys directly in scripts or relying on temporary session tokens, we used OAuth2 with stored refresh tokens. This allows the daemon to programmatically pull GA4 reports without manual re-authentication, while keeping secrets off-disk in plain text. The authentication module is decoupled from reporting logic, making it reusable across multiple scripts.

Key commands executed:

python3 ~/Documents/repos/tools/auth_ga.py --account dangerouscentaur@gmail.com

This script handles the OAuth2 consent flow, stores the refresh token securely, and validates access to the GA4 Data API. File permissions on the secrets directory were explicitly locked down post-authentication to prevent accidental exposure.

The authentication module successfully listed GA4 accounts and properties under the dangerouscentaur account, confirming that data access was properly configured. A full 7-day GA4 report was pulled for the 86dfrom.com property to validate the pipeline end-to-end.

Remote Daemon Health Monitoring and Troubleshooting

The jada-agent orchestrator daemon running on AWS Lightsail instance 34.239.233.28 required a complete health audit, including service status, recent error patterns, and resource utilization.

Challenge: The SSH private key for the jada-key pair was not stored locally. Standard SSH authentication was unavailable.

Solution implemented:

  • Used AWS Systems Manager Session Manager as a fallback mechanism to establish connectivity without requiring stored private keys
  • Simultaneously invoked the AWS Lightsail API to generate temporary SSH credentials (GetInstanceAccessDetails endpoint)
  • Wrote temporary credentials to a secure file descriptor, tested the connection, and cleaned up immediately after the session concluded

Why this two-pronged approach: SSM Session Manager works without SSH keys (it uses IAM roles), but metrics collection required direct SSH access to the daemon's process tree. By pairing both methods, we had a robust fallback and direct access simultaneously.

Key findings from the daemon health report:

  • jada-agent.service status: Active and running for 3+ days with ~0.65% CPU utilization and 144MB memory usage — well within healthy parameters
  • Instance uptime: 11 days with zero failed status checks in the last 2 hours
  • Daily session usage: 3 of 5 allowed sessions consumed on May 13
  • Two sessions hit the 30-turn Claude API limit (exit code 1), one completed successfully and processed meaningful work (e-signature and crew page updates)
  • Critical issue identified: The port_sheet_sync OAuth token is expired/revoked, causing the 30-minute Google Sheets sync to fail with HTTP 400 errors since at least yesterday afternoon

Remediation required: Re-authenticate the Google OAuth token for port_sheet_sync.py using the same authentication framework established in the GA4 module above. This will restore automated port sheet synchronization.

Multi-Property Content Deployment and SEO Optimization

In parallel, three web properties underwent HTML updates and deployment:

86from.com (formerly 86dfrom.com):

  • Renamed directory from /Users/cb/Documents/repos/sites/86dfrom.com to /Users/cb/Documents/repos/sites/86from.com to match corrected domain naming
  • Updated index.html with corrected metadata and SEO tags
  • Created new content page at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean targeting the "86'd" restaurant terminology search query
  • Deployed to S3 bucket and invalidated CloudFront distribution cache to force immediate edge refresh

sailjada.com:

  • Performed extensive HTML refinements (15+ edits to index.html) focused on booking widget integration and form validation
  • Fixed double-brace template syntax conflicts within the booking widget JavaScript block that were conflicting with the page templating engine
  • Replaced all {{ }} and }} occurrences inside the booking widget section with single-brace syntax to prevent parser collisions
  • Validated JavaScript syntax before deployment to staging S3 bucket
  • Deployed to staging environment and invalidated corresponding CloudFront distribution
  • Embedded version tag with model ID into booking widget comment block for deployment tracking

queenofsandiego.com:

  • Modified BookingAutomation.gs (Google Apps Script) in two separate sessions to refine automation logic for booking workflows
  • Updated script maintained integration with the progress dashboard and task queue system

Why this multi-site approach: Each property serves a distinct business function but shares a common booking automation infrastructure. By treating them as a cohesive system rather than isolated sites, we ensured consistency in the booking widget, unified OAuth credential management, and streamlined deployment pipelines.

Infrastructure Architecture and Key Decisions

  • Secrets management: Centralized OAuth tokens in a locked-down directory rather than scattering credentials across multiple scripts. Single source of truth for authentication credentials across GA4, Google Sheets, and booking automation.
  • Remote access pattern: Dual-layer approach using both SSM Session Manager (keyless, IAM-based) and Lightsail temporary SSH credentials (direct metrics collection). Removes dependency on stored private keys while maintaining robust access.
  • Deployment strategy: Content deployed to S3 with CloudFront cache invalidation. Staging bucket for testing before production rollout. Version tags embedded in code comments for audit trails.
  • Template conflict resolution: Template engine double-braces isolated to the booking widget section only, preventing scope creep and making future refactoring safer.

What's Next