fix(server): use native Spring Boot access-log retention for DSMS

[FelixTJDietrich]

Description

This narrows the solution down to the smallest defensible change: use embedded Tomcat's native access-log retention for the application server, and make the legal / DSMS text match that reality. It intentionally removes extra env surface and avoids leaking implementation trivia into the public privacy notice.

What I changed after re-review

• Kept the core improvement: application-server access logs now use native embedded-Tomcat retention with server.tomcat.accesslog.max-days=14.
• Removed the extra env-variable layer for log settings; the retention policy is now fixed in application-prod.yml instead of being spread across compose and .env.
• Removed the added Logback file-rotation story from the PR because it was not needed for the compliance goal and increased operational surface.
• Simplified the privacy statement so it states only what a data subject should care about: what is logged, why, and for how long.
• Kept the DSMS docs technical enough for auditability, but cut unnecessary detail that would create drift and maintenance burden.

Why this is better

• Smaller config surface
• Fewer deployment knobs
• Less documentation drift risk
• Cleaner legal copy
• Stronger link between the compliance claim and the service that actually processes requests

Official Spring Boot basis

Verified against Spring Boot documentation:

• Logging reference: Boot supports native file logging and Logback rolling-policy properties.
• Embedded Web Servers how-to: Tomcat access logging is a first-class built-in feature and supports custom patterns.
• Security / proxy how-to: server.forward-headers-strategy=native and server.tomcat.redirect-context-root=false are the documented proxy-safe approach behind TLS-terminating proxies.

How to test

• npm run check
• cd server/application-server && ./mvnw test -q
• IMAGE_TAG=latest APP_HOSTNAME=example.com docker compose -f docker/compose.app.yaml config --quiet
• Verify server/application-server/src/main/resources/application-prod.yml contains server.tomcat.accesslog.enabled=true and server.tomcat.accesslog.max-days=14
• After deploy, verify access logs are written under /var/log/hephaestus/access/ and files older than 14 days are not retained

Summary by CodeRabbit

• New Features

  • Implemented automated server access log management with automatic purging after 14 days.

• Documentation

  • Updated privacy policy and data-protection documentation to reflect new access log retention practices.
  • Clarified minimal data fields captured in server access logs to enhance user privacy.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes shift server access logging from Docker container log buffers (250 MB/30 MB) to native Tomcat access logging with 14-day automatic retention. Infrastructure is updated to support the new logging mechanism, and all compliance documentation and privacy statements are revised to reflect this change.

Changes

Cohort / File(s)	Summary
Docker & Container Infrastructure docker/compose.app.yaml, server/application-server/Dockerfile	Added persistent volume application-server-logs for /var/log/hephaestus mount; created /var/log/hephaestus/access directory with spring:spring ownership in Dockerfile.
Spring Boot Access Logging Configuration server/application-server/src/main/resources/application-prod.yml	Enabled Tomcat native access logging with directory /var/log/hephaestus/access, 14-day retention (max-days: 14), custom log pattern, and header-forwarding strategy.
Compliance & DSMS Documentation docs/admin/dsms/02-dsfa-prescreen.md, docs/admin/dsms/03-vt-dsms.md, docs/admin/dsms/04-toms.md, docs/admin/dsms/README.md, docs/admin/dsms/SUBMISSION-GUIDE.md	Updated log retention descriptions, residual risk analysis, and verification procedures; replaced Docker buffer semantics with Tomcat 14-day access-log retention; reformatted tables and adjusted checklist items.
Privacy Statement webapp/public/legal/profiles/tumaet/privacy.md	Revised server log field descriptions and updated retention wording from fixed-size buffer model to 14-day automatic deletion; adjusted Markdown emphasis formatting.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 Logs now flow where Tomcat dwells,
Fourteen days, then deleted bells,
Volumes mounted, access clear,
Privacy policy striped of fear!
Configuration blooms, compliance grows.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main technical change: implementing native Spring Boot access-log retention for DSMS compliance instead of Docker-side approximations.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/native-spring-log-retention

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

📚 Documentation Preview

Preview has been removed (PR closed)

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docs/admin/dsms/03-vt-dsms.md (1)

143-143: ⚠️ Potential issue | 🟠 Major

Update the stale server-log data-category row.

Line 143 still mentions the old storage-cap model plus user-agent and referrer, but §13 and the Tomcat pattern no longer include those fields. This would make the DSMS submission internally inconsistent.

Proposed documentation fix

-- **Server logs (per-service storage cap, oldest entries dropped automatically once exceeded; see §13):** IP address, timestamp, HTTP method, URL, status code, bytes transferred, user-agent, referrer.
+- **Application-server security logs (native Tomcat access log; see §13):** IP address, timestamp, HTTP method, request path, protocol version, status code, response size, and server-side processing time.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/admin/dsms/03-vt-dsms.md` at line 143, The "Server logs (per-service
storage cap, oldest entries dropped automatically once exceeded; see §13):" row
is stale—remove the obsolete "per-service storage cap" phrase and drop the two
fields no longer emitted by the Tomcat pattern (user-agent and referrer); update
the field list to match §13/Tomcat (e.g., IP address, timestamp, HTTP method,
URL, status code, bytes transferred) and add a short note pointing to §13 for
retention/rotation details so the row aligns with current logging behavior.

🧹 Nitpick comments (1)

docs/admin/dsms/02-dsfa-prescreen.md (1)

57-57: Clarify scope of “server-log” vs “access-log” retention.

Consider renaming this bullet to explicitly say access-log retention (or add a short clause about application/runtime logs) to prevent audit ambiguity about what is bounded by max-days=14.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/admin/dsms/02-dsfa-prescreen.md` at line 57, Rename or clarify the
bullet so it explicitly refers to access-log retention (not generic
“server-log”) and/or add a short clause distinguishing access logs from other
application/runtime logs; update the sentence that mentions
server.tomcat.accesslog.max-days=14 to read something like “Bounded access-log
retention (application access logs) via the application server’s native
access-log retention (server.tomcat.accesslog.max-days=14) — application/runtime
logs are out of scope” so auditors clearly know which logs the 14-day limit
applies to.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@docs/admin/dsms/03-vt-dsms.md`:
- Line 143: The "Server logs (per-service storage cap, oldest entries dropped
automatically once exceeded; see §13):" row is stale—remove the obsolete
"per-service storage cap" phrase and drop the two fields no longer emitted by
the Tomcat pattern (user-agent and referrer); update the field list to match
§13/Tomcat (e.g., IP address, timestamp, HTTP method, URL, status code, bytes
transferred) and add a short note pointing to §13 for retention/rotation details
so the row aligns with current logging behavior.

---

Nitpick comments:
In `@docs/admin/dsms/02-dsfa-prescreen.md`:
- Line 57: Rename or clarify the bullet so it explicitly refers to access-log
retention (not generic “server-log”) and/or add a short clause distinguishing
access logs from other application/runtime logs; update the sentence that
mentions server.tomcat.accesslog.max-days=14 to read something like “Bounded
access-log retention (application access logs) via the application server’s
native access-log retention (server.tomcat.accesslog.max-days=14) —
application/runtime logs are out of scope” so auditors clearly know which logs
the 14-day limit applies to.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a2257b1e-92c2-4c89-8c42-19a052fb3e77

📥 Commits

Reviewing files that changed from the base of the PR and between b984d6d and 771dd6c.

📒 Files selected for processing (9)

• docker/compose.app.yaml
• docs/admin/dsms/02-dsfa-prescreen.md
• docs/admin/dsms/03-vt-dsms.md
• docs/admin/dsms/04-toms.md
• docs/admin/dsms/README.md
• docs/admin/dsms/SUBMISSION-GUIDE.md
• server/application-server/Dockerfile
• server/application-server/src/main/resources/application-prod.yml
• webapp/public/legal/profiles/tumaet/privacy.md

[FelixTJDietrich]

🎉 This PR is included in version 0.62.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