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>
47 lines
1.8 KiB
Markdown
47 lines
1.8 KiB
Markdown
# Issue #5: Add Configuration for Anonymous Read and Write Access to KV Endpoints
|
|
|
|
**Status:** Open
|
|
**Author:** MrKalzu
|
|
**Created:** 2025-09-12
|
|
**Repository:** https://git.rauhala.info/ryyst/kalzu-value-store/issues/5
|
|
|
|
## Description
|
|
|
|
Currently, KV endpoints are publicly accessible without authentication. This issue proposes adding granular control over public access to key-value store functionality.
|
|
|
|
## Proposed Configuration Parameters
|
|
|
|
Add two new configuration parameters to the `Config` struct:
|
|
|
|
1. **`AllowAnonymousRead`** (boolean, default `false`)
|
|
- Controls whether unauthenticated users can read data
|
|
|
|
2. **`AllowAnonymousWrite`** (boolean, default `false`)
|
|
- Controls whether unauthenticated users can write data
|
|
|
|
## Proposed Implementation Changes
|
|
|
|
### Modify `setupRoutes` Function
|
|
- Conditionally apply authentication middleware based on configuration flags
|
|
|
|
### Specific Handler Changes
|
|
- **`getKVHandler`**: Apply auth middleware with "read" scope if `AllowAnonymousRead` is `false`
|
|
- **`putKVHandler`**: Apply auth middleware with "write" scope if `AllowAnonymousWrite` is `false`
|
|
- **`deleteKVHandler`**: Always require authentication (no anonymous delete)
|
|
|
|
## Goal
|
|
|
|
Provide granular control over public access to key-value store functionality while maintaining security for sensitive operations.
|
|
|
|
## Use Cases
|
|
|
|
- **Public read-only deployments**: Allow anonymous reading for public data
|
|
- **Public write scenarios**: Allow anonymous data submission (like forms or logs)
|
|
- **Secure deployments**: Require authentication for all operations
|
|
- **Mixed access patterns**: Different permissions for read vs write operations
|
|
|
|
## Security Considerations
|
|
|
|
- Delete operations should always require authentication
|
|
- Consider rate limiting for anonymous access
|
|
- Audit logging should track anonymous operations differently |