pn-new-crm/src/lib/rate-limit.ts

import { redis } from '@/lib/redis';
import { logger } from '@/lib/logger';

export interface RateLimitConfig {
  /** Duration of the sliding window in milliseconds. */
  windowMs: number;
  /** Maximum number of requests allowed per window. */
  max: number;
  /** Redis key prefix distinguishing different limit types. */
  keyPrefix: string;
}

export interface RateLimitResult {
  allowed: boolean;
  limit: number;
  remaining: number;
  /** Unix timestamp (ms) at which the oldest entry in the window expires. */
  resetAt: number;
}

/**
 * Redis sliding-window rate limiter.
 *
 * Uses a sorted set per identifier where each member is a unique request
 * timestamp. Old entries outside the window are pruned on each call.
 */
export async function checkRateLimit(
  identifier: string,
  config: RateLimitConfig,
): Promise<RateLimitResult> {
  const key = `rl:${config.keyPrefix}:${identifier}`;
  const now = Date.now();
  const windowStart = now - config.windowMs;

  try {
    const pipeline = redis.pipeline();
    // Remove entries older than the window.
    pipeline.zremrangebyscore(key, '-inf', windowStart);
    // Record this request; score = timestamp, member adds randomness for uniqueness.
    pipeline.zadd(key, now, `${now}:${Math.random().toString(36).slice(2)}`);
    // Count entries currently in the window.
    pipeline.zcard(key);
    // Expire the key after one full window so Redis doesn't accumulate stale keys.
    pipeline.pexpire(key, config.windowMs);

    const results = await pipeline.exec();

    const count = (results?.[2]?.[1] as number) ?? 0;
    const remaining = Math.max(0, config.max - count);

    return {
      allowed: count <= config.max,
      limit: config.max,
      remaining,
      resetAt: now + config.windowMs,
    };
  } catch (err) {
    // error-ux-auditor C4: a Redis outage previously 500'd every
    // rate-limited route — including login. Fail OPEN here so an
    // operator can still authenticate while Redis is being recovered.
    // The brief enforcement gap is acceptable; locking everyone out is
    // not. Log loudly so monitoring picks it up.
    logger.warn(
      { err, keyPrefix: config.keyPrefix },
      'rate-limit subsystem unavailable, allowing request (fail-open)',
    );
    return {
      allowed: true,
      limit: config.max,
      remaining: config.max,
      resetAt: now + config.windowMs,
    };
  }
}

/**
 * Returns standard rate-limit response headers from a RateLimitResult.
 */
export function rateLimitHeaders(result: RateLimitResult): Record<string, string> {
  return {
    'X-RateLimit-Limit': result.limit.toString(),
    'X-RateLimit-Remaining': result.remaining.toString(),
    'X-RateLimit-Reset': Math.ceil(result.resetAt / 1000).toString(),
  };
}

/**
 * Pre-configured rate limiters matching SECURITY-GUIDELINES.md §6.1.
 */
export const rateLimiters = {
  /** Auth endpoints: 5 attempts per 15 minutes per identifier. */
  auth: { windowMs: 15 * 60 * 1000, max: 5, keyPrefix: 'auth' },
  /** Authenticated API: 120 requests per minute. */
  api: { windowMs: 60 * 1000, max: 120, keyPrefix: 'api' },
  /** File uploads: 10 per minute. */
  upload: { windowMs: 60 * 1000, max: 10, keyPrefix: 'upload' },
  /** Bulk operations: 5 per minute. */
  bulk: { windowMs: 60 * 1000, max: 5, keyPrefix: 'bulk' },
  /** Hard-delete code requests: 5 per hour per user. Each request emails
   *  a fresh code; without the cap a compromised admin account could
   *  email-bomb the operator's inbox or use the endpoint as a client-id
   *  oracle. */
  hardDeleteCode: { windowMs: 60 * 60 * 1000, max: 5, keyPrefix: 'hard-delete-code' },
  /** Inbound webhook with bad secret: 10 attempts per 15 minutes per IP.
   *  Real webhooks won't fail the secret check, so any traffic here is
   *  enumeration / brute-force. Block beyond the cap with a 429. */
  webhookBadSecret: { windowMs: 15 * 60 * 1000, max: 10, keyPrefix: 'wh-bad-secret' },
  /** Receipt scanner: 10 OCR runs per minute per user. */
  ocr: { windowMs: 60 * 1000, max: 10, keyPrefix: 'ocr' },
  /** Server-side AI calls (summary, embeddings, etc): 60 per minute per user. */
  ai: { windowMs: 60 * 1000, max: 60, keyPrefix: 'ai' },
  /** Data exports (GDPR bundle, PDF, CSV): 30 per hour per user. */
  exports: { windowMs: 60 * 60 * 1000, max: 30, keyPrefix: 'export' },
  /** Public unauthenticated form posts (interest, residential inquiry): 5 per hour per IP. */
  publicForm: { windowMs: 60 * 60 * 1000, max: 5, keyPrefix: 'publicform' },
  /** Server-to-server intake from the marketing website's dual-write helper.
   *  All traffic shares the website's egress IP, so the bucket has to
   *  accommodate every legitimate inquiry the site can produce in an hour
   *  without dropping data. The shared-secret header gates abuse; this
   *  limiter is just a defensive backstop in case the secret leaks. */
  websiteIntake: { windowMs: 60 * 60 * 1000, max: 500, keyPrefix: 'websiteintake' },
  /** Portal sign-in: 5 attempts per 15min per (ip,email) bucket. Defends
   *  against credential stuffing on /api/portal/auth/sign-in. */
  portalSignIn: { windowMs: 15 * 60 * 1000, max: 5, keyPrefix: 'portal:signin' },
  /** Portal forgot-password: 3/hour/IP. Tighter than sign-in because it
   *  triggers an outbound email and is the primary email-enumeration
   *  vector (timing differences between known/unknown). */
  portalForgot: { windowMs: 60 * 60 * 1000, max: 3, keyPrefix: 'portal:forgot' },
  /** Portal activate / reset / set-password: 10/hour/IP. Bounds brute-
   *  force against the 32-byte token (random walk math is in our favour
   *  but a tight ceiling keeps the search space practically infeasible). */
  portalToken: { windowMs: 60 * 60 * 1000, max: 10, keyPrefix: 'portal:token' },
} as const satisfies Record<string, RateLimitConfig>;

export type RateLimiterName = keyof typeof rateLimiters;