MiauRizius/MiauInv
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 4 Wiki Activity

feat: added activity log

Browse Source
This commit is contained in:
miaurizius
2026-06-10 14:17:33 +02:00
parent 96f1a40266
commit 0442e4f699
16 changed files with 1027 additions and 579 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/SECURITY.md
View File

@@ -1,4 +1,4 @@
# Security Notes
# Security
This document summarizes the current security-relevant behavior of MiauInv. It is intended as implementation documentation, not as a guarantee that the application is production-ready for untrusted public deployments.
@@ -80,9 +80,17 @@ When passkeys are added, removed, or disabled, existing refresh sessions are rev
Passkey ceremonies require HTTPS except for localhost. Reverse proxy deployments must preserve the correct public `Host`, `X-Forwarded-Host`, and `X-Forwarded-Proto` information so that the relying party origin and ID match the browser-visible origin.
## Activity Logging
MiauInv stores an authenticated activity log for security-relevant and state-changing actions, including login attempts, refresh-token rotation, account changes, 2FA changes, passkey management, logout, and inventory mutations.
The activity log intentionally stores metadata only: action name, entity type, optional target ID, HTTP method, path, status, success flag, IP address, user agent, and timestamp. Request bodies are not logged, so passwords, TOTP codes, recovery codes, refresh tokens, and WebAuthn payloads are not persisted in the activity table.
Users can read their own entries from `/profile/activity` and `/api/activity`. Admin users may request all users' activity with `?all=true`. The API enforces authentication, bounds pagination limits, and is protected by rate limiting.
## Rate Limiting
Basic in-memory rate limiting protects login, passkey ceremonies, 2FA, refresh, registration, and sensitive account endpoints.
Basic in-memory rate limiting protects login, passkey ceremonies, 2FA, refresh, registration, activity, and sensitive account endpoints.
This is suitable for a single-instance private deployment. It is not sufficient for multi-instance deployments because limiter state is process-local. A public or multi-instance deployment should use persistent or distributed rate limiting at the application, reverse proxy, or infrastructure layer.
@@ -93,5 +101,4 @@ This is suitable for a single-instance private deployment. It is not sufficient
- Passkey credential metadata and public-key data are stored in the database after registration.
- TOTP secrets are not encrypted at rest.
- There is no dedicated session/device management UI yet.
- There is no audit log for account security changes yet.
- The current rate limiter is process-local and memory-only.