15 Commits

Include renames

Author	SHA1	Message	Date
Claude	597b91d29b	refactor(extension): one definition of what ships in the XPI ... Milestone #271 step 1. Groundwork for deriving the extension version from git; no behavior change yet -- nothing consumes `version` so far. "Which files end up in the XPI" was stated in two places and about to become three. Three hand-kept copies of one fact is what allowed #2397, where the publish path could republish a stale XPI because its cache key had no link to the content it stood for. New extension/scripts/packaging.sh holds the single declaration and exposes: ignore web-ext --ignore-files values pathspec :(exclude)extension/... for git version <MAJOR.MINOR from manifest>.<commit count over packaged files> major-minor / patch Consumers now delegate instead of restating it: - extension/package.json -- all four web-ext scripts - .forgejo/workflows/ci.yml -- the extension-version guard's exclusions - (step 4) the rev-list that derives the version scripts/** joins the non-packaged set; the script must not ship to users. Two shell hazards, both load-bearing: The script runs `set -euf`. Its lists are iterated with deliberate word splitting, and without -f the shell ALSO globs them -- invoking `pathspec` from a directory where test/ exists (exactly how ci.yml calls it) would expand `test/**` into the individual spec files and silently stop covering anything added later. A caller's own `set -f` cannot prevent this: the script is a separate sh process and does not inherit it. Callers additionally need their own `set -f` for the substituted RESULT, which is a different expansion. version.spec.js asserts every --ignore-files caller sets it, that the pathspec comes through with `test/**` literal and no .spec.js paths, and that neither consumer has reinstated a hardcoded list -- the easy future regression is "simplifying" by inlining one again. Verified: all five subcommands plus the usage/exit-2 path. Derived version on main (8300029) is 1.0.19, matching dev. Last published is 1.0.10, so the eventual cutover moves strictly upward and needs no offset -- Firefox refuses downgrades. (An earlier note recorded 18; that was measured against a stale origin/main from before the PR #234 merge.) Refs #2398 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:33:11 -04:00
Claude	f9111c06a7	test(extension): unit suite for lib/ + version-consistency specs ... extension/ had no test harness at all -- web-ext lint was the only signal, so the URL-normalization fix in 8214afe shipped with nothing exercising it. Adds vitest (mirroring frontend/vitest.config.js) and three specs: - url.spec.js normalizeApiUrl / webRootFromApiUrl, including the #2393 regression: instance-root input must reach /api/credentials, idempotence, trailing-slash and whitespace handling, and that empty input never yields a bare "/api" (which isConfigured() would read as configured). - platforms.spec.js getPlatformFromUrl / isArtistPage, pinning the #1485 regression -- all three Patreon creator URL shapes (bare, /c/, /cw/) plus inner pages, with nav pages excluded -- and table-integrity checks. - version.spec.js manifest.json and package.json versions in lockstep, AMO-safe version format, and url.js ordered before api.js in background.scripts (classic scripts share one scope, so a reorder is a runtime ReferenceError with no build signal). Specs load lib/*.js by evaluating the real file as a classic script (test/helpers/loadLib.js) instead of adding module.exports shims to production code that would never run in the browser. The suite therefore exercises exactly the bytes packaged into the XPI. Two packaging consequences, both handled: - web-ext would otherwise bundle test/ and vitest.config.js INTO the XPI; both are now in --ignore-files across all four web-ext scripts. - ci.yml's extension-version guard must ignore the same paths, or editing a spec would demand a pointless version bump. The dangerous drift direction is the opposite one -- a guard exclusion for a file that DOES ship would let a real change pass unnoticed -- so version.spec.js asserts every :(exclude) in ci.yml appears in --ignore-files. extension.yml also triggers on ci.yml now, since version.spec.js reads it. Refs #2393, #2397 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 23:47:18 -04:00
Claude	8214afee1e	fix(extension): normalize FC URL so credential push doesn't 405 ... The stored apiUrl was required to already carry the `/api` suffix, since api.js builds requests as `${baseUrl}/credentials`. The options label read "FC base URL", so entering the instance root -- the natural reading -- sent every request one path segment short: POST /credentials hit the Vue SPA catch-all and came back 405, and GET /extension/manifest 404'd. Worse, Test Connection reported success on it: the catch-all answers GET /credentials with 200 HTML, so `r.ok` was true and the only affordance meant to catch this misconfiguration actively masked it. Normalize instead of validate (rules 92, 26): - New lib/url.js: normalizeApiUrl / webRootFromApiUrl, one source shared by the background client and the options page. Accepts either the instance root or the API root. - api.js normalizes on read, so configs already stored in the broken form heal themselves without the operator reopening Settings. - options.js stores the canonical form, echoes back what it saved, and the test now asserts a JSON content-type -- killing the false green. - 404/405 in request() now names the URL and points at the setting. - Options label/placeholder state that both forms work. Version 1.0.9 -> 1.0.10 in BOTH manifest.json and package.json; build.yml resolves the release version from package.json, and a stale value there would hit the cached ext-1.0.9 asset and republish the old XPI unsigned against the new code. Refs #2393 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 19:37:38 -04:00
bvandeusenandClaude Opus 4.8	d80a5255ed	feat(extension): in-app update prompt — popup banner + toolbar badge (#1489) ... The extension is installed per-instance from the operator's FC host, so Firefox's static update_url can't apply (each instance has a different host) and updates were fully manual. Add a self-hosted-friendly update surface that reuses the existing public GET /api/extension/manifest ({version, latest_url, sha256}): - lib/api.js: getExtensionManifest(). - background.js: checkForUpdateInfo() compares the instance's latest published version against runtime.getManifest().version (dotted-numeric compare so 1.0.10 > 1.0.9); CHECK_UPDATE message handler; refreshUpdateBadge() sets a toolbar badge via browser.action; a daily browser.alarms check plus on startup/installed. New 'alarms' permission (non-prompting). - popup: an 'Update available — vX' banner with an Update button that opens the signed XPI (web root, /api stripped like OPEN_ARTIST_PAGE) → Firefox's native install prompt. Never blocks the popup on a failed check. No backend changes (endpoint already exists). Bump 1.0.8→1.0.9 so this ships; from here on updates surface themselves instead of needing a manual reinstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 18:28:06 -04:00
bvandeusenandClaude Opus 4.8	69b5637bd6	fix(extension): show Add-to-FC button on subscribed Patreon creators (#1485) ... Symptom (operator-flagged): the extension injected the Add-as-source button on a Patreon creator you had NOT subscribed to, but it disappeared once you were subscribed — the opposite of when it's useful. Root cause (extension logic, not Patreon security): Patreon serves a creator under three URL shapes — bare patreon.com/Atole, patreon.com/c/Atole, and patreon.com/cw/Atole (the 'creator workspace' URL you land on once subscribed; documented in patreon_resolver._VANITY_RE). The button's artist-page gate (PLATFORM_ARTIST_PATTERNS.patreon in platforms.js) and its byte-mirror probe pattern (_PLATFORM_PATTERNS in extension_service._derive) only matched the bare single-segment form and explicitly excluded c/. So the subscribed-view URL failed the gate → no button. The ingestion resolver already handled all three; only these two gates were too narrow. Fix: both regexes now accept optional cw/ and c/ prefixes and drop the strict single-segment end-anchor, so a creator's inner page (/cw/Atole/posts, /Atole/membership) also matches — robust to whatever exact shape the subscribed view uses. Nav-page exclusions (home/search/messages/notifications/library/ settings/posts + post permalinks) preserved. New unit test covers all three prefixes, sub-paths, and nav-page rejection (both regexes validated identically). Bump extension 1.0.7→1.0.8 so a fresh signed XPI ships the fix (also exercises batch-5 web-ext-10's AMO sign path end-to-end on the main build). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 17:50:07 -04:00
bvandeusenandClaude Opus 4.8	51749e05db	chore(deps): update web-ext 8→10 (batch 5) (#1450) ... Renovate dep-dashboard batch 5. web-ext is the extension's build/lint/sign CLI (devDependency only; no extension source changes). Verified against the 8→10 changelog + FC's actual usage: - All CLI flags we use survive unchanged: --source-dir, --no-config-discovery, --ignore-files, --overwrite-dest (build), --channel/--api-key/--api-secret (sign). No removed/renamed flags for lint/build/sign. - v9's one breaking change (.js config files rejected) does NOT apply: we pass --no-config-discovery on every command and ship no config file. - Node: web-ext 10 baselines Node 22. The lint job runs on node:24-bookworm-slim; the load-bearing AMO sign job runs on ci-python:3.14 which installs Node 24 (CI-runner NODE_MAJOR=24) — both satisfy it. Sign is cache-skipped this push (extension version unchanged at 1.0.7) but is verified compatible for the next version bump. - The bundled addons-linter jumps to 10.1.0 — the extension.yml lint job (web-ext lint over the MV3 manifest) is the CI verifier for any new manifest findings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 16:30:11 -04:00
bvandeusen	d3245f0c22	feat(ext): verify cookies in-browser before uploading (1.0.7) ... Pre-upload verify request: after capturing the live browser cookies, hit a known authenticated endpoint with credentials:'include' from the extension's background context. If the platform reports we're not logged in, abort the upload so we don't overwrite FC-side credentials with stale data. - platforms.js: add `verify` config per cookie-auth platform - hentaifoundry: HEAD /?enterAgree=1 (mirrors gallery-dl's HF _init_site_filters; same 401 path the operator hit 2026-06-03) - patreon: GET /api/current_user (clean 401 when logged out) - subscribestar, deviantart: no stable auth endpoint, skip verify - cookies.js: verifyCookiesForPlatform() returns {ok, status, reason}. ok=true/false/null tri-state — null = verify not configured, caller treats as "proceed". - background.js EXPORT_COOKIES + EXPORT_ALL_COOKIES: verify gates the upload; failures bubble up with the platform's name + reason. - popup.js: success message now appends "(verified ✓)" when applicable. - manifest + package.json: 1.0.6 → 1.0.7.	2026-06-03 14:04:45 -04:00
bvandeusen	d65f0b2091	feat(extension): probe shows current state before click; v1.0.6 ... Operator-asked 2026-05-31 (during sidecar synthetic anchor cleanup): "the add source/subscription button idea to the firefox extension so it can tell me if a source/artist is added or not and offer an option to add it if it isn't." Plan tracked in Scribe task #507. ## Backend - `ExtensionService.probe(url)` — read-only resolution. Reuses `_derive` for platform+slug, then 2 SELECTs. Returns one of: - `source_match` (exact (artist, platform, url) Source exists) - `artist_match` (artist exists, this URL isn't a Source yet; collapses the sidecar-synthetic-only case from v26.06.01.0) - `new` (neither exists) - `unknown_platform` (URL didn't match any artist-page regex) - `GET /api/extension/probe?url=...` route with `X-Extension-Key` auth posture matching `/quick-add-source`. Read-only, side-effect free. - 6 backend tests in tests/test_api_extension.py covering each state + auth + invalid URL. ## Extension - `api.js`: `probeSource(url)` mirroring `quickAddSource` shape. - `background.js`: `PROBE_SOURCE` + `OPEN_ARTIST_PAGE` handlers. The latter strips the `/api` suffix from configured `apiUrl` (placeholder format per options.html) and opens `${base}/artist/{slug}` in a new tab via `browser.tabs.create`. - `content-script.js`: probe-first render — on page-load and SPA navigation, asks the backend for the URL's state and renders the chip in the matching color/copy on FIRST paint instead of flashing generic "Add" and updating after. Click handler branches: `source_match` → OPEN_ARTIST_PAGE; `artist_match`/`new` → existing ADD_AS_SOURCE flow (then re-probes so the chip flips green immediately, no wait for next nav). - `content-script.css`: three state-color modifiers (--new, --artist-match, --source-match) on the FC parchment-on-slate palette. Sage for already-added, amber for artist-exists, accent orange for new. ## Versioning - `extension/manifest.json` + `extension/package.json` → 1.0.6. build.yml's sign-extension job will fire on push to main since no `ext-1.0.6` Forgejo/Gitea release exists yet — exercises the regenerated AMO keys end-to-end. ## Behavior on the sidecar-synthetic case Filesystem-imported "Dymkens"-style artist with only a sidecar synthetic Source: probe returns `artist_match` (not `new`), so the chip reads "+ Add Patreon source to Dymkens" rather than offering to recreate the artist. Clicking adds the real Source; existing `_source_for_sidecar` preference logic (v26.06.01.0) routes future gallery-dl Posts to the real one.	2026-06-01 00:41:17 -04:00
bvandeusen	2394e47370	fix(hentaifoundry): inject host-only PHPSESSID/CSRF duplicates + extension preserves browser hostOnly ... Operator-flagged 2026-05-27: HF source check 401'd on `HEAD /?enterAgree=1` even with valid login cookies. Root cause is the combination of (1) gallery-dl's HF extractor checking `self.cookies.get("PHPSESSID", domain="www.hentai-foundry.com")` with `requests`' EXACT domain matching, and (2) the extension's cookies.js forcibly rewriting every captured cookie to a leading-dot subdomain-wide form. HF's PHPSESSID is browser-stored as host-only on `www.hentai-foundry.com`; the rewrite re-anchored it to `.hentai-foundry.com`, which `cookies.get(...)` no longer matches even though the cookie is still sent on actual HTTP requests (RFC 6265 subdomain rules). The extractor falls into its unauthenticated `?enterAgree=1` fallback, which 401s (Cloudflare or HF's anti-bot HEAD gating). Two-part fix, no operator action required for existing stored cookies: 1. **Backend** (`credential_service._augment_cookies`) — refactored from the subscribestar-only single function into a per-platform dispatcher. New `_augment_hentaifoundry` parses the materialized netscape file and, for each `.hentai-foundry.com` entry whose name is PHPSESSID or YII_CSRF_TOKEN, appends a host-only duplicate (`www.hentai-foundry.com\tFALSE\t...`). Originals preserved. Three new tests pin: injection fires + originals preserved; idempotent when host-only already exists; doesn't touch unrelated cookies (e.g. `_ga`). 2. **Extension** (`cookies.js`) — `toNetscapeFormat` now respects `c.hostOnly` from the browser instead of blindly forcing a leading-dot subdomain-wide form. Host-only cookies are written with the bare host + FALSE flag; non-host-only cookies retain the leading-dot + TRUE form. Forward-compat — fresh captures from v1.0.5+ no longer need the backend's host-only duplication. Extension bumped 1.0.4 → 1.0.5; manifest + package.json in lockstep. After deploy: the next HF source check on the operator's already-stored cookies will succeed because the materialized cookies.txt now contains host-only PHPSESSID. No browser re-export needed.	2026-05-27 19:12:51 -04:00
bvandeusenandClaude Opus 4.7	74dac6b960	fix(extension+migration): MV3 CSP opt-out from upgrade-insecure-requests (v1.0.4) + alembic 0023 drops the ck_tag_fandom_requires_character check before the type swap ... extension/manifest.json: add content_security_policy.extension_pages = "script-src 'self'; object-src 'self';" — explicitly omits the upgrade-insecure-requests directive that MV3 inherits by default. Without this, every fetch(http://curator.../...) silently upgrades to https:// at the browser layer (Sec-Fetch-Site=same-origin, NS_ERROR_GENERATE_FAILURE), regardless of about:config. Bump XPI version 1.0.3 → 1.0.4 so a fresh signed build replaces the cached one. Operator-troubleshot 2026-05-26 via Inspect-the-extension dev tools showing the silent scheme upgrade. alembic 0023: drop ck_tag_fandom_requires_character before the tag_kind type swap and recreate after. Postgres can't resolve `kind = 'character'` across the rename (column on tag_kind_old, literal binds to new tag_kind → "operator does not exist"). Same dance on downgrade. Banked under reference_tag_kind_enum_swap_check_drop. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-26 21:57:38 -04:00
bvandeusen	5587a76606	fix(ext-ci): replace jq with python3 (jq not in ci-python image) + bump ext 1.0.2→1.0.3 (escape AMO 'version already exists' from prior partial-failure run) + add rollback to prevent empty cache-release tombstones — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 23:14:11 -04:00
bvandeusen	17e19081a2	fix(ext-ci): drop web-ext-config.cjs (v8 mis-parses .cjs configs as if module.exports were a config option) — inline ignore-files on CLI + --no-config-discovery — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 22:46:58 -04:00
bvandeusen	c06cbc0abe	feat(ci): inline extension sign into build.yml + Forgejo Release Assets as XPI cache (v26.05.25.5) — bump ext to 1.0.2 — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 21:30:11 -04:00
bvandeusen	dc3bce7fc1	chore(ext): bump to 1.0.1 to trigger initial sign-and-publish — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 17:37:10 -04:00
bvandeusenandClaude Opus 4.7	a06c4f009f	fc3g(ext): bootstrap extension/ skeleton (manifest, package, icon, README) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:32:23 -04:00