@wix/agent-skills 1.33.0 → 1.34.0

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

@@ -0,0 +1,234 @@
+'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

@@ -0,0 +1,101 @@
+'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 };