feat(pg-pkg): add /v2/api-key/validate endpoint - #167
Merged
Conversation
Sibling services (cryptify) need to confirm a `PG-…` API key is valid and
read the tenant id without going through signing-key issuance. Previously
they had to either re-implement the `business_api_keys` lookup against the
business database, or maintain a parallel allowlist of hashes — both create
drift on key rotation/revocation.
The new `GET /v2/api-key/validate` reuses the existing `Auth` middleware
with `AuthType::Key` and the `ApiKeyGuard`, returning
`{ tenant_id, organisation_name }` on success. `tenant_id` is
`organizations.id` (uuid, stringified) — added as a new field on
`ApiKeyData` and selected by `PgApiKeyStore::lookup`.
The route is only registered when a database pool is configured (same gate
as `/sign/key`), since validation has nothing to validate against without
the business schema.
Tests: success path returns the tenant id, unknown key is rejected, missing
or non-PG bearer 404s through the guard. All 30 pg-pkg tests pass.
6 tasks
rubenhensen
marked this pull request as ready for review
May 6, 2026 09:42
58 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
GET /v2/api-key/validateso sibling services can confirm aPG-…API key is valid and read the tenant id without going through signing-key issuance. Pairs with encryption4all/cryptify#139, which switches cryptify's quota-tier check from a parallel hashed allowlist to this endpoint.What changed
pg-pkg/src/handlers/api_key_validate.rs. Pulls the validatedApiKeyDataout of request extensions, returns{ tenant_id, organisation_name }.tenant_idisorganizations.id(uuid, stringified).ApiKeyDatagains anorg_id: Stringfield;PgApiKeyStore::lookupnow selectso.id::textfrom the JOIN.Authmiddleware insertsApiKeyDatainto request extensions (alongside the existingApiKeySigningInfo) so the new handler can read identity without re-querying./v2scope, gated onApiKeyGuard+Auth::new(_, AuthType::Key).with_db_pool(...). Only registered when a database pool is configured (same gate as/sign/key).Tests
4 new unit tests on
setup_api_key_validate_test:tenant_idandorganisation_namefrom the mock storecargo test -p pg-pkg→ 30 passed; 0 failed.cargo fmt --checkclean.Test plan
curl -H 'Authorization: Bearer PG-<real-key>' http://pkg/v2/api-key/validatereturns 200 + tenant id; with a bogus key returns 401; without the header returns 404/v2/sign/keyAPI-key auth path (existing 5 tests intest_api_key_signing_*cover this)Deploy notes
Deploy this before the cryptify counterpart (encryption4all/cryptify#139) so cryptify's calls don't all hit the 30 s retry budget.