- ProxmoxVE script can now check if auth is already set without credentials
- Quick-setup endpoint is now public but handler checks if setup should be skipped
- Prevents duplicate auth configuration attempts
- Critical for automated setup scripts
- Remove old buggy Quick Security Setup handler
- New handler in security_setup_fix.go handles all cases properly
- Tested and working with Docker, systemd, and manual installations
- Enhanced logging to diagnose chat_id extraction problems
- Log payload being sent to Telegram for debugging
- Better error messages when chat_id is missing or invalid
- Add clear error message for truncated bcrypt hashes (addresses #316)
- Detect hashes between 55-59 chars and warn they're invalid
- Only accept exactly 60 character bcrypt hashes as valid
- Treat truncated hashes as plaintext to force users to fix them
- Cluster now handles offline nodes gracefully without marking endpoints unhealthy
- Fixed error 595 (node unreachable) not being treated as node-specific failure
- Added parallel health checks with shorter timeouts for better performance
- Fixed inconsistent border width on offline node cards (removed conflicting border-l-4)
- Switched to ring utility for consistent outline on offline/alert nodes
- Improved logout functionality with proper CSRF token handling
addresses #312, #315
- alerts now trigger when nodes go offline or lose connectivity
- alerts automatically resolve when nodes come back online
- offline status is checked before resource thresholds
- logs critical events when nodes lose connectivity
This was a major oversight - nodes going offline should always trigger alerts
- adds logout button next to connection status indicator
- implements /api/logout endpoint to clear sessions
- button only shows when authentication is configured
- clears session cookie and invalidates server-side session
implements #315
- tracks online/offline status for individual cluster nodes
- updates ClusterEndpoint.Online field during node polling
- fixes issue where all cluster nodes showed green indicator regardless of status
fixes#312
- explains purpose of each file type
- clarifies that .env is only for auth, not a regression
- documents the technical reasoning behind the architecture
- addresses confusion raised in #314
- clarified .env file usage for Docker (it's acceptable for Docker volumes)
- emphasized need for quotes around bcrypt hashes to prevent shell expansion
- removed incorrect SHA3-256 'cost factor' reference (only bcrypt has cost factor)
- added notes about proper quoting in Docker examples
addresses #314 - bcrypt hashes with $ signs were being interpreted as shell variables
by godotenv, causing authentication to fail after Docker container restarts
Updated security documentation to explicitly mention that Docker uses
the Quick Security Setup wizard and persists credentials via /data/.env
file in the volume, making it clear how auth works in Docker deployments.
Script outputs from change-password and remove-password operations could
potentially contain sensitive information. Removed output logging while
keeping error logging for debugging.
Docker now supports .env files in /data for auth credentials created
by the security wizard. This was added to fix the credential persistence
issue in Docker containers.
The export/import handlers were using direct string comparison for API tokens
instead of proper hash comparison. This caused auth to fail when tokens were
stored as hashes (which is what the security wizard does).
addresses #314
The security wizard was failing to detect Docker environments because PULSE_DOCKER
env var was never set in the Dockerfile. This caused credentials to not persist
correctly after container restarts.
addresses #314
- Docker containers were not saving credentials to persistent storage
- Non-Docker setups were saving plain text instead of hashed credentials
- After container restart, saved credentials would not work
This fixes issue #314 where users couldn't login after setting up security
in Docker containers. The Quick Security Setup now:
1. Properly hashes passwords and tokens before saving
2. Saves to /etc/pulse/.env for persistence in Docker volumes
3. Correctly loads credentials after container restart
- Add clear documentation that auth settings are intentionally excluded from exports
- Update API docs to explicitly state what is/isn't included in exports
- Enhance migration guide with security notes about auth exclusion
- Add UI warning in export dialog about auth settings not transferring
- Each Pulse instance should configure its own authentication for security
Related to user feedback about auth settings not transferring between instances
- No longer shows 'Use your login password' option when no auth is configured
- Defaults to passphrase-only mode for auth-less instances
- Shows 'Encryption Passphrase' instead of confusing login password references
- Always enforces 12-character minimum for auth-less users
- Clearer messaging throughout for different auth states
- Homelab users on private networks (192.168.x.x, 10.x.x.x, 172.16.x.x) can now export/import without any configuration
- No need to set ALLOW_UNPROTECTED_EXPORT=true for typical homelab setups
- Public network access still requires authentication for security
- Simplifies backup/restore for users who don't need authentication
- Clarify that session auth (password login) is sufficient for export/import
- Document that guest metadata and custom console URLs are included
- Update FAQ with clearer backup instructions
- Add UI-first approach to README backup section
- Bring back the blue-cyan gradient background
- Restore animated Pulse logo with hover effects
- Keep the semi-transparent backdrop-blur card design
- Maintain the improved form field styling with icons
- Guest metadata handler now reloads from disk after import
- Custom console URLs are immediately available after import
- No longer requires service restart to see imported guest URLs
- Export/import now uses PULSE_DATA_DIR env var (defaults to /etc/pulse)
- Guest console URLs and metadata are now properly included in backups
- Fixed path mismatch between runtime (/etc/pulse) and export (/var/lib/pulse)
- Export/import now includes X-CSRF-Token header from cookie
- Fixes 403 Forbidden error when exporting with session auth
- Both export and import endpoints now properly validate CSRF tokens
- Allow export/import with session auth when logged in with password
- No longer require API token when user is already authenticated
- Backend now accepts either session cookies OR API token
- Frontend only prompts for API token if no password auth exists
- Improved UX by eliminating redundant authentication requests
- Add visual cards for export/import actions with descriptive icons
- Allow users to use their login password by default for backups
- Add option for custom passphrase when needed
- Improve clarity around password requirements
- Add security notice with clear guidance
- Simplify the backup process by reducing password friction
- Fix clipboard copy buttons not working over HTTP by using fallback method
- Add proper clipboard utility with document.execCommand fallback
- Update all copy buttons to use the fallback-enabled utility
- Enhance Authentication section UI with better visual hierarchy
- Add colored headers with gradients for security sections
- Implement card-based buttons with icons and descriptions
- Show actual Pulse URL in API token examples instead of placeholder
- Improve overall security settings layout and accessibility
- Store API tokens in sessionStorage during security setup
- Add CurrentAPIToken component to display tokens from current session
- Show token section in Settings when authentication is enabled
- Tokens can only be retrieved during the session they were created
- After logout/restart, tokens cannot be recovered (stored as SHA3-256 hash)
This addresses user feedback about making API tokens retrievable after
initial setup, similar to other applications, while maintaining security.
The API Token Manager section was showing a different token than the one
created by Quick Security Setup, causing confusion.
Changes:
- Hide API Token Manager when using Quick Security Setup
- Quick Security Setup manages API tokens via systemd
- Add clarification that the token shown is for API automation
- Remove duplicate/confusing token management UI
The Quick Security Setup token is the only one that matters when using
that method of authentication setup.
Users can now choose between:
- Auto-Generate: Creates secure 16-character password (default)
- Custom: Set their own username and password
Features:
- Toggle between auto-generate and custom modes
- Custom username field (defaults to 'admin')
- Password validation (min 8 characters)
- Password confirmation field
- Clear messaging about password hashing
- Both modes use bcrypt hashing with cost factor 12
- Clarify that passwords are ALWAYS bcrypt hashed (never plain text)
- Document SHA3-256 hashing for API tokens
- Add Quick Security Setup as recommended method
- Update examples to show hashed format required
- Add security best practices section
- Add verification script reference
- Update troubleshooting for new auth variables
- Include CSRF token in change password requests
- Include CSRF token in remove password requests
- Get token from pulse_csrf cookie
- Add credentials: 'include' to ensure cookies are sent
This fixes the 'CSRF token validation failed' error when
trying to change or remove passwords.
New Feature:
- Add "Remove Password" button in Settings → Security tab
- Allows users to disable password authentication completely
- Returns Pulse to open access mode (no auth required)
- Requires current password confirmation for security
Implementation:
- New API endpoint: POST /api/security/remove-password
- New modal component: RemovePasswordModal.tsx
- Removes password from systemd override files
- Clears auth configuration from running instance
- Invalidates all sessions after removal
This addresses the issue where users couldn't disable authentication
once it was enabled. Now they can easily toggle between secured and
open modes as needed for their use case.
Documentation Updates:
- Fix CORS documentation to reflect new secure defaults (no CORS by default)
- Add API token management endpoints to API.md
- Document CORS configuration in SECURITY.md
- Update environment variable documentation with defaults
- Add authentication variables (PULSE_PASSWORD, API_TOKEN, etc.)
- Add troubleshooting for CORS and authentication issues
- Remove outdated references to ALLOWED_ORIGINS=*
- Clarify that CORS defaults to same-origin only
All documentation now accurately reflects:
- Security improvements from recent audit
- New API token management features
- Correct CORS behavior and configuration
- Complete environment variable reference
Pulse Monitor