Commit Graph
11 Commits
Author SHA1 Message Date
twooey 61ea299b0e Fix Stripe authorization lifecycle timing 2026-08-28 17:18:54 -04:00
twooey 21038d68ca Replace Helcim integration with WooCommerce Stripe 2026-08-28 16:59:08 -04:00
twooey 197938f482 pushing stuff that was worked on 2026-08-28 15:17:46 -04:00
twooeyandClaude Sonnet 5 7023044278 Sync README with current project state
Top summary still said Week 3+ was undone even though checkout/order
engine has its own finished section further down; "what's deliberately
not here yet" claimed no tests exist at all. Adds a Testing section and
corrects the Week 4/BooksRun/Ingram/CI status bullets to match reality.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MqhgnCRjjVLFnZ3Jpn93Vg
2026-08-28 11:21:15 -04:00
twooeyandClaude Sonnet 5 8b149a672d Restrict production wp-admin/wp-login to an IP allowlist (opt-in)
New WP_ADMIN_ALLOWED_IPS env var (space-separated CIDR ranges, matching
Caddy's remote_ip syntax directly). Defaults to 0.0.0.0/0 ::/0 (today's
open behavior) when unset, resolved at the Compose level rather than in
the Caddyfile so an unset var can never leave `remote_ip` with zero
arguments and fail Caddy's startup. admin-ajax.php stays exempt since
WooCommerce routes logged-out storefront AJAX through it. Production
only — staging is already LAN-only.

Verified live: a scratch Caddy instance on a Docker network, with a
sibling container's actual observed source IP used to prove both the
blocked (403 on wp-admin/wp-login, everything else unaffected) and
allowed (matching CIDR lets it through) cases, plus `docker compose
config` to confirm the unset-var default resolves correctly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MqhgnCRjjVLFnZ3Jpn93Vg
2026-08-28 11:15:55 -04:00
twooeyandClaude Sonnet 5 4079bfceac Week 3: checkout + order engine (Helcim gateway, pre-charge recheck, order state machine)
Wires up Helcim's free WooCommerce plugin (installed inert until a sandbox
token exists) alongside a synchronous pre-charge supplier/margin recheck
and a fraud-check hook, both firing immediately before payment per the
Appendix B immediate-charge decision. Adds a custom order-status sequence
(bsc-ordered/bsc-shipped/bsc-exception) as the state machine and review
queue, an Action Scheduler-backed supplier-submission job with idempotency
guards, a bsc_order_audit ledger, and two new transactional emails.

Hooks both the classic WooCommerce checkout actions and the real
woocommerce_checkout_validate_order_before_payment hook, since this site's
storefront runs WooCommerce Blocks/Store API rather than the classic
shortcode checkout (confirmed by reading WooCommerce's own source after
the classic hooks turned out not to fire in live testing).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D2gmgaDVXcRGCwLfdXQajD
2026-08-27 20:03:32 -04:00
twooeyandClaude Sonnet 5 ea144d0298 Fix staging HTTPS: force tls internal, require a hostname not a bare IP
Two real, verified findings from actually testing the "let Caddy issue a
self-signed cert automatically" approach against a literal IP:

1. TLS SNI is not sent for literal IP connections (out of spec — SNI's
   HostName type explicitly excludes IPs). Confirmed via openssl s_client:
   the handshake fails with a TLS-layer internal_error, even though Caddy
   logs "certificate obtained successfully" — Caddy has no way to select a
   cert without SNI. No Caddyfile config fixes this; the address has to be
   a hostname.

2. Caddy's automatic-HTTPS heuristic only treats bare IPs and "localhost"
   as obviously-private. Any other name — including a made-up LAN hostname
   like "bookstore-staging.test" — it assumes might be real and tries
   Let's Encrypt, which fails the same way staging.example.com did.
   Fixed by forcing `tls internal` explicitly in Caddyfile.staging,
   removing the guesswork entirely.

Verified end-to-end with curl --resolve (proper SNI, no real DNS/hosts
change needed to test): direct HTTPS 200, HTTP->HTTPS redirect chain 200.

