MrKalzu/kalzu-value-store
1
0
Fork 0
forked from ryyst/kalzu-value-store
Code Pull Requests Activity
Files
b4f57b3604e687447adbe559ac955c77eba85c37
kalzu-value-store/issues/5.md
ryyst 8d6a280441 feat: complete issue #6 - implement feature toggle integration in routes 
- 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>
2025-09-20 23:50:58 +03:00

1.8 KiB
Raw Blame History

Issue #5: Add Configuration for Anonymous Read and Write Access to KV Endpoints

Status: Open
Author: MrKalzu
Created: 2025-09-12
Repository: ryyst/kalzu-value-store#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