[tracking202]

Stacked on #268 (PayKickstart IPN, branch 1.9.79-paykickstart-ipn): review and merge this after #268. Until #268 merges, this diff includes #268's commits. #268 is merged in at 8532b44, and with it 1.9.79 (#262, #270, #280, #281, #282), each by a merge commit. This PR's own commits are 5ec4eda, e1f2d2b and b2c115f, plus the merge resolutions. See them alone with git diff origin/1.9.79-paykickstart-ipn...1.9.79-clickbank-per-account. #288 (851K: rebills, refunds, chargebacks) is stacked on this PR.

Backlog: 7PJV ("ClickBank notifications only work for the first account")

What was wrong

• Account 1 only. tracking202/static/cb202.php read cb_key and user_slack_incoming_webhook from account 1 (lines 7 and 10). No other account could use ClickBank INS.
• The wrong cipher, for every account. cb202.php decrypted with AES-128-CBC. ClickBank's INS article says notifications are encrypted with CBC-AES-256. Its PHP sample calls openssl_decrypt(…, 'AES-256-CBC', substr(sha1($secretKey), 0, 32), OPENSSL_RAW_DATA, …), and its Python sample's 32-byte key is AES-256 too. AES-128 reads only 16 of the derived key's 32 bytes.
  • Executed. The openssl command line encrypted a sale as the article says. Python's cryptography, keyed as ClickBank's Python sample, decrypts that ciphertext. The old cb202.php answers it 400 Unable to decrypt notification. It accepted only the AES-128 that its own tests (PostbackHandlerTest, legacy-pixels.sh) encrypted with: a mirror of the code, not of ClickBank (CLAUDE.md Update release notes in README #9).
  • Consequence. No notification encrypted as ClickBank documents it could have decrypted, for account 1 either. Nothing ClickBank actually sent was available here to confirm this.
• A padding oracle. A ciphertext that failed to decrypt answered 400 Unable to decrypt notification. One that decrypted to something other than an order answered 400 Malformed order payload. That difference is the condition a padding-oracle attack needs. It was not demonstrated end to end.

What changed

cb202.php is now #268's Receiver, with a ClickBank adapter.

Decryption: ClickBankCipher. It decrypts as ClickBank's samples do:

• AES-256-CBC, keyed with the first 32 hex digits of SHA-1(secret) taken as text;
• trailing control bytes trimmed;
• the result must be a JSON object that names its transactionType.

Invalid UTF-8 is substituted rather than refused, because 7.0 is the first version to say it sends UTF-8.

Finding the account: ClickBankAdapter.

• Every account's stored cb_key is tried, with surrounding whitespace trimmed. The account is the one whose key decrypts the notification (CLAUDE.md [Maintenance] Remove deprecated PHP features #16).
• A key two accounts store is refused, as the brief asks. The outcome is ambiguous_account (409). The log names the accounts; the answer does not.
• A ciphertext that decrypts to something that is not an order answers exactly as a wrong key does (403). There is no padding oracle.
• The envelope is checked before any key is tried:
  • A legacy cverify form (version 4.0 and earlier) is a 415 that says to choose 8.0.
  • Anything else that is not {"notification","iv"} with base64 of whole AES blocks and a 16-byte IV is a 400.

Reading the order.

• SALE records a conversion under its receipt at totalAccountAmount, through 1.9.79: PayKickstart's product IPN, verified with each campaign's key #268's Processor (ledger source clickbank, pixel type 2). The amount is read exactly, whether 8.0 sends it as a string or 7.0 as a number.
• Currency. The amount is stated as USD ("Total you received for the transaction in USD", in 6.0, 7.0 and 8.0). An account that counts in another currency gets the Processor's 422.
• The click is the first tracking code (tid=[[subid]] on the HopLink). When there is none, it is 8.0's affiliateTrackingParameters.extclid.
  • A value that is not a click id is a 400 naming it.
  • No click at all is 200 no_click, worded for a HopLink.
• When it happened. transactionTime is read with the offset it carries and sets Notification::$occurredAt, which 1.9.79: PayKickstart's product IPN, verified with each campaign's key #268's Processor dates the row by (held at the click when earlier, at arrival when later).
  • Accepted forms: RFC 3339 as 6.0 and 8.0 send it (2023-10-05T13:47:51-06:00), and ISO 8601's basic form as 7.0's notes describe (20200819T144359-0700).
  • A time that is neither, or that names no real moment (a 13th month, hour 24, beyond a conv_time), is a 400 naming transactionTime.
  • No time at all is dated on arrival, as before.
• TEST marks that account's cb_verified, through a new optional interface, ConfirmsTestNotifications. A failure answers 500, so ClickBank's Test URL shows it. cb202.php then posts cb_key_verified to that account's own Slack webhook, after the answer.
• Every other type is acknowledged, as before. 1.9.79: ClickBank rebills are recorded, and refunds and chargebacks take a sale back #288 handles them.

#268's adapter contract, as 1YEB listed it:

• signatureField() answers encryption. INS 6.0 and later are encrypted, not signed: no field carries a signature, and the ciphertext arrives in notification. The method names what failed to verify in the 403, so encryption makes the answer read "The notification's encryption does not verify with any ClickBank secret key stored in Prosper202". notification would read "The notification's notification". The legacy versions, which did sign with cverify, are refused before any key is tried.
• $occurredAt is set as above.
• ServedPreferences::SECRET needs no change. ClickBank's per-account secrets are cb_key and the Slack webhook (user_slack_incoming_webhook), and 1.9.79: GET /users/{id}/preferences serves no integration secret #270 already lists both. cb_verified is a flag and is on SERVED.

Shared code, kept out of the other adapters' way:

• InboundRequest carries the raw body.
• The Processor's test and ignored outcomes name the account when one verified.
• OutcomeKind::AMBIGUOUS_ACCOUNT is new (409).

The page. The ClickBank panel says to put tid=[[subid]] on the HopLink, and asks for OpenSSL alone.

Docs and changelogs. There is a ClickBank section in documentation/tutorials-and-guides/09-3rd-party-integrations.md, with setup steps, an outcome table and dating. changelogs.txt and changelogs.json have entries after 1.9.79's own.

ClickBank's spec: what was verified and what was not

Read from support.clickbank.com, "Instant Notification Service (INS)" (article 10535147) and the related articles.

• Verified against the article:
  • Versions. 8.0 is current; 7.0 is recommended; 6.0 is the first encrypted one; 1, 2, 2.1 and 4 are legacy cverify form posts.
  • The encryption and the envelope, as above.
  • The fields used: transactionType, receipt (8 to 21 characters), totalAccountAmount (USD; a number in the 7.0 example, a string in the 8.0 one), trackingCodes, affiliateTrackingParameters.extclid, and transactionTime (RFC 3339 in the 6.0 table and the 8.0 example; 7.0's notes say ISO 8601 basic).
  • TEST carries the receipt ********.
  • Delivery. Any non-2xx is retried every 4 hours, at most 5 times, and a 2xx is expected within 3 seconds.
  • The secret key is "up to 16 characters, including numbers and capital letters".
• Not verified:
  • No notification actually sent by ClickBank was available.
  • PKCS#7 padding is inferred from the official sample's openssl_decrypt call.
  • Whether an affiliate's INS receipt is ever masked (ClickBank's reporting pages mask it).
  • Whether tid is what fills trackingCodes.

Decisions a reviewer should check

1. A shared key is refused, not decided by the click. A ClickBank key is a whole ClickBank account's, and a TEST could not say whose key to mark verified.
2. The stored keys of deleted or deactivated accounts still count, as in 1.9.79: PayKickstart's product IPN, verified with each campaign's key #268 and JVZoo.
3. USD. A notification for an account whose currency is not USD is now a 422.
4. Where this differs from JVZoo (1.9.79: JVZoo's JVZIPN at jvzoo.php, for affiliates and vendors (stacked on #268) #272): unknown fields are not refused. JVZoo refuses them because its signature joins values without their names. ClickBank's order is encrypted whole, and its fields grow by version (8.0 added affiliateTrackingParameters and commonTrackingParameters).
5. The extclid fallback is new behaviour. A tracking code, when there is one, always decides.
6. signatureField() is encryption (above).

Verification

Scope report of .claude/skills/p202-verify/scripts/verify.sh --since origin/1.9.79 --changed on b2c115f (PHP 8.3.6, MariaDB 10.11, full vendor/). The schema tier had a scratch database, and the live instance's 202-config.php was moved aside. Unit tier: 6167 tests, 4 skipped (the documented User DB-singleton skips). Verbatim:

Scope report
------------
  go         PASS  ran under CI's go1.25.14 via GOTOOLCHAIN (local go is 1.24)
  golangci   PASS  ran under CI's go1.25.14 via GOTOOLCHAIN (local go is 1.24)
  openapi    PASS
  patterns   PASS
  phpcs      PASS
  phpstan    PASS
  schema     PASS
  syntax     PASS
  unit       PASS

Not covered by this script:
  live      stand up an instance, drive the path a user would take
  agent     add and run a case under tests/fixtures/agent-eval/cases/
  ci        a workflow still in_progress has not passed; read the run

Integration suites, each alone on a database created for it:

Suite	Tests
ClickBankInsIntegrationTest	12 OK
PayKickstartIpnIntegrationTest (the shared Processor)	20 OK
LegacyPostbackCampaignIntegrationTest	5 OK
ConversionBridgeIntegrationTest	5 OK
ConversionLedgerIntegrationTest	26 OK

Planted defects: 15 of 15 caught for the adapter (listed in the first version of this description), and the time-reading plants in #288's run (a time read without its offset, a 13th month read as January, a sale not dated, an unreadable time read as none), each caught by a named test.

Live pass, tests/live/clickbank-ins.sh, on the merged tree: 41 passed, 0 failed. Notifications are encrypted by the openssl command line and posted with curl to an instance with two accounts:

• each account's SALE is recorded under its own account;
• either account's key on the other's click is a 404;
• account 2's TEST makes account 2's GET /system/integrations read verified: true, and account 1's false;
• a replay is a duplicate; another amount is a 409;
• a stranger's key and the old AES-128 ciphertext are 403;
• no tracking code is 200 no_click; 42.9 is 400;
• a legacy form is 415; a GET is 405;
• a key two accounts store is 409, and records once it is one account's again;
• a sale stating its time in -06:00 is stored with that conv_time; a 13th month is a 400;
• the log has one line per notification, with no key and no buyer detail.

Before and after. Against the old cb202.php, 9 of the first 37 checks passed. tests/live/legacy-pixels.sh: 61 passed (before the latest merge).

Could not run

• The installer's licence step. The licence stub at my.tracking202.com is down. The instance was installed by running what 202-config/install.php does after its licence check: INSTALL::install_databases(), InstallAccount::create(), a REST key in 202_api_keys, and the partitions. Then php -S was started with the CI router, as install-instance.sh does. Skipped: the licence check itself, and the AutoCron and daily-email registrations. The API, dl.php and cb202.php were driven directly.
• CI has not been observed on this head.
• A real ClickBank notification was not available.
• The full integration-suite set was not run. The run was on MariaDB 10.11; CI runs MySQL 8.0.
• No browser pass for the panel's text change.
• No agent-eval case. This is not an agent-facing change.

Found outside this item

• The other pages that read account 1's Slack webhook are 974K, and were left alone.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VRoS2SViuxaucFaKWsFnLr

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-23T22:32:30.442407Z We couldn’t complete this review. Comment @codex review to try again.	5ec4eda	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[github-actions]

Adversarial review: BLOCKING

For fcd6019: 5 finding(s). The report is encrypted for the maintainers in the review-findings artifact of this run.

Rewritten on every push; the check fails on BLOCKING.

[tracking202]

The adversarial review marks fcd6019 BLOCKING (5 findings), so the check is red. Its report is encrypted for maintainers, so I can't see which finding blocks.

The previous head, 0869d72, came back NON-BLOCKING with 4 findings. The only change since then is the deleted-account key fix (merged from #268, plus fcd6019):

• A new shared AccountSecrets::stored() joins 202_users, so a deleted account's stored key verifies nothing.
• ClickBank's and PayKickstart's storedSecrets() now read through it.

I read that delta and found no defect. The column name is checked against ^[a-z][a-z0-9_]*$ before it goes into the SQL. The join leaves out only deleted accounts (user_deleted = 0), so switched-off accounts still verify. Each adapter's key handling is unchanged. #272 got the same change for JVZoo and is NON-BLOCKING.

That still doesn't rule out a real finding elsewhere in this PR; #288's BLOCKING turned out to be one. A self-review of this PR's ClickBank code is under way, covering the cipher, the account decision, the TEST path and the logs. Any real defect will be fixed here with a test that fails without the fix, and merged up into #288 and #319. I'll report the result on this thread.

If a maintainer can share the blocking finding's title, I can go straight to it.

---

Generated by Claude Code

[tracking202]

The self-review of fcd6019 is done: no blocking defect found, so nothing is pushed. Everything below was measured on a live instance, not read.

• Deleted-account change, through the real DELETE /api/v3/users/{id} path. A sale under a key that a now-deleted account also stored went from 409 to 200 recorded. A re-created account storing the same key gets 409, and the log names the live accounts, not the deleted one.
• Padding oracle. Good padding, bad padding, a non-order JSON and an unknown key all get byte-identical answers (403, same body). Loopback medians over 1,500 requests each fall within 0.03 ms of one another, against a 0.6 ms spread.
• Ownership, logs, content type. Neither account's key records on the other's click. No key, buyer detail or line break reaches the log. The body is read whether it comes form-encoded or as text/plain.
• Tests. ClickBank integration 13/13, PayKickstart integration 21/21 and tests/live/clickbank-ins.sh 41/41 on this head. Removing the user_deleted filter or the shared lookup fails named tests.

Two real but non-blocking points, both already present on 0869d72 (NON-BLOCKING):

1. Merge order. On this PR alone, RFND, CGBK, INSF and BILL answer 200 ignored, as documented here. ClickBank does not resend after a 2xx, so a refund that arrives while only this PR is deployed is lost. 1.9.79: ClickBank rebills are recorded, and refunds and chargebacks take a sale back #288 fixes that (an RFND there writes the reversal; measured). Please don't release 1.9.79: ClickBank's INS works for every account, decrypted with each account's own key #276 without 1.9.79: ClickBank rebills are recorded, and refunds and chargebacks take a sale back #288.
2. TEST answer on servers without PHP-FPM. The answer waits for the Slack post: fastcgi_finish_request() exists only under FPM, and the shared Slack.class.php sets no curl timeout. The old cb202 posted before answering on every server, so this PR is still an improvement. The root cause is filed separately.

Two reviews of code that contains this PR in full, #288 (5e7e990) and #319 (d537116), came back NON-BLOCKING. Together with the above, the BLOCKING mark on this head looks like reviewer variance. If a maintainer can share the blocking finding, I'll address it directly.

---

Generated by Claude Code