README now documents the /etc/hosts requirement and how to trust Caddy's
root cert to skip the one-time browser warning.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 12:22:58 -04:00
twooeyandClaude Sonnet 5 3876a6ba30 Fix DB password corruption via Docker secrets file mechanism
The reported bug (a generated password containing "$BRjTx3tlmSpz" got
silently blanked, breaking the DB connection) is the same Compose
interpolation issue as the earlier bcrypt hash, but this time in fields
that are genuinely user-chosen and can't just be avoided by convention.

Switched DB_PASSWORD/DB_ROOT_PASSWORD to Docker's official `_FILE`
secrets convention (MARIADB_PASSWORD_FILE / WORDPRESS_DB_PASSWORD_FILE),
backed by Compose's native `secrets:` mechanism: deploy.sh writes the raw
value to secrets/<env>/db_password, and the container reads that file
directly — the value never passes through Compose's ${VAR} interpolation
at all. Verified end-to-end with an actual `$`-containing password,
including a full deploy → backup → restore → still-serving round trip.

Also fixed along the way (found while actually testing, not assumed):
- Makefile never exported ENVIRONMENT, so `make up` alone (bypassing
  deploy.sh) would have left the new secrets path unresolved.
- deploy.sh chmod'd the secret files 600, unreadable by the container's
  own UID (www-data) — fixed to 644, relying on the containing directory
  (700) to keep other host users out instead.
- backup.sh/restore.sh still called `mysqldump`/`mysql`, which don't
  exist in the mariadb:11 image under those names — renamed to
  mariadb-dump/mariadb. (This means neither script had actually
  succeeded before now; both are verified working end-to-end here.)

The supplier/payment API keys remain passed the old way — nothing reads
them yet (bookstore-core is still a stub), so there's no live bug to fix
there; noted in .env.example that the same _FILE pattern should be used
once that code exists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:36:29 -04:00
twooeyandClaude Sonnet 5 cd48f85a47 Remove staging basic-auth wall — box is LAN-only
Staging runs on a private-network VM, not reachable from outside, so the
HTTP basic-auth layer was unnecessary defense-in-depth. Removing it also
lets the Caddyfile drop the render-around-Compose workaround entirely
(that workaround existed specifically because Compose's interpolation
mangles a bcrypt hash) — the noindex header and blog_public=0 stay, since
those guard against search-engine indexing, a separate concern from
network-level access.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:23:35 -04:00
twooeyandClaude Sonnet 5 b43852e733 Switch deploy pipeline to Gitea polling; fix env-parsing and volume-isolation bugs
- Replace the bare-repo post-receive hook with deploy/poll-deploy.sh: Gitea
  and the Docker hosts are separate machines, so each box polls its branch
  via host crontab instead of needing an exposed webhook receiver.
- Add Blocksy theme + Blocksy Companion auto-install to deploy.sh (free
  tier; the paid Book Store starter site still needs a manual license step).
- Fix deploy.sh/backup.sh/restore.sh sourcing .env files as bash: a bcrypt
  hash's `$2a$14$...` shape breaks under `set -u`. Replaced with
  deploy/lib/env.sh, a literal (non-executing) KEY=VALUE reader.
- Fix docker compose itself mangling the same kind of value: both
  `environment: ${VAR}` and `env_file:` run values through Compose's
  interpolation, which silently blanks `$identifier`-shaped substrings.
  The staging basic-auth hash is now rendered directly into the Caddyfile
  by deploy.sh, bypassing Compose's variable system entirely.
- Fix dev/staging/production silently sharing one Compose project (and
  therefore one db_data volume) by pinning an explicit -p per environment.
- cron and wordpress now share one environment anchor so they can't drift
  apart again (cron was silently missing WORDPRESS_CONFIG_EXTRA before).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 10:10:12 -04:00
twooeyandClaude Sonnet 5 c9d637c907 Week 1 infrastructure: Docker environments, deploy pipeline, bookstore-core scaffold
Docker Compose environments for dev/staging/production (MariaDB, Redis,
Caddy, Action Scheduler cron sidecar), an idempotent deploy script,
git-hook-based deploy pipeline, backup/restore scripts, and the
bookstore-core plugin stub with WooCommerce HPOS compatibility declared.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 09:50:18 -04:00