DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.9 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | body | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a19-f009 | 접근 검사가 두 갈래로 존재하고, 조립된 쪽이 진단이 약한 쪽이다 (§8.3) | messaging-and-outbox | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a19-f009 | 2026-09-01 | case-analysis-finding-a19-f009.body.md |
|
|
|
접근 검사가 두 갈래로 존재하고, 조립된 쪽이 진단이 약한 쪽이다 (§8.3)
같은 권한 검사가 두 형태로 있다. 조립된 쪽은 거부를 설정 분류로 돌려주고, 조립되지 않은 쪽은 전용 인가 예외를 던진다. 검사 자체는 조립된 쪽에서 수행되므로 보안 구멍은 아니다.
관계
- 중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다 이 사례가 그 규칙의 형태다.
- 브로커 권한 매니페스트의 자기 점검이 존재하지 않는다 같은 가족의 다른 권한 사례다.
- 권한 거부와 설정 실수가 같은 버킷에 들어간다 기록하는 이유다.
문제
같은 권한 검사가 두 형태로 있다.
어느 쪽이 조립되었고 두 쪽의 차이가 무엇인지 확인했다.
결론
조립된 쪽은 발행자가 접근 정책을 직접 부르는 형태다.
발행이 허용되지 않으면 발행 금지 코드와 메시지를 담은 거부 결과를 돌려준다. 실패 분류가 설정이고 재시도 불가다.
조립되지 않은 쪽은 전용 검증기다. 주 참조도 테스트 참조도 0 이다.
발행이 허용되지 않으면 전용 인가 예외를 던진다. 코드와 함께 자격증명이 그 목적지에 발행할 수 없다는 메시지를 담는다.
그 클래스의 자바독이 존재 이유를 적는다.
브로커의 권한 검사보다 먼저 돌고, 일으키는 실패가 논리 목적지와 역할을 이름으로 부른다는 것이다.
브로커 권한 거부는 애플리케이션 문맥이 없는 연결 수준 오류로 도착하며, 그래서 어느 모듈이 어디로 발행하려 했는가가 로그 한 줄이 아니라 조사가 된다는 것이다.
두 경로의 차이는 분류다.
조립된 쪽은 인가 거부를 설정으로 분류한다. 조립되지 않은 쪽은 전용 인가 예외를 던진다.
핵심 계약의 예외 스물여섯 종에 그 인가 예외가 명시적으로 있는데, 실제 발행 경로는 그 타입을 쓰지 않는다.
권한 거부가 설정으로 집계되면 설정 실수와 권한 침해 시도가 같은 갈래에 들어간다.
실제 검사 자체는 조립된 쪽에서 수행되므로 보안 구멍은 아니다.
분류와 진단의 문제이고, 중복 장치 중 조립되지 않은 쪽이 더 정확한 분류를 갖고 있다.
판정은 P3 다.
검증 환경
확인 방식 : 두 경로의 구현과 참조 계수 대조 소스 수정 : x
재현 조건
원문은 final/evidence/raw/252 계열에 있다.
- 발행자에서 권한 검사를 부르는 지점을 읽는다.
- 거부 결과의 분류와 재시도 여부를 확인한다.
- 전용 검증기의 구현과 자바독을 읽는다.
- 그 검증기의 참조를 센다.
- 핵심 계약의 예외 목록에 인가 예외가 있는지 확인한다.
본문
같은 권한 검사가 두 형태로 있다.
조립된 쪽
DefaultMessagePublisher가 DestinationAccessPolicy를 직접 호출한다.
if (!access.mayPublish(destination.name())) {
return rejected("PUBLISH_FORBIDDEN",
"this application may not publish to '" + destination.name().value() + '\'', startedAt);
}
FailureCategory.CONFIGURATION · retryable=false인 PublishResult를 돌려준다.
DefaultMessagePublisher 참조 위치
:::evidence key="analysis-finding-a19-f009" alt="코드베이스에서 DefaultMessagePublisher 를 검색한 출력 6줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="DefaultMessagePublisher 코드베이스 검색 — 6줄 · exit 0" zoom="true" :::
조립되지 않은 쪽
DestinationAccessValidator(main 참조 0건, 테스트 0건)가 전용 예외를 던진다.
public void requirePublish(DestinationName destination) {
if (!policy.mayPublish(destination)) {
throw new MessageAuthorizationException("DESTINATION_PUBLISH_DENIED",
"the producer credential may not publish to " + destination.value());
}
}
조립된 쪽이 진단이 약한 쪽이다. P3.
확인하지 못한 것
권한 거부를 발생시켜 집계 갈래를 확인하지 않았다. 분류 상수상 그 결과가 나온다.