Claude Code Plugins

Community-maintained marketplace

Feedback

middleware-protection

@vanman2024/ai-dev-marketplace
0
0

Route protection and authorization patterns for Clerk middleware. Use when implementing route guards, protecting API routes, configuring middleware matchers, setting up role-based access control, creating auth boundaries, or when user mentions middleware, route protection, auth guards, protected routes, public routes, matcher patterns, or authorization middleware.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name middleware-protection
description Route protection and authorization patterns for Clerk middleware. Use when implementing route guards, protecting API routes, configuring middleware matchers, setting up role-based access control, creating auth boundaries, or when user mentions middleware, route protection, auth guards, protected routes, public routes, matcher patterns, or authorization middleware.
allowed-tools Read, Write, Edit, Bash, Glob

Middleware Protection

Comprehensive route protection and authorization patterns for Clerk middleware in Next.js applications. Provides middleware configuration, route matchers, role-based access control, and authentication boundaries.

Core Concepts

Middleware Architecture

  • Edge Runtime: Clerk middleware runs on Cloudflare Workers/Vercel Edge
  • Request Interception: Middleware executes before route handlers
  • Auth State: Access to authentication state via auth() helper
  • Matcher Patterns: Configure which routes middleware applies to

Route Protection Levels

  1. Public Routes: Accessible without authentication (sign-in, sign-up, landing pages)
  2. Protected Routes: Require authentication (dashboards, user profiles)
  3. Organization Routes: Require organization membership
  4. Role-Based Routes: Require specific roles or permissions

Security Principles

  • Deny by Default: All routes protected unless explicitly made public
  • Defense in Depth: Middleware + server component checks + API route guards
  • Session Validation: Automatic token validation on every request
  • CSRF Protection: Built-in protection against cross-site request forgery

Instructions

Basic Middleware Setup

  1. Create middleware.ts in project root

    • Import clerkMiddleware from @clerk/nextjs/server
    • Export default middleware function
    • Configure matcher for routes to protect
  2. Configure Public Routes

    • Define routes accessible without authentication
    • Use glob patterns for route matching
    • Include sign-in/sign-up pages as public
  3. Set Protected Routes

    • Specify which routes require authentication
    • Use route groups for organization
    • Apply different protection levels

Advanced Patterns

  1. Role-Based Access Control

    • Check user roles in middleware
    • Redirect based on permissions
    • Implement organization-level permissions
  2. Conditional Route Protection

    • Apply different rules based on route patterns
    • Check custom metadata
    • Implement feature flags
  3. API Route Protection

    • Secure API endpoints with middleware
    • Validate session tokens
    • Check permissions before processing
  4. Multi-Tenant Protection

    • Organization-scoped routes
    • Tenant isolation
    • Cross-organization access prevention

Testing Protection

  1. Test Authentication Boundaries

    • Verify unauthenticated redirects
    • Check protected route access
    • Validate role requirements
  2. Test Edge Cases

    • Token expiration handling
    • Invalid session handling
    • Missing organization membership

Templates

Use these templates for middleware implementation:

Core Templates

  • templates/middleware.ts - Basic middleware configuration
  • templates/route-matchers.ts - Route matching patterns
  • templates/role-based-middleware.ts - Role-based access control

Configuration Templates

  • templates/public-routes-config.ts - Public route definitions
  • templates/protected-routes-config.ts - Protected route setup
  • templates/api-middleware-config.ts - API route protection

Advanced Templates

  • templates/organization-middleware.ts - Organization-scoped protection
  • templates/conditional-middleware.ts - Conditional route logic
  • templates/custom-redirects.ts - Custom redirect handling

Scripts

Use these scripts for middleware setup and testing:

  • scripts/generate-middleware.sh - Generate middleware.ts with configuration
  • scripts/configure-routes.sh - Setup route protection patterns
  • scripts/test-protection.sh - Test authentication guards and boundaries
  • scripts/validate-middleware.sh - Validate middleware configuration

Examples

See complete examples in the examples/ directory:

Basic Examples

  • examples/basic-middleware.ts - Simple middleware setup
  • examples/public-private-routes.ts - Public vs protected routes
  • examples/api-middleware.ts - API route protection

Advanced Examples

  • examples/role-based-protection.ts - Role-based access control
  • examples/organization-routes.ts - Organization-scoped routes
  • examples/conditional-routing.ts - Conditional protection logic
  • examples/custom-auth-flow.ts - Custom authentication flows

Testing Examples

  • examples/middleware-tests.ts - Middleware unit tests
  • examples/integration-tests.ts - Full protection integration tests

Security Best Practices

API Key Handling

CRITICAL: When generating middleware configuration:

  • ❌ NEVER hardcode CLERK_SECRET_KEY or NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
  • ❌ NEVER include real API keys in examples
  • ✅ ALWAYS use placeholders: your_clerk_secret_key_here
  • ✅ ALWAYS read from environment variables: process.env.CLERK_SECRET_KEY
  • ✅ ALWAYS add .env* to .gitignore (except .env.example)
  • ✅ ALWAYS document where to obtain keys from Clerk Dashboard

Middleware Security

  1. Validate All Requests: Don't skip middleware on any protected routes
  2. Check Session Validity: Always validate session tokens
  3. Implement Rate Limiting: Protect against brute force attacks
  4. Log Security Events: Track authentication failures and suspicious activity
  5. Use HTTPS Only: Never run authentication over HTTP in production

Requirements

Next.js Version:

  • Next.js 13.4+ (App Router support)
  • Next.js 12+ (Pages Router support)

Clerk SDK:

  • @clerk/nextjs 4.0+ (latest stable)
  • Node.js 16+

Configuration Files:

  • .env.local with Clerk environment variables
  • middleware.ts in project root
  • .gitignore protecting secrets

Common Patterns

Pattern 1: Public Landing + Protected Dashboard

// Public: /, /about, /pricing
// Protected: /dashboard/*, /profile/*
// Matcher: Protect everything except public routes

Pattern 2: API Route Protection

// Protect all /api/* except /api/webhooks/clerk
// Validate session tokens on protected endpoints
// Return 401 for unauthenticated requests

Pattern 3: Organization-Scoped Routes

// Require organization membership for /org/*
// Check active organization in middleware
// Redirect to organization selection if needed

Pattern 4: Role-Based Access

// Check user roles in middleware
// Redirect based on permissions (admin vs user)
// Implement feature-specific access control

Troubleshooting

Common Issues

  1. Middleware Not Running

    • Check matcher configuration
    • Verify middleware.ts location (project root)
    • Ensure Next.js version supports middleware
  2. Infinite Redirect Loops

    • Sign-in page must be public
    • Check redirect logic in middleware
    • Verify afterSignInUrl configuration
  3. Protected Routes Accessible

    • Verify matcher includes routes
    • Check auth state validation
    • Ensure middleware executes before route
  4. Session Not Found

    • Check environment variables loaded
    • Verify Clerk keys are correct
    • Ensure cookies not blocked

Purpose: Provide comprehensive middleware protection patterns for Clerk authentication Load when: Implementing route guards, protecting routes, setting up middleware, configuring auth boundaries