forked from ryyst/kalzu-value-store
ryyst
8d6a280441
- Add conditional route registration based on feature toggles - AuthEnabled now controls authentication/user management endpoints - ClusteringEnabled controls member and Merkle tree endpoints - RevisionHistoryEnabled controls history endpoints - Feature toggles for RateLimitingEnabled and TamperLoggingEnabled were already implemented This completes issue #6 allowing flexible deployment scenarios by disabling unnecessary features and their associated endpoints. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
71 lines
2.4 KiB
Markdown
71 lines
2.4 KiB
Markdown
# Issue #3: Implement Autogenerated Root Account for Initial Setup
|
|
|
|
**Status:** Open
|
|
**Author:** MrKalzu
|
|
**Created:** 2025-09-12 22:17:12 +03:00
|
|
**Repository:** https://git.rauhala.info/ryyst/kalzu-value-store/issues/3
|
|
|
|
## Problem Statement
|
|
|
|
The KVS server lacks a mechanism to create an initial administrative user when starting with an empty database and no seed nodes. This makes it impossible to interact with authentication-protected endpoints during initial setup.
|
|
|
|
## Current Challenge
|
|
|
|
- Empty database + no seed nodes = no way to authenticate
|
|
- No existing users means no way to create API tokens
|
|
- Authentication-protected endpoints become inaccessible
|
|
- Manual database seeding required for initial setup
|
|
|
|
## Proposed Solution
|
|
|
|
### 1. Detection Logic
|
|
- Detect empty database condition
|
|
- Verify no seed nodes are configured
|
|
- Only trigger on initial startup with empty state
|
|
|
|
### 2. Root Account Generation
|
|
Create a default "root" user with:
|
|
- **Server-generated UUID**
|
|
- **Hashed nickname** (e.g., "root")
|
|
- **Assigned to default "admin" group**
|
|
- **Full administrative privileges**
|
|
|
|
### 3. API Token Creation
|
|
- Generate API token with administrative scopes
|
|
- Include all necessary permissions for initial setup
|
|
- Set reasonable expiration time
|
|
|
|
### 4. Secure Token Distribution
|
|
- **Securely log the token to console** (one-time display)
|
|
- **Persist user and token in BadgerDB**
|
|
- **Clear token from memory after logging**
|
|
|
|
## Implementation Details
|
|
|
|
### Relevant Code Sections
|
|
- `NewServer` function - Add initialization logic
|
|
- `User`, `Group`, `APIToken` structs - Use existing data structures
|
|
- Hashing and storage key functions - Leverage existing auth system
|
|
|
|
### Proposed Changes (from MrKalzu's comment)
|
|
- **Added `HasUsers() (bool, error)`** to `auth/auth.go`
|
|
- **Added "Initial root account setup for empty DB with no seeds"** to `server/server.go`
|
|
- **Diff file attached** with implementation details
|
|
|
|
## Security Considerations
|
|
|
|
- Token should be displayed only once during startup
|
|
- Token should have reasonable expiration
|
|
- Root account should be clearly identified in logs
|
|
- Consider forcing password change on first use (future enhancement)
|
|
|
|
## Benefits
|
|
|
|
- Enables zero-configuration initial setup
|
|
- Provides secure bootstrap process
|
|
- Eliminates manual database seeding
|
|
- Supports automated deployment scenarios
|
|
|
|
## Dependencies
|
|
|
|
This issue blocks **Issue #4** (securing administrative endpoints), as it provides the mechanism for initial administrative access. |