پیاده سازی «محدود سازی نرخ دسترسی به منابع در برنامههای ASP.NET Core» هم باید در این موارد مدنظر باشد.
نظرات مطالب
استفاده از افزونهی jsTree در ASP.NET MVC
با سلام برای پیاده سازی مثال جاری در asp.net core چه مواردی باید مد نظر قرار داد؟
مباحث تکمیلی در مورد AntiForgery و نحوه پیاده سازی به صورت عمومی و همیشگی در Asp.net Core
- اگر فکر میکنید که 2 بار چک کردن به ازای هر درخواست زیاد هست، احتمالا با ASP.NET Identity کار نکردید! در ASP.NET Identity اگر بررسی اعتبار کاربر را به ازای هر درخواست رسیده فعال کنید (بجای مقدار پیشفرض چند دقیقهای آن، این مقدار را صفر کنید تا به ازای هر درخواست انجام شود)، همین یک مورد 5 کوئری را شامل میشود. برای نمونه در ASP.NET Core 2.X این بررسیها شامل 5 کوئری به جداول AspNetUser, AspNetUserClaims, AspNetUserRoles, AspNetRoles, AspNetRoleClaims هستند.
- 2 بار بررسی بانک اطلاعاتی برای بانکهای اطلاعاتی امروزی هیچ سرباری ندارد و ضمن اینکه خودشان مباحث کش کردن اطلاعات ویژهای را هم برای کوئریهای پر استفاده دارند؛ مانند buffer cache در SQL Server که تا حد مصرف حافظهی کل سرور هم میتواند پیش رود.
- استفاده از متغیرهای استاتیک و حافظهی سرور برای کش کردن، مقیاس پذیر نیست. در این موارد روش توصیه شده، استفاده از بانک اطلاعاتی Key/Value فوق سریع Redis هست. فقط مشکل تمام کشها، هماهنگ سازی اطلاعات آنها با بانک اطلاعاتی اصلی است که باید مدنظر باشند.
- تمام APIهای ASP.NET Core که از Regex استفاده میکنند، به همراه timeout توکار هم هستند (^ و ^ و ^).
ASP.NET Core framework APIs that use RegularExpressions pass a timeout.
<aspNetCore requestTimeout="00:00:40"> </aspNetCore>
در نسخه dotnet Core 2.1 گویا از سیستم جدیدی تحت عنوان Razor UI In Class استفاده شده که طبق این لینک جهت مدیریت و پیاده سازی Identity نیز بهره برده شده و تمام مواردی که مربوط به احراز هویت و سطح دسترسی و غیره بوده در این سیستم متمرکز شده .
نظرات مطالب
امن سازی برنامههای ASP.NET Core توسط IdentityServer 4x - قسمت هشتم- تعریف سطوح دسترسی پیچیده
در Identity Server، دسترسیهای کاربران بر اساس User Claims آنها تعریف میشوند؛ مانند مثال ()public static List<TestUser> GetUsers مطلب جاری. بنابراین تعدادی Claims را به نامهای SuperAdmin1 تا n، به کاربران SuperAdmin ای که مدنظر هستند، انتساب میدهید. سپس سایر کاربران زیر مجموعهی آنها هم Claims جدیدی مانند SuperAdmin1_User تا n را خواهند داشت. بعد از تعریف این Claims، نحوهی دادن دسترسیها دقیقا مانند مثال CanOrderFrame مطلب فوق است. یک Policy جدید را مانند SuperAdmin1User_Policy تعریف میکنید که policyBuilder.RequireClaim آن بر اساس Claim ای مانند SuperAdmin1_User کار کند. سپس قسمتی که قرار است صرفا با این Policy کار کند، توسط [Authorize(Policy = " SuperAdmin1User_Policy")] محدود میشود.
ASP.NET Core Identity هم چنین طراحی مبتنی بر User Claims «تک» برنامهای هم دارد. بحث جاری در مورد طراحی «چند» برنامهای Identity Server هست.