DongHyeonka
83409bef7a
The repository had no container image and no production-shaped serving configuration. `dist/server.mjs` is a preview server that applies neither the security headers nor the cache policy `config/hosting/` declares, so a deployment had nothing correct to run. `scripts/generate-nginx-config.ts` derives the server block from `dist/tech-log-serving-contract.json` plus the two hosting policy files, so the served headers and cache lifetimes cannot drift from what the contract declares. It emits no TLS and no proxy blocks: the edge terminates TLS and routes /api, and baking a backend address into the image would tie the bundle to one deployment. Static surfaces use `alias` because a base-path build serves /dev/assets/... out of dist/assets/..., which `root` plus URI would look for one directory too deep. The image copies that config next to the bundle and normalises permissions: the build writes config.json 0600, which nginx cannot read, so the container came up healthy and answered 403 for the one file the SPA needs to boot. index.html never referenced public/favicon.svg. The file shipped and nginx served it, but browsers asked for /favicon.ico, got a 404, and fell back to the default icon. `%BASE_URL%` rather than an absolute path so a prefixed deployment points at its own copy. development.json moves to the HTTP Studio source; the mock source has no backend to authenticate against, which is the whole point of that profile.
25 lines
1.3 KiB
Markdown
25 lines
1.3 KiB
Markdown
# Keycloak realm
|
|
|
|
`tech-log-realm.json` is imported by the `keycloak` service at start
|
|
(`--import-realm`). It exists because the realm was previously created by hand,
|
|
which meant §27 of the release checklist — "Keycloak Realm 설정을 복원할 수
|
|
있다" — had no answer: nothing in either repository described the realm.
|
|
|
|
What it declares, and why each part is load-bearing:
|
|
|
|
- **`studio-author` realm role.** `StudioAuthzEnvironmentPostProcessor` maps this
|
|
name to `studio:read` and `studio:write`. The name is configurable through
|
|
`APP_STUDIO_AUTHOR_ROLE`; if you change it here, change it there too.
|
|
- **`tech-log-bff` confidential client.** The Authorization Code flow belongs to
|
|
the backend, not the browser — the SPA never holds a token. `redirectUris` is
|
|
relative so the same realm works on any origin the deployment is served from.
|
|
- **`realm-roles` protocol mapper.** Without it the roles never reach the token,
|
|
the registry resolves zero permissions, and every Studio call answers 403.
|
|
|
|
## Values that must be replaced
|
|
|
|
`CHANGE_ME_BFF_SECRET` and `CHANGE_ME_STUDIO_PASSWORD` are placeholders, and the
|
|
deploy script substitutes them from the environment before import. They are left
|
|
visible rather than pre-filled so a realm file committed with a real secret is an
|
|
obvious mistake rather than a quiet one.
|