@wix/agent-skills 1.36.0 → 1.36.1

package/skills/wix-replatform/resources/rp-source-wordpress/lib/secret-value-guard.js

@@ -1,234 +0,0 @@
-'use strict';
-
-// The Node half of the secret-shaped value guard.
-//
-// There are two implementations of this guard and there have to be: this one runs on the
-// migration host (the gateway wrapper reads gateway configuration here, in
-// JavaScript), and the other runs inside the WordPress plugin, in PHP
-// (plugins/wix-wp-plugin-v2/includes/class-wmh2-secret-value-guard.php). PHP and Node share
-// no runtime, so "import the same module" is not available to them. What IS shared is one
-// canonical manifest, one restricted regex dialect, and one conformance corpus:
-//
-//   manifest  ../secret-value-patterns.v1.json, vendored from the canonical copy at
-//             plugins/wix-wp-plugin-v2/schemas/secret-value-patterns.v1.json
-//   corpus    tests/fixtures/secret-patterns/conformance.json
-//   dialect   anchors, character classes, alternation, quantifiers. NOTHING else --
-//             no lookaround, no backreferences, no named groups, no inline flags,
-//             no \p{...}, and no `~` (the PHP side's pattern delimiter).
-//
-// The dialect is not stylistic. It is the set of constructs that mean the SAME thing in
-// PCRE and in JavaScript, which is the only reason one pattern string can drive both
-// engines. assertRestrictedDialect() below is the machine-checkable statement of it, and
-// the contract test runs it over every manifest entry.
-//
-// CI verifies THIS side against the corpus. The PHP side has no interpreter in this
-// pipeline and is established by review against the same
-// corpus plus the live smoke. Said out loud because an unverified second implementation of
-// a security control reads as covered and is not.
-//
-// And the standing caveat, the same one the PHP file carries: this is DEFENCE IN DEPTH,
-// NOT A GUARANTEE. It is a pattern list; a secret in an unrecognized format passes
-// through. A credential that can be named in advance gets a deterministic denial instead
-// (the plugin's COLUMN_DENYLIST) and must never be left to this file.
-
-const fs = require('node:fs');
-const path = require('node:path');
-
-const REDACTED = '[REDACTED:secret-shaped]';
-
-// VENDORED INSIDE THE SKILL, deliberately. `skills/` is the published product and is
-// installed on its own, so anything under it that reaches up into the monorepo -- as this
-// once did, via ../../../../../plugins/wix-wp-plugin-v2/schemas/ -- resolves fine in this
-// repo and dies with ENOENT the moment a user installs the bundle. Caught by copying
-// the skill tree alone and calling the guard.
-//
-// The plugin's copy at plugins/wix-wp-plugin-v2/schemas/secret-value-patterns.v1.json stays
-// CANONICAL: the PHP evaluator reads it from
-// inside the plugin zip for the same no-network reason. So there are now three copies of one
-// file -- canonical, plugin zip, skill bundle -- and all three are asserted byte-identical
-// by tests/plugins/wmh2-eav-access-contract-test.js. Drift fails CI rather than producing
-// guards that disagree.
-const MANIFEST_PATH = path.join(__dirname, '..', 'secret-value-patterns.v1.json');
-
-// Constructs that do NOT survive the PCRE/JavaScript round trip, or that would break the
-// PHP side's `~` delimiter. Checked as source-text patterns because the point is to reject
-// the pattern STRING before either engine ever compiles it.
-const FORBIDDEN_DIALECT_CONSTRUCTS = [
-  { id: 'lookaround', test: /\((\?=|\?!|\?<=|\?<!)/, why: 'lookahead/lookbehind' },
-  { id: 'named-group', test: /\(\?</, why: 'named capture group' },
-  { id: 'inline-flags', test: /\(\?[a-zA-Z]*[-:)]/, why: 'inline flag / non-capturing modifier group' },
-  { id: 'unicode-property', test: /\\[pP]\{/, why: '\\p{...} unicode property' },
-  { id: 'backreference', test: /\\[1-9]/, why: 'backreference' },
-  { id: 'php-delimiter', test: /~/, why: '`~`, the PHP side\'s pattern delimiter' },
-];
-
-/**
- * Throws unless `regex` uses only constructs that mean the same thing in PCRE and in JS.
- * Returns the compiled RegExp so a caller cannot accidentally validate one string and
- * compile another.
- */
-function assertRestrictedDialect(regex, id) {
-  const label = id ? `denyPatterns[${id}]` : 'pattern';
-  if (typeof regex !== 'string' || regex === '') {
-    throw new Error(`${label}: regex must be a non-empty string`);
-  }
-  for (const construct of FORBIDDEN_DIALECT_CONSTRUCTS) {
-    if (construct.test.test(regex)) {
-      throw new Error(`${label}: ${construct.why} is outside the restricted dialect (${construct.id})`);
-    }
-  }
-  try {
-    // No flags, deliberately. `m` would change what `^`/`$` mean; `i` would change what
-    // the character classes mean; either would desynchronize the two engines.
-    return new RegExp(regex);
-  } catch (error) {
-    throw new Error(`${label}: not a valid regular expression (${error.message})`);
-  }
-}
-
-const MANIFEST_KEYS = ['schemaVersion', 'allowPrefixes', 'denyPrefixes', 'denyPatterns'];
-
-/**
- * STRICT, AND WHOLE-FILE: any defect THROWS, rather than dropping the bad entry and carrying
- * on with what is left.
- *
- * The lenient version of this function was a security hole and a quiet one. `Array.isArray(x)
- * ? x : []` turned a `denyPrefixes` corrupted to a string into a manifest with NO deny
- * prefixes; nothing threw, nothing reported a problem, and `whsec_...` came back unredacted
- * from a guard that looked healthy. Partial corruption is not a lesser problem than total
- * corruption — it is the same problem, harder to notice.
- */
-function loadManifest(manifestPath = MANIFEST_PATH) {
-  let raw;
-  try {
-    raw = JSON.parse(fs.readFileSync(manifestPath, 'utf8'));
-  } catch (error) {
-    throw new Error(`secret-value manifest at ${manifestPath} could not be read as JSON: ${error.message}`);
-  }
-  if (!raw || typeof raw !== 'object' || Array.isArray(raw)) {
-    throw new Error('secret-value manifest must be a JSON object');
-  }
-  const keys = Object.keys(raw).sort();
-  if (JSON.stringify(keys) !== JSON.stringify([...MANIFEST_KEYS].sort())) {
-    throw new Error(`secret-value manifest keys must be exactly: ${MANIFEST_KEYS.join(', ')} (got: ${keys.join(', ') || 'none'})`);
-  }
-  if (raw.schemaVersion !== 1) {
-    throw new Error(`secret-value manifest schemaVersion ${JSON.stringify(raw.schemaVersion)} is unsupported (this evaluator understands 1)`);
-  }
-  const stringList = (name) => {
-    const list = raw[name];
-    if (!Array.isArray(list) || list.length === 0) throw new Error(`secret-value manifest ${name} must be a non-empty array`);
-    for (const entry of list) {
-      if (typeof entry !== 'string' || entry === '') throw new Error(`secret-value manifest ${name} must contain only non-empty strings`);
-    }
-    return [...list];
-  };
-  const allowPrefixes = stringList('allowPrefixes');
-  const denyPrefixes = stringList('denyPrefixes');
-  if (!Array.isArray(raw.denyPatterns) || raw.denyPatterns.length === 0) {
-    throw new Error('secret-value manifest denyPatterns must be a non-empty array');
-  }
-  const denyPatterns = raw.denyPatterns.map((entry) => {
-    if (!entry || typeof entry !== 'object' || Array.isArray(entry)) throw new Error('every denyPatterns entry must be an object');
-    const entryKeys = Object.keys(entry).sort();
-    if (JSON.stringify(entryKeys) !== JSON.stringify(['id', 'regex'])) {
-      throw new Error(`every denyPatterns entry must have exactly id and regex (got: ${entryKeys.join(', ') || 'none'})`);
-    }
-    if (typeof entry.id !== 'string' || entry.id === '') throw new Error('denyPatterns id must be a non-empty string');
-    return { id: entry.id, regex: entry.regex, compiled: assertRestrictedDialect(entry.regex, entry.id) };
-  });
-  return { schemaVersion: raw.schemaVersion, allowPrefixes, denyPrefixes, denyPatterns };
-}
-
-let cachedManifest = null;
-let cachedError = null;
-function manifest() {
-  if (cachedError !== null) throw cachedError;
-  if (cachedManifest === null) {
-    try {
-      cachedManifest = loadManifest();
-    } catch (error) {
-      // Cached so the SECOND call fails identically to the first. A guard that throws once and
-      // then quietly succeeds is worse than one that consistently refuses.
-      cachedError = error;
-      throw error;
-    }
-  }
-  return cachedManifest;
-}
-
-/**
- * Is the guard operational? The Node counterpart of the plugin's `is_usable()`.
- *
- * Its absence was the actual leak: the PHP side
- * refused a read when its manifest was broken, while this side loaded an empty pattern set and
- * returned values unredacted. Two implementations of one control disagreeing about whether the
- * control is even running is the worst version of the two-runtime problem.
- *
- * Callers that must not proceed unguarded — the gateway wrapper above all — should
- * check this before reading, rather than relying on isSecretShaped() to throw mid-loop.
- */
-function isUsable() {
-  try {
-    manifest();
-    return true;
-  } catch {
-    return false;
-  }
-}
-
-/** Why the guard is unusable, or null when it is fine. */
-function unusableReason() {
-  try {
-    manifest();
-    return null;
-  } catch (error) {
-    return error.message;
-  }
-}
-
-/**
- * The verdict for one value, and the whole guard.
- *
- * ORDER IS THE RULE: allowPrefixes first, and as a PREFIX, never a substring. That
- * ordering is what keeps the payment pointers this effort exists to migrate intact — a
- * 44-character `card_...` id is precisely what the `long-opaque` pattern would otherwise
- * eat. Prefix-not-substring is also what stops the allow list becoming a bypass: a value
- * cannot smuggle `sk_live_...` through by containing `pm_` somewhere inside it.
- *
- * Non-strings are never secret-shaped. Coercing an integer column to a string to test it
- * would only invent false positives on long numeric ids.
- */
-function isSecretShaped(value, loaded = manifest()) {
-  // Note the default argument: a broken manifest THROWS here rather than reporting "not
-  // secret-shaped". Refusing loudly is the only safe answer a boolean-returning function can
-  // give when it cannot actually evaluate the question.
-  if (typeof value !== 'string' || value === '') return false;
-  for (const prefix of loaded.allowPrefixes) {
-    if (value.startsWith(prefix)) return false;
-  }
-  for (const prefix of loaded.denyPrefixes) {
-    if (value.startsWith(prefix)) return true;
-  }
-  for (const pattern of loaded.denyPatterns) {
-    if (pattern.compiled.test(value)) return true;
-  }
-  return false;
-}
-
-/** `[REDACTED:secret-shaped]` — never a hash, never a prefix, never the length. */
-function redact(value, loaded = manifest()) {
-  return isSecretShaped(value, loaded) ? REDACTED : value;
-}
-
-module.exports = {
-  REDACTED,
-  MANIFEST_PATH,
-  isUsable,
-  unusableReason,
-  FORBIDDEN_DIALECT_CONSTRUCTS,
-  assertRestrictedDialect,
-  loadManifest,
-  isSecretShaped,
-  redact,
-};

package/skills/wix-replatform/resources/rp-source-wordpress/lib/store-currency.js

@@ -1,101 +0,0 @@
-'use strict';
-
-// Where a WooCommerce store's currency actually comes from.
-//
-// The `currency` field on an order is documented as an ISO 4217 code, and on a stock store it is
-// one. It is not reliable: a store can return
-// `currency: "₪"` (an HTML-encoded currency SYMBOL) on every order, because a plugin or theme filter had
-// overridden the field. Passed through, that reaches the payment gate as a currency that matches
-// nothing, and every payment record is refused as a currency mismatch. Passed through without a
-// gate it would write amounts labelled with a symbol into the target.
-//
-// `/wc/v3/settings/general` -> `woocommerce_currency` is the store's own declared setting and is
-// the authoritative answer. It is one request per run, not one per order.
-//
-// The per-order field is still worth reading: a store CAN legitimately hold orders in more than
-// one currency (multi-currency plugins), and in that case the order's own value is the true one.
-// So the rule is: trust the order's value when it is a plausible ISO code, fall back to the
-// store's setting when it is not, and refuse when neither yields one. Never infer a code from a
-// symbol -- "$" is at least a dozen different currencies.
-
-const ISO_4217 = /^[A-Z]{3}$/;
-
-// The symbols worth recognising -- not to RESOLVE a currency from, but to notice when the store's
-// declared currency and the order's mangled field are talking about different money. A store set
-// to ILS whose order says "$" is not an ILS order with a broken field; it is an order this code
-// cannot read, and falling back would relabel dollars as shekels.
-//
-// Deliberately not a lookup table from symbol to code: "$" is USD, CAD, AUD, MXN, SGD and more,
-// and picking one silently misstates money. This maps a code to the symbols it may legitimately
-// appear as, and is used only to CORROBORATE a fallback, never to produce one.
-const SYMBOLS_BY_CODE = {
-  ILS: ['₪', '₪', '₪', 'NIS'],
-  USD: ['$', '$', 'US$'],
-  EUR: ['€', '€', '€'],
-  GBP: ['£', '£', '£'],
-  JPY: ['¥', '¥', '¥'],
-  AUD: ['$', 'A$', '$'],
-  CAD: ['$', 'C$', '$'],
-};
-
-function readStoreCurrency(generalSettings) {
-  if (!Array.isArray(generalSettings)) return null;
-  const setting = generalSettings.find((entry) => entry && entry.id === 'woocommerce_currency');
-  const value = setting && typeof setting.value === 'string' ? setting.value.trim().toUpperCase() : '';
-  return ISO_4217.test(value) ? value : null;
-}
-
-// Shape is not proof. `ABC`, `XXX` and `ZZZ` all match /^[A-Z]{3}$/ and none of them is money the
-// target can hold, so a code is accepted only if one of the two sides actually recognises it.
-function plausibleCode(code, known) {
-  if (!ISO_4217.test(code)) return false;
-  return known.length === 0 || known.includes(code);
-}
-
-// `knownCurrencies` is the set the source or target actually supports -- WooCommerce publishes one
-// at /wc/v3/data/currencies, and the target site declares its own. Pass it when you have it;
-// with none, shape is all that is left and the caller is told so.
-function resolveOrderCurrency(order, storeCurrency, { knownCurrencies = [] } = {}) {
-  const known = (knownCurrencies || []).map((c) => String(c).toUpperCase());
-  const declared = order && typeof order.currency === 'string' ? order.currency.trim() : '';
-  const upper = declared.toUpperCase();
-
-  if (ISO_4217.test(upper)) {
-    if (plausibleCode(upper, known)) return { currency: upper, source: 'order' };
-    return {
-      currency: null,
-      source: null,
-      finding: { code: 'order-currency-unknown', declared, note: 'shaped like a code but not one this store or target supports' },
-    };
-  }
-
-  // The order's field is not a code. Falling back to the store default is only safe when the
-  // mangled value does not CONTRADICT it -- otherwise a "$" order in an ILS store becomes ILS.
-  if (storeCurrency && ISO_4217.test(storeCurrency)) {
-    const expected = SYMBOLS_BY_CODE[storeCurrency] || [];
-    const agrees = declared.length === 0 || expected.some((symbol) => symbol.toUpperCase() === upper);
-    if (!agrees) {
-      return {
-        currency: null,
-        source: null,
-        // The important one. This is money, and the two sources of truth disagree.
-        finding: { code: 'order-currency-contradicts-store', declared, storeCurrency },
-      };
-    }
-    return {
-      currency: storeCurrency,
-      source: 'store-settings',
-      // Reported, not silent: a store that mangles this field is a store whose other
-      // currency-bearing fields are suspect too.
-      finding: { code: 'order-currency-not-iso', declared: declared || null, corroboratedBy: declared ? 'symbol-matches-store-currency' : 'field-empty' },
-    };
-  }
-
-  return {
-    currency: null,
-    source: null,
-    finding: { code: 'currency-unresolvable', declared: declared || null },
-  };
-}
-
-module.exports = { ISO_4217, SYMBOLS_BY_CODE, readStoreCurrency, resolveOrderCurrency };