Enhance Config Struct Validation, Duration Parsing, and Secret Management #16
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The internal/platform/config package defines the strongly-typed application configuration. While the current JSON-based configuration loading works correctly, the struct contains fields which should be validated, type-enforced, or sourced securely for production environments.
Specifically:
Duration fields (lifetime, idleTimeout, rememberDuration, etc.) are strings and parsed later; invalid values fail late rather than early
Certain security-sensitive values (password, API key) are stored directly in JSON
DatabaseNamed has a JSON tag mismatch (databaseName vs databaseNamed)
Critical fields (e.g., database server/port, site name) lack upfront validation
Improving type safety and validation increases reliability and security of the bootstrap process.
Current Behavior (observed):
Config loads without validation (struct may be incomplete)
Type parsing (durations) happens separately in consuming components
Secrets are file-based instead of environment-based
Incorrect field naming does not cause breakage but reduces clarity
Why this matters:
Fail-fast behavior during bootstrap prevents obscure runtime panics
Removes silent misconfigurations
Hardens security posture by reducing accidental exposure of secrets
Architecturally aligns with immutable, strongly typed configuration
Scope of Work:
✅ Validate required fields during bootstrap (non-empty DB server, valid port, etc.)
✅ Convert duration strings to time.Duration at load time with structured errors
✅ Align JSON tags (DatabaseNamed → databaseNamed)
✅ Add environment override support for secrets (password/API key)
✅ Improve documentation and error reporting around invalid config values
✅ Unit tests for Load + validation failure scenarios
Non-Goals:
No change to configuration file layout unless required by tag fix
No rework of configuration merge/override strategy beyond minimal environment support
Risks / Mitigations:
Medium: Requires boot flow adjustments
✅ Mitigation: Introduce validation incrementally with clear logs
Acceptance Criteria:
✅ Bootstrap errors clearly if required fields are missing/invalid
✅ Duration values are type-safe before use (no runtime parsing failures)
✅ Sensitive values may be read from environment
✅ JSON config linted for consistency
✅ Tests confirm validation rules and override behavior
Effort Estimate:
Medium (2–4 dev days)