Repository navigation
Add browser policy API before desktop adoption - #4481
reachjalil wants to merge 3 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 4 Skipped Deployments
|
There was a problem hiding this comment.
Warden security clearance: clear. No blocking findings (security or desktop↔den sync) in this diff (ce129ddb83f5b1ee989701642ee332c88d30c056). 1 advisory desktop↔den sync note(s) were posted as review comments; they do not affect clearance. Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
There was a problem hiding this comment.
Warden security clearance: clear. No blocking findings (security or desktop↔den sync) in this diff (119199ada22fcb8f88e7ae1f558659d2fe8753b6). 1 advisory desktop↔den sync note(s) were posted as review comments; they do not affect clearance. Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
Test evidence — an-administrator-provisions-browser-policy-through-the-api-while-existing-client — ✅ passed✅ passed · 5 expectations passed · 0 failed · 0 pending
verdict passed · 0 user observations · 0 probes · steps 0/0 ℹ️ ASSERTION — 1. The additive policy API defaults preserve existing browser accessThe member's existing desktop-config endpoint returned built-in browser access, an explicit unrestricted host policy, and login import disabled by default.
ℹ️ ASSERTION — 2. An administrator's browser grant reaches the member through the existing APIThe policy update persisted the explicit import grant and project.example allowlist. A separate member GET returned both effective values and preserved the existing built-in extension permission.
ℹ️ ASSERTION — 3. A member cannot change the organization's browser permissionsThe member's update returned HTTP 403. A subsequent member config read retained the administrator's import grant and host restriction.
ℹ️ ASSERTION — 4. Administrators can revoke import and explicitly clear a website restrictionUpdating the policy to deny import and clear the host list returned an effective false grant and explicit unrestricted hosts.
ℹ️ ASSERTION — 5. Existing clients can still update policy without sending the new fieldsAn update containing only the existing allowZenModel flag succeeded. That flag changed, the other existing flags retained their values, and the new fields used safe defaults without becoming required request fields.
Test run created 2026-09-05T04:28:26.199Z · Source: |
Deploying openwork with
|
| Latest commit: |
58c4a5c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f0473af7.openwork.pages.dev |
| Branch Preview URL: | https://feature-browser-policy-api.openwork.pages.dev |
There was a problem hiding this comment.
Warden security clearance: clear. No blocking findings (security or desktop↔den sync) in this diff (58c4a5c186d041662266e2eb7d403b595bcf515c). 1 advisory desktop↔den sync note(s) were posted as review comments; they do not affect clearance. Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
Status — Superseded as a browser-task prerequisite
The refreshed #4468 no longer consumes this proposed API. Merged #4564 already supplies server-owned execution.browserOrigins with exact-origin matching, intersected restrictions and upload enforcement. Restoring the older allowedBrowserHosts host/union semantics would create a conflicting policy system.
#4468 also removes the old one-time login importer. It uses direct sign-in in the built-in tab or the separately approved login-sync feature merged in #4452, preserving its native consent and managed-desktop restrictions. Therefore allowBrowserLoginImport is not required by the completed browser-task path.
Do not merge or deploy this stale API branch as a dependency of #4468. No replacement API or migration is required for that path. This PR remains open for the owner to decide its disposition; it has not been closed or otherwise changed beyond this status description.
Historical verification — not current readiness
The original API candidate at 119199a had five passed compatibility assertions. That evidence does not validate the newer conflicting branch against current dev and is not a current readiness claim. Its previously proposed API-first rollout plan is superseded by the integration decision above.