164 lines
7.1 KiB
Markdown
164 lines
7.1 KiB
Markdown
# Quality report
|
|
|
|
## Gate result
|
|
|
|
**PASS**
|
|
|
|
- Document type: `technical_blog`
|
|
- Reader language: `ko-KR`
|
|
- Citation mode: `hidden`
|
|
- Source pack: 48 entries
|
|
- Required H2 intents: 8/8, in contract order
|
|
- Deterministic lint: 100.0/100
|
|
- ClariDoc word count: 9,043
|
|
- Blockers: 0
|
|
- Errors: 0
|
|
- Warnings: 0
|
|
|
|
No mock-provider score is used as evidence of prose or factual quality.
|
|
|
|
## Evidence collection
|
|
|
|
All four pattern tips were inspected independently and read-only:
|
|
|
|
| Pattern | Git tip |
|
|
|---|---|
|
|
| AP1 | `bb8fd9333d7da1c6424d6e0b039fc1c80c2cf0ca` |
|
|
| AP2 | `d019846f8725bdb0badde33043b020dc252e32ff` |
|
|
| AP3 | `934c5da5d6edc2429dfb558b773656e46f21d677` |
|
|
| AP4 | `f4aea65dc6255eae07b20ebbe21e02fb6115e563` |
|
|
|
|
The canonical `develop` corpus was merged with branch-specific implementation,
|
|
configuration, test-contract, decision-rationale, and worked-flow evidence. The
|
|
expanded evidence covers browser entry, authorization callback, token/session
|
|
storage, controller and framework transformations, downstream requests, exact
|
|
reader JSON fields, failure statuses, and implementation gaps.
|
|
|
|
The common comparison described AP2 as a short or one-time handoff, but the
|
|
current controller returns the raw Keycloak access token on repeatable
|
|
authenticated GET requests and has no nonce consumption or deletion. The
|
|
article therefore uses the implementation-backed term `access-only handoff`.
|
|
|
|
## Reference-document calibration
|
|
|
|
The requested comparison document was inspected for its authoring pattern. Its
|
|
important technique is a concrete initial HTTP input followed through actual
|
|
classes and methods, intermediate models, next-hop input, and observable final
|
|
output. The revised Keycloak article applies the same technique separately to:
|
|
|
|
- AP1 login callback and browser Bearer `/api/me`;
|
|
- AP2 login session, `/token/boundary`, `/token/access`, and direct API call;
|
|
- AP3 login, `/bff/api/me`, CSRF issuance, and preference POST;
|
|
- AP4 login redirect, Nginx auth subrequest, upstream rewrite, and identity JSON.
|
|
|
|
## Independent reviews and revisions
|
|
|
|
### AP1 and AP2 technical review
|
|
|
|
Initial result: **NEEDS REVISION**
|
|
|
|
Material findings:
|
|
|
|
- the general Authorization Code introduction implied that every pattern used a
|
|
`code_challenge`, contradicting AP2's unverified PKCE boundary;
|
|
- the AP1 browser E2E was said to assert `username`, while its live assertion is
|
|
UI status plus decoded audience;
|
|
- AP2's `AP2_SESSION` transaction role before callback was missing;
|
|
- CORS wording could be mistaken for network-level access control;
|
|
- dynamic audience examples looked exact;
|
|
- AP1's local wildcard redirect registration and the diagnostic-server negative
|
|
test shape were not explicit.
|
|
|
|
All findings were revised. Targeted re-review result: **PASS**, with no remaining
|
|
blocker, error, or warning.
|
|
|
|
### AP3 and AP4 technical review
|
|
|
|
Initial result: **NEEDS REVISION**
|
|
|
|
Material findings:
|
|
|
|
- AP3 incorrectly placed the ID token in
|
|
`OAuth2AuthorizedClientService`; the corrected text separates access/refresh
|
|
token storage from the ID-token-derived OIDC principal in `SecurityContext`;
|
|
- AP4 was initially grouped with server-side session cookies and was assigned
|
|
persistent refresh-token custody; the corrected text describes the configured
|
|
minimal client-side cookie, absence of a shared server store, and the
|
|
unverified refresh lifecycle;
|
|
- the AP3 handler was named `updatePreferences` instead of the actual
|
|
`updatePreference`;
|
|
- the cross-site test was described beyond its exact assertion, which only
|
|
checks that `AP3_SESSION` is absent from the request.
|
|
|
|
All findings were revised. Targeted re-review result: **PASS**, with no adjacent
|
|
regression found.
|
|
|
|
### Reader, logic, evidence, and procedure review
|
|
|
|
Initial result: **PASS WITH ONE WARNING**
|
|
|
|
The only warning was that “oauth2-proxy manages the Keycloak session” could
|
|
confuse the IdP SSO session with AP4's proxy session. The sentence now says that
|
|
oauth2-proxy owns OIDC code exchange and `AP4_SESSION` verification while Nginx
|
|
owns upstream request and identity-header construction.
|
|
|
|
The reviewer confirmed that:
|
|
|
|
- all four patterns contain a complete
|
|
`input → transformation → next hop → output` trace;
|
|
- test-defined contracts remain separate from fresh execution claims;
|
|
- hidden source metadata does not leak into reader prose;
|
|
- destructive volume reset is surrounded by prerequisites, stop conditions,
|
|
backup, and recovery guidance;
|
|
- each choice includes context, rationale, alternative, accepted cost,
|
|
guardrail, and evidence boundary.
|
|
|
|
## Validation performed
|
|
|
|
- Brief and 48-entry SourcePack runtime validation: **PASS**
|
|
- Deterministic preliminary outline generation: **PASS**
|
|
- Refined outline contract: **PASS**, 8 required intents in order
|
|
- Every refined-outline evidence ID resolves in the SourcePack: **PASS**
|
|
- Reader/provenance separation and hidden-citation leakage lint: **PASS**
|
|
- Final deterministic document lint: **PASS**, 100.0/100, 0 issues
|
|
- ClariDoc unit and integration suite: **PASS**, 41 tests
|
|
- Target repository after inspection: clean `develop`
|
|
- Four remote pattern refs re-resolved to the reviewed Git tips: **PASS**
|
|
- Earlier read-only manifest/ref audit: 39 declared feature refs exist and are
|
|
reachable from their declared target branches
|
|
|
|
## Validation deliberately not performed
|
|
|
|
The pattern verification scripts rebuild their stacks after deleting Docker
|
|
volumes. They were not run during this documentation task. The article therefore
|
|
describes committed acceptance contracts rather than claiming a fresh runtime
|
|
PASS.
|
|
|
|
The repository-provided branch audit still depends on a branch-note inventory
|
|
outside the available local path. The separate read-only Git reachability check
|
|
does not substitute for those missing note files.
|
|
|
|
The ClariDoc `scripts/verify.sh` workflow was not run because this worktree
|
|
already contains extensive user changes and that workflow removes or rebuilds
|
|
distribution and generated demo artifacts. The non-destructive 41-test suite,
|
|
contract validation, outline validation, and final lint were run instead.
|
|
|
|
## Remaining evidence boundaries
|
|
|
|
- AP1's E2E does not directly assert the token-request `code_verifier`, automatic
|
|
silent renewal, exact IdP cookie flags, CORS preflight, invalid signature, or
|
|
expired-token negative cases. Its local realm uses wildcard redirects.
|
|
- AP2 does not implement one-time consumption and does not verify expiry-driven
|
|
refresh, logout, durable session/token storage, or handoff replay rejection.
|
|
- AP3 does not implement a shared session/token store, token-at-rest encryption,
|
|
coordinated logout, downstream failure mapping, or user-scoped persistence
|
|
for the preference example.
|
|
- AP4's minimal cookie does not establish persistent refresh-token custody. Role
|
|
propagation, generalized endpoint enforcement, state-changing-request CSRF,
|
|
multi-replica cookie-secret lifecycle, and internal secret rotation remain
|
|
outside the verified contract.
|
|
- The Google harness uses a controllable mock identity provider. Real external
|
|
accounts and public-HTTPS acceptance remain separate.
|
|
- Performance, load, high availability, recovery, and long-duration session
|
|
behavior are outside the verified scope.
|