The extension injected the "Add as source" button on a Patreon creator you had not subscribed to, but it vanished 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 (documented in patreon_resolver._VANITY_RE): bare patreon.com/Atole, patreon.com/c/Atole, and patreon.com/cw/Atole — the "creator workspace" URL you land on once subscribed. The button's artist-page gate (PLATFORM_ARTIST_PATTERNS.patreon) and its byte-mirror probe pattern (_PLATFORM_PATTERNS in _derive) only matched the bare single-segment form and explicitly excluded c/. The ingestion resolver already handled all three — only these two gates were too narrow.
Fix
Both regexes now accept optional cw/ / 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 backend unit test covers all three prefixes, sub-paths, and nav-page rejection; JS + Python patterns validated identically on 14 cases.
Extension bumped 1.0.7 → 1.0.8 so a freshly-signed XPI ships the fix — which also exercises batch-5's web-ext-10 AMO sign path end-to-end on this main build.
CI green on dev head 69b5637: backend unit test (run 2246) + extension lint on v1.0.8 (run 2247).
## Symptom
The extension injected the "Add as source" button on a Patreon creator you had **not** subscribed to, but it vanished 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 (documented in `patreon_resolver._VANITY_RE`): bare `patreon.com/Atole`, `patreon.com/c/Atole`, and `patreon.com/cw/Atole` — the "creator workspace" URL you land on **once subscribed**. The button's artist-page gate (`PLATFORM_ARTIST_PATTERNS.patreon`) and its byte-mirror probe pattern (`_PLATFORM_PATTERNS` in `_derive`) only matched the bare single-segment form and explicitly excluded `c/`. The ingestion resolver already handled all three — only these two gates were too narrow.
## Fix
Both regexes now accept optional `cw/` / `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 backend unit test covers all three prefixes, sub-paths, and nav-page rejection; JS + Python patterns validated identically on 14 cases.
Extension bumped **1.0.7 → 1.0.8** so a freshly-signed XPI ships the fix — which also exercises batch-5's web-ext-10 AMO sign path end-to-end on this main build.
CI green on `dev` head `69b5637`: backend unit test (run 2246) + extension lint on v1.0.8 (run 2247).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01NsmJSQxnNxGgtM5Yz4GAqi
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>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Symptom
The extension injected the "Add as source" button on a Patreon creator you had not subscribed to, but it vanished 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 (documented in
patreon_resolver._VANITY_RE): barepatreon.com/Atole,patreon.com/c/Atole, andpatreon.com/cw/Atole— the "creator workspace" URL you land on once subscribed. The button's artist-page gate (PLATFORM_ARTIST_PATTERNS.patreon) and its byte-mirror probe pattern (_PLATFORM_PATTERNSin_derive) only matched the bare single-segment form and explicitly excludedc/. The ingestion resolver already handled all three — only these two gates were too narrow.Fix
Both regexes now accept optional
cw//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 backend unit test covers all three prefixes, sub-paths, and nav-page rejection; JS + Python patterns validated identically on 14 cases.Extension bumped 1.0.7 → 1.0.8 so a freshly-signed XPI ships the fix — which also exercises batch-5's web-ext-10 AMO sign path end-to-end on this main build.
CI green on
devhead69b5637: backend unit test (run 2246) + extension lint on v1.0.8 (run 2247).🤖 Generated with Claude Code
https://claude.ai/code/session_01NsmJSQxnNxGgtM5Yz4GAqi