- Ya
- 9 Agosti 2026, 01:47 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 5bde69e
active_addon_codes was written straight from the request body. That was harmless while nothing read the column, but it is now an authorization input: an add-on bound to a ServiceType grants that app, and for the enterprise-negotiated origination modules it is the ONLY grant path, since they are deliberately excluded from every plan's feature matrix. So POST /accounts/{uid}/subscriptions with **************** saved an ACTIVE subscription carrying that code, and the next request resolved isOrgEntitledToApp(org, MLOS) true — unlocking the mortgage app and CommerceType.MORTGAGE on the free plan. CUSTOM-plan-only compatibility was enforced only by the order wizard's client-side filter, which this endpoint never consults. Turning fail-open false is what made this the one remaining way in. Codes are now resolved against the market-owning org's catalog and kept only when the add-on exists, is active, is compatible with the plan being bought, and — where it carries an app — that app is published. Unknown codes are dropped rather than rejected so a stale client cannot brick checkout, but they grant nothing. Not the whole fix: /api/billing/accounts/** still trusts a path-variable accountUid and a body-supplied targetOrganizationId with no rights check and no org scoping. That needs its own pass.