- Added failed login tracking for account lockout enforcement in `db` and `ui` layers; introduced `failed_logins` table to store attempts, window start, and attempt count.
- Updated login checks in `grpcserver/auth.go` and `ui/handlers_auth.go` to reject requests if the account is locked.
- Added immediate failure counter reset on successful login.
- Implemented username length and character set validation (F-12) and minimum password length enforcement (F-13) in shared `validate` package.
- Updated account creation and edit flows in `ui` and `grpcserver` layers to apply validation before hashing/processing.
- Added comprehensive unit tests for lockout, validation, and related edge cases.
- Updated `AUDIT.md` to mark F-08, F-12, and F-13 as fixed.
- Updated `openapi.yaml` to reflect new validation and lockout behaviors.
Security: Prevents brute-force attacks via lockout mechanism and strengthens defenses against weak and invalid input.
- ui/handlers_accounts.go (handleIssueSystemToken): call
GetSystemToken before issuing; if one exists, call
RevokeToken(existing.JTI, "rotated") before TrackToken
and SetSystemToken for the new token; mirrors the pattern
in REST handleTokenIssue and gRPC IssueServiceToken
- db/db_test.go: TestSystemTokenRotationRevokesOld verifies
the full rotation flow: old JTI revoked with reason
"rotated", new JTI tracked and active, GetSystemToken
returns the new JTI
- AUDIT.md: mark F-16 as fixed
Security: without this fix an old system token remained valid
after rotation until its natural expiry, giving a leaked or
stolen old token extra lifetime. With the revocation the old
JTI is immediately marked in token_revocation so any validator
checking revocation status rejects it.
- db/accounts.go: add RenewToken(oldJTI, reason, newJTI,
accountID, issuedAt, expiresAt) which wraps RevokeToken +
TrackToken in a single BEGIN/COMMIT transaction; if either
step fails the whole tx rolls back, so the user is never
left with neither old nor new token valid
- server.go (handleRenewToken): replace separate RevokeToken +
TrackToken calls with single RenewToken call; failure now
returns 500 instead of silently losing revocation
- grpcserver/auth.go (RenewToken): same replacement
- db/db_test.go: TestRenewTokenAtomic verifies old token is
revoked with correct reason, new token is tracked and not
revoked, and a second renewal on the already-revoked old
token returns an error
- AUDIT.md: mark F-03 as fixed
Security: without atomicity a crash/error between revoke and
track could leave the old token active alongside the new one
(two live tokens) or revoke the old token without tracking
the new one (user locked out). The transaction ensures
exactly one of the two tokens is valid at all times.
* Rewrite .golangci.yaml to v2 schema: linters-settings ->
linters.settings, issues.exclude-rules -> issues.exclusions.rules,
issues.exclude-dirs -> issues.exclusions.paths
* Drop deprecated revive exported/package-comments rules: personal
project, not a public library; godoc completeness is not a CI req
* Add //nolint:gosec G101 on PassphraseEnv default in config.go:
environment variable name is not a credential value
* Add //nolint:gosec G101 on EventPGCredUpdated in model.go:
audit event type string, not a credential
Security: no logic changes. gosec G101 suppressions are false
positives confirmed by code inspection: neither constant holds a
credential value.
