Dashboard Add top-right user dropdown using Syncfusion DropDownButton: shows username + role; menu entries “Profil” and “Abmelden”. Replace custom dropdown logic with Syncfusion component; position at header’s right edge. Update /logout page to call backend logout and redirect to /login (reliable user switching). Build/Config Add @syncfusion/ej2-react-splitbuttons and @syncfusion/ej2-splitbuttons dependencies. Update Vite optimizeDeps.include to pre-bundle splitbuttons and avoid import-analysis errors. Docs README: Rework Architecture Overview with clearer data flow: Listener consumes MQTT (discovery/heartbeats) and updates API. Scheduler reads from API and publishes events via MQTT to clients. Clients send via MQTT and receive via MQTT. Worker receives commands directly from API and reports results back (no MQTT). Explicit note: MariaDB is accessed exclusively by the API Server; Dashboard never talks to DB directly. README: Add SplitButtons to “Syncfusion Components Used”; add troubleshooting steps for @syncfusion/ej2-react-splitbuttons import issues (optimizeDeps + volume reset). Copilot instructions: Document header user menu and splitbuttons technical notes (deps, optimizeDeps, dev-container node_modules volume). Program info Bump to 2025.1.0-alpha.10 with changelog: UI: Header user menu (DropDownButton with username/role; Profil/Abmelden). Frontend: Syncfusion SplitButtons integration + Vite pre-bundling config. Fix: Added README guidance for splitbuttons import errors. No breaking changes.
4.6 KiB
Superadmin User Setup
This document describes the superadmin user initialization system implemented in the infoscreen_2025 project.
Overview
The system automatically creates a default superadmin user during database initialization if one doesn't already exist. This ensures there's always an initial administrator account available for system setup and configuration.
Implementation Details
Files Modified
-
server/init_defaults.py- Updated to create a superadmin user with role
superadmin(fromUserRoleenum) - Password is securely hashed using bcrypt
- Only creates user if not already present in the database
- Provides clear feedback about creation status
- Updated to create a superadmin user with role
-
.env.example- Updated with new environment variables
- Includes documentation for required variables
-
docker-compose.ymlanddocker-compose.prod.yml- Added environment variable passthrough for superadmin credentials
-
userrole-management.md- Marked stage 1, step 2 as completed
Environment Variables
Required
DEFAULT_SUPERADMIN_PASSWORD: The password for the superadmin user- IMPORTANT: This must be set for the superadmin user to be created
- Should be a strong, secure password
- If not set, the script will skip superadmin creation with a warning
Optional
DEFAULT_SUPERADMIN_USERNAME: The username for the superadmin user- Default:
superadmin - Can be customized if needed
- Default:
Setup Instructions
Development
-
Copy
.env.exampleto.env:cp .env.example .env -
Edit
.envand set a secure password:DEFAULT_SUPERADMIN_USERNAME=superadmin DEFAULT_SUPERADMIN_PASSWORD=your_secure_password_here -
Run the initialization (happens automatically on container startup):
docker-compose up -d
Production
-
Set environment variables in your deployment configuration:
export DEFAULT_SUPERADMIN_USERNAME=superadmin export DEFAULT_SUPERADMIN_PASSWORD=your_very_secure_password -
Deploy with docker-compose:
docker-compose -f docker-compose.prod.yml up -d
Behavior
The init_defaults.py script runs automatically during container initialization and:
- Checks if the username already exists in the database
- If it exists: Prints an info message and skips creation
- If it doesn't exist and
DEFAULT_SUPERADMIN_PASSWORDis set:- Hashes the password with bcrypt
- Creates the user with role
superadmin - Prints a success message
- If
DEFAULT_SUPERADMIN_PASSWORDis not set:- Prints a warning and skips creation
Security Considerations
- Never commit the
.envfile to version control - Use a strong password (minimum 12 characters, mixed case, numbers, special characters)
- Change the default password after first login
- In production, consider using secrets management (Docker secrets, Kubernetes secrets, etc.)
- Rotate passwords regularly
- The password is hashed with bcrypt (industry standard) before storage
Testing
To verify the superadmin user was created:
# Connect to the database container
docker exec -it infoscreen-db mysql -u root -p
# Check the users table
USE infoscreen_by_taa;
SELECT username, role, is_active FROM users WHERE role = 'superadmin';
Expected output:
+------------+------------+-----------+
| username | role | is_active |
+------------+------------+-----------+
| superadmin | superadmin | 1 |
+------------+------------+-----------+
Troubleshooting
Superadmin not created
Symptoms: No superadmin user in database
Solutions:
- Check if
DEFAULT_SUPERADMIN_PASSWORDis set in environment - Check container logs:
docker logs infoscreen-api - Look for warning message: "⚠️ DEFAULT_SUPERADMIN_PASSWORD nicht gesetzt"
User already exists message
Symptoms: Script says user already exists but you can't log in
Solutions:
- Verify the username is correct
- Reset the password manually in the database
- Or delete the user and restart containers to recreate
Permission denied errors
Symptoms: Database connection errors during initialization
Solutions:
- Verify
DB_USER,DB_PASSWORD, andDB_NAMEenvironment variables - Check database container is healthy:
docker ps - Verify database connectivity:
docker exec infoscreen-api ping -c 1 db
Next Steps
After setting up the superadmin user:
- Implement the
/api/meendpoint (Stage 1, Step 3) - Add authentication/session management
- Create permission decorators (Stage 1, Step 4)
- Build user management UI (Stage 2)
See userrole-management.md for the complete roadmap.