Repository navigation
auth: admit schedule authoring for tokens once schedules carry the creating credential's limits - #3815
auth: admit schedule authoring for tokens once schedules carry the creating credential's limits#3815ptone wants to merge 4 commits into
Conversation
ptone
commented
Oct 17, 2026
ptone
commented
- A user access token may create a scheduled event or recurring schedule with scheduled_event:create, and update or resume a schedule with scheduled_event:update, on a project or hub boundary that contains the project. The token's user still needs live authority in the project.
- The event type's target checks still apply: a message needs agent:message on a target the token can read, and a dispatch_agent run needs agent:create. A resume re-checks the stored target with the resuming token.
- Each admitted revision records the token's attribution and its frozen ceiling and boundary. A fire runs under the recorded ceiling and the boundary of the recorded token.
- A credential kind outside the authoring allowlist gets a plain 403.
- The four scheduler fire entry points are catalogued as non-user.
- The schedule update row's catalog metadata is reconciled with hub: schedule update grant semantics in the catalog, store delete caller guard #3783 when either lands.
A user access token may create a scheduled event or schedule with scheduled_event:create, and update or resume a schedule with scheduled_event:update, on a boundary that contains the project. The event type's target checks still apply, and the revision records the token's ceiling and boundary, which bound each fire. Other credential kinds outside the authoring allowlist get a plain 403. The scheduler fire entry points are catalogued as non-user and pinned by tests that fire token-authored events.
A scoped identity built with an empty project ID has an invalid project boundary, not a hub boundary. The hub-scoped schedule authoring cases now use a token identity on the hub boundary with a frozen ceiling of exactly their selectors.
A hub token holding the schedule authoring selectors is refused on create and resume when its user holds no authority in the project. A token-authored event whose recorded credential is a project token for another project fails at fire: no child is created and nothing is delivered. The schedule authoring credential check drops a nil test the identity helper covers, and the update test's token loop uses its own names.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request enables User Access Tokens (UATs) to create, update, and resume scheduled events and recurring schedules, provided they carry the appropriate scopes (scheduled_event:create or scheduled_event:update) and pass target checks. Previously, UATs were unconditionally blocked by a session-only gate for these operations. The changes update the authorization catalog, permission registry, and route handlers to support UATs, ensuring that when an event or schedule is authored via a token, its bounded ceiling and boundary are recorded and enforced when the event fires. A new operation schedule.event.fire is introduced to handle the execution of scheduled events under the recorded authority. Extensive test suites have been updated and added to validate these token-based scheduling capabilities. I have no feedback to provide.
This branch has not been deployed
1 participant
