Commit Graph
6 Commits
Author SHA1 Message Date
twooeyandClaude Sonnet 5 dcad1b7512 Product cover images via Open Library; Gutenberg literature filter; cron root fix
Cover sync (OpenLibraryAdapter + CoverSync + sync-covers command): fetches
a real cover from Open Library's free, keyless, explicitly-licensed-for-
this-use Covers API and attaches it as a genuine Media Library attachment
(not a hotlinked <img> — WooCommerce's shop loop/gallery/structured data
all need a real _thumbnail_id). ISBN-first, title/author-search fallback
via the confirmed cover_i field, matching the pattern already established
in HardcoverAdapter.

Two real bugs found and fixed while verifying this against the actual
catalog, not assumed:
- A Range-header HEAD-equivalent probe (added to avoid double-fetching)
  caused Open Library's server to redirect with a misleading content-type,
  producing a false positive on a known-fake ISBN. Removed — fetch once,
  verify the real bytes.
- Their search endpoint has genuine transient failures under repeated
  querying (same request, same input, failed then succeeded seconds
  later) — added retry-with-backoff on network errors/5xx, matching how
  the rest of this codebase already treats transient failures as
  retriable rather than fatal.

Also found chasing what looked like a third cover-sync bug, but wasn't
one: uploads/2026/08 was owned by root, silently blocking www-data-run
wp-cli from writing new files. Root cause was a gap in the earlier
root-hardening pass (docker-compose.yml, Commands.php) — it fixed our own
deploy.sh/backup.sh/Makefile invocations but missed the cron sidecar's
own internal process, which was still running its wp-cli loop as root via
a leftover --allow-root. Fixed at the container level (`user: www-data`
on the cron service) since it's a plain shell loop with none of
php-fpm's master-process-needs-root-to-drop-privileges concern.

Gutenberg importer: filters to actual literature via LoCC (Library of
Congress Classification) — verified directly against the real catalog
that novels consistently get a P* code while government documents/
speeches/law get E/JK/KF/DA and never a P code. Removes the Declaration
of Independence, Bill of Rights, etc. from what was importing as "books."

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 14:48:40 -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 f65581bc50 Permanently eliminate the "$X variable not set" warning, and fix Caddy auto-HTTPS on private IPs
Two separate leaks were causing the same cosmetic-but-annoying warning to
survive every previous fix attempt:

1. Compose's own `secrets:` block reads the referenced file's *content*
   as part of its config model, and applies the same interpolation
   warning to it — even with DB_PASSWORD fully removed from every ${VAR}
   and --env-file path. Switched from Compose's native `secrets:` to plain
   bind mounts at the same /run/secrets/* paths: a bind mount only ever
   touches the file's path, never its content, so it's immune. (Verified
   this precisely with an isolated repro before rolling it out — the two
   mechanisms behave differently even though they look equivalent.)

2. caddy's `env_file: .env.staging` (a leftover from the since-removed
   basic-auth setup) loaded the *raw*, unfiltered env file directly,
   bypassing deploy.sh/backup.sh/restore.sh's filtered-copy mechanism
   entirely. Caddy only ever needed SITE_DOMAIN; switched to passing that
   one value directly instead of the whole file.

Also fixed Caddyfile.staging: the site address had no explicit scheme, so
Caddy's automatic-HTTPS logic still applied to a private IP (registering
its own internal CA and redirecting HTTP->HTTPS) — not the "plain HTTP
only" behavior I'd assumed and told the user earlier. Prefixed with
`http://` to genuinely disable automatic HTTPS for this LAN-only box.

Verified end-to-end: fresh deploy with dollar-sign DB passwords produces
zero warnings, serves HTTP 200 on plain http:// with no redirect, and the
DB connection genuinely authenticates.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:59:36 -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