feat: LLM API 키를 두 번째 리소스 종류로 추가 - #49
Merged
Merged
Conversation
The approver decides that somebody may have a key; only its owner may ever see the plaintext, and the approver is not in the room when they do. So approval creates the key, its access list and its period, and the owner mints the secret themselves - once. A key between the two is PENDING with no hash, and the gateway is not told about it at all: a key that authenticates nothing has no state worth publishing. Carries the token hash's char(64) mapping with it. Hibernate validates the schema at startup, so without it every application context refused to build - which no compile and no single-class run catches.
Promote the relay filter's chunked-body cap wrapper to common.web so the LLM gateway chain can reuse it. Behaviour unchanged.
The dedicated /internal/llm chain sits ahead of the broad /internal catch-all, which moves one order slot down with behaviour unchanged. The unchanged poll answers the bare generation without building the document, a generation reported above ours raises the counter instead of being discarded, per-event usage problems are never a 4xx, and the bodies endpoint accepts and deliberately stores nothing.
The VM list's grant-to-visibility reduction is the platform's access rule, not the VM's; lifted so a second resource type reuses it instead of copying it. VM behavior is unchanged.
The list and detail a user sees for their keys, plus the key's access-list endpoints as a pass-through into the shared grant service. Visibility follows the platform rule: only a grant opens a row, a member without one gets a restricted row that never carries the token prefix, and a non-member is answered with the 404 existence mask. The token hash appears in no response, asserted against whole bodies. The published spec snapshot is regenerated in the contract round that versions this surface; until then ContractDriftTest's snapshot check is the one expected failure.
The matrix marks the key's operations resource-scoped, which the annotation-reading matrix test cannot verify at runtime. Drive all eight operations across the five standings, and pin the deliberate asymmetry between issuing (an OWNER grant, never standing rights) and revoking (a standing right of workspace owners and admins), plus rotation, the revoked-key conflict and revoke idempotence.
Revoking is a standing right in the access model - taking a resource away, which a workspace owner holds without a grant - and the code required an OWNER grant for it. During a leaked-key incident that left the only people able to stop it as the ones already on its access list, and a workspace owner whose key owner had left would have had to grant themselves content access first: a break-glass record for taking something away. ORG_ADMIN (own org) and SYS_ADMIN now reach it too, matching VM deletion. Minting stays on the OWNER grant. Handing somebody a working credential is content access, and standing rights deliberately do not include that - the same line the VM draws at reading a password. Also here, because both are in the same file: issue re-reads the status after taking the generation lock, since the check before it ran against a snapshot a concurrent revoke could have invalidated - the full-column update would then have written ACTIVE and a null revoked_at back over it. And update() no longer folds purpose into rename, which erased a purpose whenever somebody renamed without resending it, contradicting the schema's own '생략한 항목은 그대로 둡니다'.
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
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.
📝 작업내용
Pageable제거, 순서를 속성 이름이 아니라 의미로 규정⭐️ 검증
💬 리뷰 포인트