Add DELETE /api/v1/trusted_publishing/tokens API endpoint
#11234
Conversation
Turbo87
added
C-enhancement ✨
|
Would you be willing to also add some regression tests? Specifically around cross-crate and user manipulation. This could probably apply to some of the other endpoints as well. Id feel better just covering any future errors. |
|
absolutely, but could you be slightly more specific on the exact scenarios you would like to see tested? :) |
This fn can be used to decode a JSON web token without verifying it's signature or claims. Only the `iss` claim will actually be decoded, since we use that to find the correct decoding key for the JWT issuer.
This defaults to the domain name (crates.io / staging.crates.io) and controls the expected `aud` claim of the OIDC JWT in the Trusted Publishing token exchange.
…lishing providers
This makes it possible to construct `MockTokenUser` instances from an existing plaintext token or other random header value.
| // If we're in a cooldown from a previous refresh, return | ||
| // whatever is in the cache. | ||
| return Ok(cache.keys.get(key_id).cloned()); |
There was a problem hiding this comment.
Practically, it seems unlikely that the cache will now contain key_id, since we just did a check a moment ago under a read lock. (Obviously, in theory another task could acquire the write lock and refresh between releasing the read lock and acquiring the write lock, but that feels unlikely in practice.)
I'm not sure the behaviour should change, but I think the comment maybe should:
| // If we're in a cooldown from a previous refresh, return | |
| // whatever is in the cache. | |
| return Ok(cache.keys.get(key_id).cloned()); | |
| // If we're in a cooldown from a previous refresh, return | |
| // whatever is in the cache, which will probably be None | |
| // given the previous check under the read lock. | |
| return Ok(cache.keys.get(key_id).cloned()); |
| if let Some(key_id) = &key.common.key_id { | ||
| let decoding_key = DecodingKey::from_jwk(&key)?; | ||
| cache.keys.insert(key_id.clone(), decoding_key); | ||
| } |
There was a problem hiding this comment.
kid is technically optional in JWKs. Given that we're requiring a key ID in any actual requests this is fine in practice, but I wonder if we should warn if we see a key that doesn't have an ID, since that may indicate future problems with that provider.
This PR adds an endpoint to revoke a temporary access token from the Trusted Publishing flow.
The
DELETE /api/v1/trusted_publishing/tokensendpoint expects the token to be handed over in theAuthorizationheader as aBearertoken, similar to how it will be used in the publish endpoint.This PR is based upon (and currently includes the changes of) #11131, which implements the API endpoint to create a temporary access token (from a JWT).
Related:
PUT /api/v1/trusted_publishing/tokensAPI endpoint #11131