smartproxy/readme.plan.md

SmartProxy Interface Consolidation Plan

Overview

This document outlines a plan to consolidate duplicate and inconsistent interfaces in the SmartProxy codebase, specifically the IRouteSecurity interface which is defined twice with different properties. This inconsistency caused issues with security checks for port forwarding. The goal is to unify these interfaces, use consistent property naming, and improve code maintainability.

Problem Description

We currently have two separate IRouteSecurity interfaces defined in ts/proxies/smart-proxy/models/route-types.ts:

1. First definition (lines 116-122) - Used in IRouteAction:

   export interface IRouteSecurity {
     allowedIps?: string[];
     blockedIps?: string[];
     maxConnections?: number;
     authentication?: IRouteAuthentication;
   }
   

2. Second definition (lines 253-272) - Used directly in IRouteConfig:

   export interface IRouteSecurity {
     rateLimit?: IRouteRateLimit;
     basicAuth?: {...};
     jwtAuth?: {...};
     ipAllowList?: string[];
     ipBlockList?: string[];
   }
   

This duplication with inconsistent naming (allowedIps vs ipAllowList and blockedIps vs ipBlockList) caused routing issues when IP security checks were used, as we had to implement a workaround to check both property names.

Implementation Plan

Phase 1: Interface Consolidation

1. Create a unified interface definition:

   • Create one comprehensive IRouteSecurity interface that includes all properties
   • Use consistent property naming (standardize on ipAllowList and ipBlockList)
   • Add proper documentation for each property
   • Remove the duplicate interface definition

2. Update references to use the unified interface:

   • Update all code that references the old interface properties
   • Update all configurations to use the new property names
   • Ensure implementation in route-manager.ts uses the correct property names

Phase 2: Code and Documentation Updates

1. Update type usages and documentation:

   • Update all code that creates or uses security configurations
   • Update documentation to reflect the new interface structure
   • Add examples of the correct property usage
   • Document the breaking change in changelog.md

2. Add tests:

   • Update existing tests to use the new property names
   • Add test cases for all security configuration scenarios
   • Verify that port range configurations with security settings work correctly

Implementation Steps

// Step 1: Define the unified interface
export interface IRouteSecurity {
  // Access control lists
  ipAllowList?: string[];        // IP addresses that are allowed to connect
  ipBlockList?: string[];        // IP addresses that are blocked from connecting
  
  // Connection limits
  maxConnections?: number;       // Maximum concurrent connections
  
  // Authentication
  authentication?: IRouteAuthentication;
  
  // Rate limiting
  rateLimit?: IRouteRateLimit;
  
  // Authentication methods
  basicAuth?: {
    enabled: boolean;
    users: Array<{ username: string; password: string }>;
    realm?: string;
    excludePaths?: string[];
  };
  
  jwtAuth?: {
    enabled: boolean;
    secret: string;
    algorithm?: string;
    issuer?: string;
    audience?: string;
    expiresIn?: number;
    excludePaths?: string[];
  };
}

Update isClientIpAllowed method to use only the new property names:

private isClientIpAllowed(route: IRouteConfig, clientIp: string): boolean {
  const security = route.action.security;
  
  if (!security) {
    return true; // No security settings means allowed
  }
  
  // Check blocked IPs first
  if (security.ipBlockList && security.ipBlockList.length > 0) {
    for (const pattern of security.ipBlockList) {
      if (this.matchIpPattern(pattern, clientIp)) {
        return false; // IP is blocked
      }
    }
  }
  
  // If there are allowed IPs, check them
  if (security.ipAllowList && security.ipAllowList.length > 0) {
    for (const pattern of security.ipAllowList) {
      if (this.matchIpPattern(pattern, clientIp)) {
        return true; // IP is allowed
      }
    }
    return false; // IP not in allowed list
  }
  
  // No allowed IPs specified, so IP is allowed
  return true;
}

Expected Benefits

• Improved Consistency: Single, unified interface with consistent property naming
• Better Type Safety: Eliminating confusing duplicate interface definitions
• Reduced Errors: Prevent misunderstandings about which property names to use
• Forward Compatibility: Clearer path for future security enhancements
• Better Developer Experience: Simplified interface with comprehensive documentation

Testing Plan

1. Test with existing configurations using both old and new property names
2. Create specific test cases for port ranges with different security configurations
3. Verify that port forwarding with IP allow lists works correctly with the unified interface