Skip to content

Commit f31ea1c

Browse files
os-samclaude
andauthored
docs(platform-objects): re-measure the two better-auth 1.6.11 stamps outside #10188's plugin-auth carrier (#11468)
Both sites stamp the same upstream-gap claim as #10188's plugin-auth site 1 (the stock /admin/oauth2/update-client endpoint's Zod body schema does not accept `disabled`). Nothing was broken: both claims are still TRUE, only the stamps (and, for site 1, the anchor) were stale. Re-measured 2026-08-23 against installed @better-auth/oauth-provider@1.7.1, independently of #10188/#11446's own re-measurement. Fixes #11362 Claude-Session: https://claude.ai/code/session_01APWX2AwT3a4xDcjPCe8bk4 Co-authored-by: Claude <noreply@anthropic.com>
1 parent 905019b commit f31ea1c

2 files changed

Lines changed: 18 additions & 11 deletions

File tree

packages/platform-objects/src/identity/sys-oauth-application.object.ts

Lines changed: 12 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -46,14 +46,19 @@ export const SysOauthApplication = ObjectSchema.create({
4646
// is intentionally dropped from `apiMethods` below so the only delete
4747
// path is the better-auth wrapper.
4848
//
49-
// Upstream gap (better-auth 1.6.11): the stock `/admin/oauth2/update-client`
50-
// endpoint's Zod body schema does NOT accept the `disabled` flag, even
51-
// though the column exists and the runtime honours it. We bridge the
52-
// gap with `POST /api/v1/auth/admin/oauth2/toggle-disabled`, registered
53-
// by plugin-auth, which writes through better-auth's own adapter under
49+
// Upstream gap (re-measured 2026-08-23 against the installed
50+
// @better-auth/oauth-provider@1.7.1): `adminUpdateOAuthClient`
51+
// (`dist/authorize-Crqw4_bR.mjs:2860`) declares the stock
52+
// `/admin/oauth2/update-client` endpoint's Zod body schema at
53+
// `:2862-2889`, and `disabled` occurs zero times in that block — while
54+
// matching 35 other lines of the same file (`grep -c`), so the search
55+
// reaches the text. The column exists and the runtime honours it, but
56+
// no client-facing API can flip it there. We bridge the gap with
57+
// `POST /api/v1/auth/admin/oauth2/toggle-disabled`, registered by
58+
// plugin-auth, which writes through better-auth's own adapter under
5459
// the auth namespace (no generic data-layer bypass). When upstream
55-
// ships `disabled` support, retarget the enable/disable actions and
56-
// delete the bridge route.
60+
// adds `disabled` to `adminUpdateOAuthClient`'s schema, retarget the
61+
// enable/disable actions and delete the bridge route.
5762
//
5863
// The two toggle predicates are guarded for the SPARSE action face (#8990),
5964
// and this pair is where the guard actually changes what a user sees. Both

packages/platform-objects/src/platform-objects.test.ts

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -182,10 +182,12 @@ describe('@objectstack/platform-objects', () => {
182182
expect(del?.mode).toBe('delete');
183183

184184
// Enable/disable both hit the ObjectStack-added bridge route on
185-
// /api/v1/auth (since better-auth 1.6.11's stock admin endpoint
186-
// does not accept `disabled` in its update schema). They differ
187-
// only in the static `disabled` body field and the visibility
188-
// predicate, so exactly one is active at any time.
185+
// /api/v1/auth. Re-measured 2026-08-23 against the installed
186+
// @better-auth/oauth-provider@1.7.1: the stock admin endpoint's Zod
187+
// body schema (`dist/authorize-Crqw4_bR.mjs:2862-2889`) still does
188+
// not accept `disabled`, so the bridge route stays warranted. They
189+
// differ only in the static `disabled` body field and the
190+
// visibility predicate, so exactly one is active at any time.
189191
expect(disable?.target).toBe('/api/v1/auth/admin/oauth2/toggle-disabled');
190192
expect(disable?.bodyExtra).toEqual({ disabled: true });
191193
expect((disable?.visible as any)?.source).toBe('(has(record.disabled) && record.disabled != true) && features.oidcProvider != false');

0 commit comments

Comments
 (0)