Skip to content

Create shared module structure for client/server code reuse #124

@inureyes

Description

@inureyes

Summary

Create a shared module structure to enable code reuse between the existing bssh client and the new bssh-server. This is a foundational task that must be completed before other server implementation work begins.

Parent Epic

Motivation

The current codebase has several modules that can be reused for the server implementation:

  • Validation utilities
  • Rate limiting (token bucket algorithm)
  • Logging infrastructure
  • Error handling patterns
  • Authentication types

Extracting these into a shared module will:

  1. Avoid code duplication
  2. Ensure consistent behavior between client and server
  3. Make maintenance easier

Implementation Details

1. Create Shared Module Directory

src/
├── shared/                    # New shared module
│   ├── mod.rs                # Module exports
│   ├── validation.rs         # Input validation (from security/validation.rs)
│   ├── rate_limit.rs         # Rate limiting (from jump/rate_limiter.rs)
│   ├── auth_types.rs         # Shared auth types (from ssh/tokio_client/authentication.rs)
│   └── error.rs              # Shared error types

2. Extract Validation Utilities

Move and refactor from src/security/validation.rs:

  • validate_username() - Validate SSH username format
  • validate_hostname() - Validate hostname format
  • validate_local_path() - Validate local file paths
  • validate_remote_path() - Validate remote file paths
  • sanitize_error_message() - Remove sensitive data from errors

These are already client-agnostic and can be moved directly.

3. Extract Rate Limiter

Move from src/jump/rate_limiter.rs:

  • ConnectionRateLimiter struct
  • TokenBucket implementation

The rate limiter uses a token bucket algorithm that's useful for:

  • Client: Connection attempt rate limiting
  • Server: Authentication attempt rate limiting (fail2ban-like)

Generalize the interface:

pub struct RateLimiter<K: Hash + Eq> {
    buckets: Arc<RwLock<HashMap<K, TokenBucket>>>,
    config: RateLimitConfig,
}

pub struct RateLimitConfig {
    pub max_tokens: u32,
    pub refill_rate: f64,
    pub cleanup_after: Duration,
}

4. Extract Shared Auth Types

From src/ssh/tokio_client/authentication.rs, extract types usable by both client and server:

  • ServerCheckMethod enum (client uses for verification, server can use for configuration)

Create new shared types:

/// Common authentication result
pub enum AuthResult {
    Accept,
    Reject,
    Partial { remaining_methods: Vec<String> },
}

/// User information (shared between auth systems)
pub struct UserInfo {
    pub username: String,
    pub home_dir: PathBuf,
    pub shell: PathBuf,
    pub uid: Option<u32>,
    pub gid: Option<u32>,
}

5. Update Module Imports

Update existing client code to import from shared module:

  • src/security/mod.rs - Re-export from shared
  • src/jump/mod.rs - Re-export from shared
  • src/ssh/tokio_client/authentication.rs - Import shared types

6. Update lib.rs

// Add to src/lib.rs
pub mod shared;

// ... existing modules ...

Files to Modify

File Action
src/shared/mod.rs Create - Module exports
src/shared/validation.rs Create - Move from security/validation.rs
src/shared/rate_limit.rs Create - Move from jump/rate_limiter.rs
src/shared/auth_types.rs Create - Extract from auth modules
src/shared/error.rs Create - Shared error types
src/security/mod.rs Modify - Re-export from shared
src/jump/mod.rs Modify - Re-export from shared
src/lib.rs Modify - Add shared module

Testing Requirements

  1. All existing tests must pass after refactoring
  2. Add tests for generalized RateLimiter<K> with different key types
  3. Ensure validation functions work identically before and after move

Acceptance Criteria

  • src/shared/ module created with all extracted code
  • Existing client code works unchanged (via re-exports)
  • All existing tests pass
  • Rate limiter generalized to work with any hashable key type
  • No code duplication between client and shared modules
  • Documentation comments updated for shared module

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions