🧑‍💻 محدودسازی نرخ کاربران بر اساس هویت (Identity)

اگر از کاربران می‌خواهید که در API شما احراز هویت (Authenticate) کنند، می‌توانید تشخیص دهید که کاربر فعلی کیست. سپس می‌توانید از هویت (Identity) کاربر به عنوان کلید پارتیشن (Partition Key) برای یک RateLimitPartition استفاده کنید. 🆔

💻 پیاده‌سازی محدودسازی با هویت کاربر

در اینجا نحوه ایجاد چنین سیاست محدودسازی نرخ آمده است:

builder.Services.AddRateLimiter(options =>
{
    options.AddPolicy("fixed-by-user", httpContext =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: httpContext.User.Identity?.Name?.ToString(),
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 10,
                Window = TimeSpan.FromMinutes(1)
            }));
});

من از مقدار User.Identity در HttpContext استفاده می‌کنم تا Claim مربوط به Name کاربر فعلی را به دست آورم. این معمولاً متناظر با Claim با نام sub درون یک JWT است - که همان شناسه کاربر می‌باشد.

🛡 اعمال Rate Limiting روی Reverse Proxy

در یک پیاده‌سازی قوی، شما می‌خواهید محدودسازی نرخ را در سطح Reverse Proxy اعمال کنید، پیش از آنکه درخواست به API شما برسد. و اگر یک سیستم توزیع شده دارید، این یک الزام است. در غیر این صورت، سیستم شما به درستی کار نخواهد کرد. 🚨

پیاده‌سازی‌های متعددی برای Reverse Proxy وجود دارد که می‌توانید از بین آن‌ها انتخاب کنید.

YARP
یک Reverse Proxy با یکپارچگی عالی با NET. است. این امر تعجب‌آور نیست، زیرا YARP با #C نوشته شده است.

⚙️ اعمال Rate Limiting در تنظیمات YARP

برای پیاده‌سازی محدودسازی نرخ روی Reverse Proxy با استفاده از YARP، شما باید:

یک سیاست محدودسازی نرخ تعریف کنید (همانند مثال‌های قبلی).

RateLimiterPolicy
را برای مسیر (Route) در تنظیمات YARP پیکربندی کنید:

"products-route": {
  "ClusterId": "products-cluster",
  "RateLimiterPolicy": "sixty-per-minute-fixed",
  "Match": {
    "Path": "/products/{**catch-all}"
  },
  "Transforms": [
    { "PathPattern": "{**catch-all}" }
  ]
}

توجه به حافظه: Middleware محدودسازی نرخ داخلی، از یک حافظه in-memory برای ردیابی تعداد درخواست‌ها استفاده می‌کند. اگر می‌خواهید Reverse Proxy خود را در یک راه‌اندازی با در دسترس بودن بالا (High-Availability) اجرا کنید، به استفاده از یک Distributed Cache نیاز خواهید داشت. استفاده از یک Redis backplane برای محدودسازی نرخ، یک گزینه خوب برای بررسی است. 💾

📝 سخن پایانی

با استفاده از PartitionedRateLimiter می‌توانید به راحتی سیاست‌های محدودسازی نرخ جزئی (Granular) ایجاد کنید.

دو رویکرد رایج عبارتند از:

محدودسازی نرخ بر اساس آدرس IP 🌐

محدودسازی نرخ بر اساس شناسه کاربر (User Identifier) 👤

تیم NET. محدودسازی نرخ را ارائه کرد که بسیار شگفت انگیز است. اما پیاده‌سازی فعلی کاستی‌هایی دارد. مشکل اصلی این است که فقط به صورت in-memory کار می‌کند. برای یک راهکار توزیع شده (distributed)، شما باید خودتان چیزی پیاده‌سازی کنید یا از یک کتابخانه خارجی استفاده نمایید.

شما می‌توانید از Reverse Proxy YARP برای ساختن سیستم‌های توزیع شده قوی و مقیاس‌پذیر استفاده کنید. و اضافه کردن Rate Limiting در سطح Reverse Proxy تنها به چند خط کد نیاز دارد. بهتر است که به طور گسترده‌ای از آن در سیستم‌هایمان استفاده می‌کنیم.

از اینکه این مقاله را خواندید، متشکرم. و فوق‌العاده بمانید! ✨

🔖 هشتگ‌ها:
#DotNet #RateLimiting #Security #ASPNETCore #ReverseProxy #IPAddress