• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

stacklok / toolhive / 30293642581 / 1
70%
main: 70%

Build:
DEFAULT BRANCH: main
Ran 27 Jul 2026 06:33PM UTC
Files 841
Run time 32s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

27 Jul 2026 06:24PM UTC coverage: 69.677% (+0.07%) from 69.609%
30293642581.1

push

github

web-flow
Fix contradictory upstream ID token exp contract (#6036)

Follow-up to #6022, addressing the three non-blocking points raised in its
approval. Comments and docs only; no logic changes.

The exp contract on stored ID tokens said callers MUST check `exp` before use,
but #6022 made the Cedar authorizer a consumer that deliberately does not: it
reads login-time identity claims rather than presenting a credential, and
rejecting an expired token would flip a policy from permit to deny mid-session.
Four sites stated the strict rule, and the strictest was UpstreamCredential —
the doc the other three tell readers to consult, so following a cross-reference
landed on the version contradicting where you came from. All four now
distinguish presenting the token from reading its claims.

The TODO in upstreamtoken/service.go asserted that exp enforcement belonged at
the RFC 8693 consumer. That work does not exist: for claims-readers enforcement
is affirmatively unwanted, and for the credential path the obliged party is the
recipient IdP, so a presenter's local pre-check is a latency and error-message
optimisation rather than a security control — skipping it cannot cause an
expired assertion to be accepted. Replaced with a statement of that design,
including what a future consumer presenting to a non-validating sink must do,
since "neither consumer" is only true as a census of today's two readers.

Stop spelling the Cedar profile-claim names with the auth server's constants.
What this code reads is an upstream provider's id_token, where `name` and
`email` are OIDC Core 5.1 wire names fixed by the spec, so anchoring them to a
ToolHive constant inverted the dependency: renaming that constant would have
changed which claim Cedar reads out of a third party's token. The comment also
promised that a rename on either side would be a compile error, which was never
true — upstream/oidc.go extracts these claims by hardcoded json tags, not via
those constants, so the extraction ... (continued)

80678 of 115789 relevant lines covered (69.68%)

86.93 hits per line

Source Files on job 30293642581.1
  • Tree
  • List 841
  • Changed 14
  • Source Changed 3
  • Coverage Changed 14
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 30293642581
  • 82319240 on github
  • Prev Job for on main (#30292044720.1)
  • Next Job for on main (#30295039973.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc