Developer Advocate
Ir al canal en Telegram
1 035
Suscriptores
Sin datos24 horas
Sin datos7 días
-130 días
Archivo de publicaciones
1 035
مایکروسافت در مقاله جدید خود اعلام کرده است که قابلیت افزودن «عاملهای خودتان» (Bring Your Own Agents) را به Microsoft 365 Copilot فراهم کرده است. این ویژگی به توسعهدهندگان و سازمانها اجازه میدهد تا عاملهای هوشمند سفارشی خود را مبتنی بر هوش مصنوعی به اکوسیستم Microsoft 365 اضافه کنند و بدین شکل کارایی و شخصیسازی Copilot را افزایش دهند.
عاملهای سفارشی میتوانند وظایف خاص سازمان یا فرآیندهای ویژه کسبوکار را انجام دهند، به منابع داده داخلی متصل شوند، و به صورت یکپارچه با برنامههایی مانند Outlook، Teams، Word و سایر سرویسهای مایکروسافت همکاری کنند. مایکروسافت این قابلیت را با هدف قدرتبخشی بیشتر به کسبوکارها و توسعهدهندگان معرفی کرده و اعلام کرده است که ابزارهایی مبتنی بر Microsoft Teams Toolkit و Semantic Kernel برای ساخت و یکپارچهسازی این عاملها در دسترس قرار دارد.
همچنین توسعهدهندگان میتوانند با استفاده از Microsoft Graph API و مدل امنیتی Microsoft 365، اطمینان حاصل کنند که عاملهای سفارشی ساختهشده به همان استانداردهای امنیت و حریم خصوصی پایبند باشند که خود مایکروسافت رعایت میکند. با ورود این قابلیت، سازمانها میتوانند تجربه کاری کاربران خود را ارتقاء ببخشند، فرآیندها را خودکار کنند و پاسخهای هوشمندانهتر، دقیقتر و شخصیسازیشدهتر از Microsoft 365 Copilot دریافت نمایند.
https://devblogs.microsoft.com/microsoft365dev/bring-your-own-agents-into-microsoft-365-copilot
@DeveloperAdvocate 🥑
1 035
امروزه Delegateها و Eventها در C# فراتر از ابزارهای کلاسیک برای پیادهسازی observer pattern هستند. بهینهسازی نحوه استفاده از آنها، تأثیر مستقیمی در عملکرد و خوانایی کد در معماریهای مدرن دارد. چند نکته پیشرفته:
۱️⃣ در .NET Core و جدیدتر، MulticastDelegate نسبت به قبل کمهزینهتر است؛ اما اضافه و حذف event handlerها همچنان گرانی دارند—بهویژه اگر حجم eventها بالاست. تا حد امکان، از الگوهایی همچون
EventAggregator برای انتزاع و کنترل دقیق lifecycle handlerها استفاده کنید.
۲️⃣ وقتی عملکرد بحرانی است، توجه کنید که invocation مستقیم delegate (با null check) تا ۴ برابر سریعتر از استفاده از Event است. بهعنوان مثال:
public event EventHandler<EventArgs> MyEvent;
public void Raise()
{
MyEvent?.Invoke(this, EventArgs.Empty); // حدود 4 برابر کندتر از زیر است
// مقایسه:
_handler?.Invoke(this, EventArgs.Empty); // delegate مستقیم
}
private EventHandler<EventArgs> _handler;
WeakEventManager راه حل رسمی مایکروسافت است.
۴️⃣ از Func و Action هنگام عدم نیاز به EventArgsهای پیچیده بهره ببرید. این رویکرد به افزایش انعطاف و سادهسازی امضای متد منتهی میشود.
public event Action<string>? OnMessage;
1 035
🚀 افزایش کارایی ادراکشده با React Server Components (RSC) و استریمینگ محتوا
یکی از ویژگیهای تحولآفرین RSC، پشتیبانی از Stream کردن UI به سمت مرورگر است. به جای ارسال یکباره کل رندر اولیه (SSR)، میتوانید بخشهایی از UI را—حتی وقتی دادهها یا وابستگیهای برخی قطعات دیرتر حاضر میشوند—در جریانهای تدریجی به سمت کاربر ارسال کنید. این تکنیک به طور چشمگیری Time To First Byte (TTFB) و زمان نمایش اولین محتوای معنادار (FCP) را کاهش میدهد.
در ترکیب با ASP.NET Core و Node.js (مثلاً Next.js)، میتوانید خروجی رندر RSC را با قابلیت stream مستقیماً در پاسخ HTTP پیاده کنید:
app.MapGet("/streaming", async context =>
{
var rscProcess = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = "node",
Arguments = "render-rsc.js", // رندر صفحه React
RedirectStandardOutput = true,
UseShellExecute = false
}
};
rscProcess.Start();
context.Response.ContentType = "text/html; charset=utf-8";
using var nodeStream = rscProcess.StandardOutput.BaseStream;
await nodeStream.CopyToAsync(context.Response.Body); // Stream تا آخر
await rscProcess.WaitForExitAsync();
});
1 035
وقتی حرف از مصاحبه فنی میشه—چه در نقش مصاحبهکننده و چه داوطلب—دقت در عمق سؤالات و جوابها اهمیت حیاتی داره. در سمت مصاحبهکننده، سوالات باید حول مسائلی مثل design tradeoffها، concurrencies، testability، maintainability و scalability بچرخن—not “سینتکس حفظی”. به جای سوالات کلاسیک، یک سناریوی معماری مطرح کنید و از داوطلب انتظار داشته باشید استدلال کند که چرا فلان مدل رو انتخاب میکنه یا گزینههای دیگه چی بودن. مثلا:
public interface ICacheProvider
{
Task<T?> GetAsync<T>(string key, CancellationToken cancellationToken = default);
Task SetAsync<T>(string key, T value, TimeSpan expiry, CancellationToken cancellationToken = default);
}
1 035
مصاحبه فنی، چه در نقش مصاحبهگر و چه به عنوان متقاضی، یک بازی دوطرفه است و عمق بینش شما در هردو سو میتواند تفاوت کلیدی ایجاد کند. به عنوان مصاحبهگر، بهتر است فراتر از سؤالات تئوریک یا الگوریتمی بروید و عملاً روی مسائل دنیای واقعی محصول و زیرساخت تمرکز کنید: تحلیل معماری، تستپذیری، و trade-offهای تکنولوژیک. مثلا، بجای دانش خام Entity Framework، سناریویی پیرامون پرفورمنس migrationها و باید و نبایدهای استفاده از concurrency token مطرح کنید:
public class Order
{
public int Id { get; set; }
public decimal Amount { get; set; }
[Timestamp]
public byte[] RowVersion { get; set; }
}
1 035
در C# 12 و نسخههای بعدی، تحولاتی بنیادین در طراحی زبان و امکانات آن رخ داده که سطح انتزاع و قدرت مهندسی شما را ارتقا میدهد. اجازه دهید به دو قابلیت درخشان بپردازیم:
🔹 Collection Expressions
افزودن Collection Expressions، امکان تعریف آرایهها و مجموعهها را با سینتکسی سادهتر میدهد—تقریباً مشابه لیترالهای آرایه در زبانهایی مانند JavaScript، اما با پشتیبانی از انواع مختلفی مانند
List<T>, Span<T>, و حتی تایپهای سفارشی که ICollectionBuilder<T> را پیادهسازی کردهاند:
int[] arr = [1, 2, 3, 4];
List<string> names = ["Reza", "Sara", "Ehsan"];
Span<double> weights = [70.5, 80.1, 85];
.. (range spread) و آرایهها/لیستهایی که میخواهید ادغام کنید:
int[] numbers1 = [1, 2, 3];
int[] numbers2 = [4, 5];
int[] merged = [..numbers1, 100, ..numbers2]; // [1,2,3,100,4,5]
// Signature پیشنهادی
[InterceptsLocation("SomeFile.cs", line:42, column:13)]
public static void MyCustomInterceptor()
{
// رفتار دلخواه
}
1 035
🔐 بهترین شیوههای امنیت دیتابیس: رمزنگاری، اصل حداقل دسترسی و Audit
در معماریهای Enterprise، محافظت از دادههای حساس به چند لایه امنیتی نیاز دارد. بیایید سه رکن محکم امنیت دیتابیس را مرور کنیم:
1️⃣ رمزنگاری دادهها
دیتابیسها باید دادهها را هم در حالت سکون (
At Rest) و هم حین انتقال (In Transit) رمزنگاری کنند. توابع رمزنگاری در SQL Server (مثل Always Encrypted) و یا رمزنگاری End-to-End در EF Core، راهکارهایی استاندارد هستند، اما رمزگذاری سمت کلاینت یک سطح امنیتی بالاتر ایجاد میکند:
using System.Security.Cryptography;
using System.Text;
// رمزنگاری داده قبل از درج در دیتابیس
var plainText = "MySensitiveValue";
using var aes = Aes.Create();
aes.Key = Convert.FromBase64String("[YourBase64Key]");
aes.IV = Convert.FromBase64String("[YourBase64IV]");
using var encryptor = aes.CreateEncryptor();
var cipherBytes = encryptor.TransformFinalBlock(Encoding.UTF8.GetBytes(plainText), 0, plainText.Length);
// Save cipherBytes (as Base64) to DB
// فقط مجوز خواندن (SELECT)
// به جای اجازهی خواندن و نوشتن کامل
GRANT SELECT ON dbo.Customers TO MyAppUser;
public class AuditEntry
{
public string TableName { get; set; }
public string UserName { get; set; }
public DateTime ChangeTime { get; set; }
public string OldValues { get; set; }
public string NewValues { get; set; }
}
1 035
تعریف و همراستا کردن تیم با ویژن فنی چطور باید انجام شود؟ اگر ویژن را فقط یک اسلاید PowerPoint بدانیم، محکوم به تکرار دردسرهای گذشته هستیم. ویژن فنی باید منشأ تصمیمگیریهای عمیق، شفاف و الهامبخش باشد.
۱️⃣ تعریف ویژن در لایه Architecture: ویژن باید شفاف، قابل اندازهگیری و پایهی تمام تصمیمات تکنیکی باشد. به تیم نشان دهید به کجا میخواهیم برویم (مثلاً "گذار کامل به معماری event-driven تا انتهای سال"). این ویژن با نمونهکد، دیاگرام و حتی spike های اولیه ملموس میشود:
// نمونهای از تعریف پیام در CQRS + Event Sourcing
public class OrderCreatedEvent : INotification
{
public Guid OrderId { get; }
public DateTime CreatedAt { get; }
public OrderCreatedEvent(Guid orderId, DateTime createdAt)
{
OrderId = orderId;
CreatedAt = createdAt;
}
}
// نمونهای از یک ADR خیلی خلاصه
/*
ADR-003: Use MediatR for decoupled application layers.
Context: Need to avoid direct dependencies between layers.
Decision: Adopt MediatR for in-process messaging.
Status: Accepted
Consequences: Minimal coupling, easier to test.
*/
1 035
اگر با Azure App Service کار میکنید و به دنبال حداکثر کارایی، امنیت و قابلیت مانیتورینگ هستید، برخی تنظیمات پیشرفته را از دست ندهید:
🔹 VNet Integration: با ادغام App Service در Virtual Network، امکان دسترسی امن به منابع دیتابیس، APIها یا سرویسهای داخلی فراهم میشود. برای این کار کافیست از قسمت Networking > VNet Integration استفاده کنید. توجه کنید اگر به منابع داخل VNet نیاز دارید، App باید در حالت PremiumV2 یا بالاتر اجرا شود.
توصیه: اگر به outbound traffic کنترلشده نیاز دارید، از private endpoints استفاده کنید تا دیتا خارج از شبکه Azure منتقل نشود.
🔹 Deployment Slots: تعریف deployment slot جداگانه (مانند “staging”، “qa” یا “canary”) باعث کاهش downtime و ریسک انتشار میشود. میتوانید ترافیک را درصدی بین slotها تقسیم کنید یا حتی swap انجام دهید تا صفر-داونتایم deploy داشته باشید.
برای سواپ کردن اسلات در CI/CD، میتوانید از Azure CLI استفاده کنید:
az webapp deployment slot swap --resource-group MyResourceGroup --name MyUniqueApp --slot staging
{
"rule": {
"metricTrigger": {
"metricName": "CPUPercentage",
"threshold": 60,
"timeAggregation": "Average",
"operator": "GreaterThan",
"statistic": "Average",
"timeWindow": "PT5M"
},
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
}
}
}
var telemetry = new TelemetryClient();
telemetry.TrackException(exception);
telemetry.TrackTrace("پوشش کامل قابلیت مانیتورینگ");
1 035
تهدیدکاوی (Threat Modeling) ابزاری پیشرفته برای طراحی امنیتمحور است که به تیمها امکان میدهد آسیبپذیریها و تهدیدهای احتمالی را پیش از پیادهسازی شناسایی و رفع کنند. متدولوژی STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) یکی از مدلهای محبوب است که در .NET بهسادگی قابل پیادهسازی میباشد.
فرض کنید مشغول طراحی یک API هستید که باید ورود کاربران و مدیریت پروفایل را هندل کند. یک رویکرد عملی، تحلیل هر endpoint براساس STRIDE است:
- Spoofing: آیا مکانیزم احراز هویت بهاندازه کافی قوی است؟
- Tampering: دادههای ورودی و خروجی امضا یا رمزنگاری شدهاند؟
- Repudiation: آیا لاگهای کافی برای پیگیری اقدامات وجود دارد؟
- Information Disclosure: اطلاعات حساس (مانند JWT یا Connection String) در لاگها، Exceptionها یا Responseها نمایش داده نمیشوند؟
- Denial of Service: لحاظ کردن محدودیت نرخ درخواست (Rate Limiting) یا Circuit Breaker؟
- Elevation of Privilege: آیا کنترل سطح دسترسی بهدرستی پیادهسازی شده؟
مثال: محدود کردن اطلاعات لو رفته در Exception Handler
app.UseExceptionHandler(errorApp =>
{
errorApp.Run(async context =>
{
context.Response.StatusCode = 500;
context.Response.ContentType = "application/json";
var exceptionHandlerPathFeature =
context.Features.Get<IExceptionHandlerPathFeature>();
// Log full exception internally
Log.Error(exceptionHandlerPathFeature.Error, "Unhandled exception");
// Minimal info for client (no sensitive data)
await context.Response.WriteAsync("{\"error\":\"Internal Server Error\"}");
});
});
1 035
یکپارچهسازی لاگینگ با SIEM برای مدیریت رویدادهای امنیتی در .NET
در معماریهای مدرن، داشتن لاگهای جامع نهتنها برای تحلیل مشکلات بلکه برای کشف رخدادهای امنیتی حیاتی است. اما صرف جمعآوری لاگ کافی نیست؛ باید این لاگها را به صورت ساختارمند به SIEM (مثل Splunk، Azure Sentinel یا Elastic SIEM) ارسال کنیم تا آنالیز، هشدار و پاسخ خودکار به حملات میسر شود.
🔑 نکاتی برای پیادهسازی اثربخش:
- دستهبندی هوشمند لاگها: برای SIEM هر event باید شامل نوع رخداد، severity، identifier یکتا و context باشد (مثلاً userId، IP، endpoint، traceId).
- استفاده از Structured Logging: کتابخانههایی مثل Serilog اجازه میدهند لاگها را به فرمت JSON و با فیلدهای دلخواه ارسال کنید.
- Enrich کردن لاگها: اطلاعات حیاتی (مانند correlationId, user claims, request info) را به لاگ اضافه کنید تا جستجو و تحلیل در SIEM تسهیل شود.
- Export مستقیم: بسیاری SIEMها، ingestion API دارند. میتوانید Sink مخصوص آنها را به Serilog اضافه کنید.
نمونهی پیکربندی Serilog با Sink مستقیم به Seq یا ElasticSearch (قابل تعمیم برای SIEM):
using Serilog;
using Serilog.Sinks.Elasticsearch;
Log.Logger = new LoggerConfiguration()
.Enrich.FromLogContext()
.Enrich.WithProperty("Application", "MyApp")
.WriteTo.Console()
.WriteTo.Elasticsearch(new ElasticsearchSinkOptions(new Uri("http://elasticsearch:9200"))
{
AutoRegisterTemplate = true,
IndexFormat = "myapp-logs-{0:yyyy.MM.dd}"
})
// برای SIEMهایی مانند Splunk یا Sentinel میتوانید sink مناسب را جایگزین کنید
.CreateLogger();
logger.Warning("Failed login attempt", new {
UserId = user.Id,
Username = user.Username,
IP = httpContext.Connection.RemoteIpAddress,
Timestamp = DateTime.UtcNow
});
1 035
نکته کلیدی در ارزیابی بلوغ DevOps، سنجش و بهبود مستمر ۴ متریک DORA است:
1️⃣ Lead Time for Changes: زمان بین کامیت کد تا استقرار آن در محیط تولید. هرچه مقدار کمتر، پویایی تیم و بازخورد سریعتر است. با اتوماسیون تست و Deployment به شدت بهبود مییابد.
2️⃣ Deployment Frequency: تعداد استقرارهای موفق به پروڈاکشن در بازه زمانی مشخص (مثلاً روزانه یا هفتگی). تیمهایی با دفعات بیشتر، پذیرای تغییر و کمتر دچار “Big Bang Release” هستند.
3️⃣ Mean Time to Restore (MTTR): مدت زمان میان رخداد یک مشکل تا بازگردانی سرویس. Log مناسب، مانیتورینگ، و پروسه Incident Response سریع، MTTR را کاهش میدهند.
4️⃣ Change Failure Rate: درصد تغییرات استقرار یافته که نیاز به Rollback یا Hotfix پیدا میکنند. پوشش تست اتوماتیک و Canary Release این شاخص را بهبود میدهد.
برای رصد این متریکها میتوانید از Telemetry در Azure DevOps یا GitHub Actions بهره بگیرید. مثال ساده استخراج Deployment Frequency با استفاده از GitHub API:
using Octokit;
var client = new GitHubClient(new ProductHeaderValue("DoraMetrics"));
var deployments = await client.Repository.Deployment.GetAll("orgName", "repoName");
var lastWeek = DateTimeOffset.UtcNow.AddDays(-7);
var weeklyDeployCount = deployments.Count(d => d.CreatedAt >= lastWeek);
Console.WriteLine($"Weekly Deployments: {weeklyDeployCount}");
1 035
در معماری سرویسگرا، هماهنگی بین سرویسها معمولاً دو رویکرد اصلی دارد: Orchestration و Choreography. انتخاب درست میان این دو، تأثیر زیادی بر مقیاسپذیری و مانیتورینگ سیستمهای توزیعشده دارد.
🔹 Orchestration (مدیریت متمرکز):
در این مدل، یک سرویس مرکزی (اورکستراتور) کل فرآیند را کنترل و ترتیب اجرای سرویسها را مشخص میکند. کتابخانههایی مثل MassTransit یا Dapr Workflow پیادهسازی مناسبی برای این الگو در .NET ارائه میدهند.
public class OrderOrchestrator
{
public async Task<OrderResult> ProcessOrder(Order order)
{
var validated = await _validator.Validate(order);
var reserved = await _inventory.Reserve(validated);
var paid = await _payment.Process(reserved);
return paid.IsSuccess ? OrderResult.Success : OrderResult.Failure;
}
}
public class InventoryService
{
[CapSubscribe("OrderValidated")]
public async Task OnOrderValidated(OrderValidatedEvent evt)
{
// منبع را رزرو کن و رخداد بعدی ارسال کن
await _inventory.Reserve(evt.OrderId);
await _messageBus.PublishAsync("InventoryReserved", new { evt.OrderId });
}
}
1 035
در معماری Zero-Trust، هیچ چیزی پیشفرض قابل اعتماد نیست؛ هر درخواست (چه داخلی چه خارجی) باید به طور مستقل اعتبارسنجی و احراز هویت شود. پیادهسازی این رویکرد در سیستمهای enterprise .NET یعنی جداسازی لایهها از طریق service boundaries، بررسی Context کاربر، و اصرار بر prinsip «کمترین مجوز» (Least Privilege). استفاده از middleware های Authorize و Policy-based authorization، validation pipeline و حتی mutual TLS (mTLS) میان سرویسها توصیه میشود.
نمونهای از middleware ساده اما موثر برای enforce کردن احراز هویت و انجام Logging بر هر درخواست:
public class ZeroTrustMiddleware
{
private readonly RequestDelegate _next;
private readonly ILogger<ZeroTrustMiddleware> _logger;
public ZeroTrustMiddleware(RequestDelegate next, ILogger<ZeroTrustMiddleware> logger)
{
_next = next;
_logger = logger;
}
public async Task Invoke(HttpContext context)
{
// احراز هویت
if (!context.User.Identity.IsAuthenticated)
{
_logger.LogWarning("Unauthorized access attempt to: {Path}", context.Request.Path);
context.Response.StatusCode = StatusCodes.Status401Unauthorized;
return;
}
// تایید Policy
// (در سیستم واقعی، چک کردن policyهای مرتبط اضافه میشود)
await _next(context);
}
}
// ثبت در pipeline
app.UseMiddleware<ZeroTrustMiddleware>();
1 035
🌐 ترفند معمارانه: Intercepting Object Operations با Proxy و Reflect در #NET
آیا تا به حال نیاز داشتهاید رفتار دسترسی به آبجکتهایتان را به صورت real-time و با انعطاف بالا کنترل کنید؟ در .NET 6+ میتوان مشابه پراکسیهای دنیای جاواسکریپت، با بهرهگیری از
DispatchProxy و برخی تکنیکهای پیشرفته، interception لایه transport و حتی reactive object behaviors ایجاد کنید.
📌 یک سناریوی کاربردی، ایجاد کلاسهایی است که بر روی propertyها عملیات logging، validation یا حتی event publishing انجام میدهند—بدون تغییر در منطق Domain اصلی:
public interface IUserService
{
string GetUserName(int userId);
void UpdateUserName(int userId, string newName);
}
public class UserService : IUserService
{
// پیادهسازی استاندارد
}
public class LoggingProxy<T> : DispatchProxy
{
private T _decorated;
protected override object Invoke(MethodInfo targetMethod, object[] args)
{
Console.WriteLine($"Calling: {targetMethod.Name}");
var result = targetMethod.Invoke(_decorated, args);
Console.WriteLine($"Done: {targetMethod.Name}");
return result;
}
public static T Create(T decorated)
{
object proxy = Create<T, LoggingProxy<T>>();
((LoggingProxy<T>)proxy)._decorated = decorated;
return (T)proxy;
}
}
// استفاده:
var service = new UserService();
var loggedService = LoggingProxy<IUserService>.Create(service);
loggedService.UpdateUserName(1, "Ali");
1 035
در اکوسیستم مایکروسرویسها، تضمین اتمیک بودن تراکنشها میان چند سرویس یا دیتابیس یکی از چالشهای بزرگ معماری است. رویکرد کلاسیک با استفاده از پروتکلهایی مثل XA یا MS DTC (Distributed Transaction Coordinator) سعی میکند از طریق 2PC (Two-Phase Commit) یک تراکنش گسترده را تضمین کند. اما استفاده از این الگوها در محیط مایکروسرویس:
- کارایی را کم میکند (latency بالا به خاطر قفل منابع)
- محدودیت مقیاسپذیری ایجاد میکند
- وابستگی شدید بین سرویسها به وجود میآورد (coupling)
- غالباً پشتیبانی خوبی در محیطهای cloud-native ندارند
به همین دلیل بیشتر معماران به سراغ راهحلهای جایگزین میروند. یکی از الگوهای پراستفاده، الگوی SAGA است که با رویکرد eventual consistency و تعریف جبران (compensation) به جای rollback، شل بودن تراکنش را مدیریت میکند. در این الگو، هر سرویس یک عملیات محلی را کامیت میکند و در صورت نیاز، با استفاده از پیام (event) عملیات جبرانی اجرا میشود.
نمونهای از یک Saga Coordinator ساده با استفاده از پیامرسان (مثلاً MassTransit):
public class PaymentSaga : MassTransitStateMachine<PaymentState>
{
public PaymentSaga()
{
InstanceState(x => x.CurrentState);
Event(() => OrderCreated, x => x.CorrelateById(context => context.Message.OrderId));
Initially(
When(OrderCreated)
.ThenAsync(context => ProcessPayment(context.Instance, context.Data))
.TransitionTo(Processing)
);
During(Processing,
When(PaymentProcessed)
.ThenAsync(context => CompleteOrder(context.Instance, context.Data))
.TransitionTo(Completed),
When(PaymentFailed)
.ThenAsync(context => Compensate(context.Instance, context.Data))
.TransitionTo(Failed)
);
}
//...
}
1 035
🔐 عمیقتر از سطح: هویت و مجوزدهی پیشرفته با ASP.NET Core Identity و OAuth 2.0/OIDC
اگر فقط به Default Identity رضایت دادهاید، بخش بزرگی از قدرت ASP.NET Core را از دست دادهاید. بیایید یک سناریوی جدیتر بسازیم:
- ادغام تامینکنندههای خارجی (مثل Google و Azure AD)
- تعریف سیاستهای مجوزدهی چندلایه و داینامیک
۱️⃣. افزودن Google OAuth 2.0 و Azure AD به پروژه:
ابتدا NuGet package های زیر را اضافه کنید:
-
Microsoft.AspNetCore.Authentication.Google
- Microsoft.AspNetCore.Authentication.AzureAD.UI
سپس، در Startup یا Program:
builder.Services.AddAuthentication()
.AddGoogle(googleOptions =>
{
googleOptions.ClientId = Configuration["Authentication:Google:ClientId"];
googleOptions.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
})
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
builder.Services.AddAuthorization(options =>
{
options.AddPolicy("RequireItAdmin", policy =>
{
policy.RequireClaim("department", "IT")
.RequireRole("Admin");
});
});
[Authorize(Policy = "RequireItAdmin")]
public IActionResult SecureArea() { ... }
builder.Services.Configure<OAuthOptions>(GoogleDefaults.AuthenticationScheme, options =>
{
options.Events.OnCreatingTicket = async context =>
{
// افزودن Custom Claim
var identity = (ClaimsIdentity)context.Principal.Identity;
identity.AddClaim(new Claim("ExternalProvider", "Google"));
};
});
public class DocumentOwnerRequirement : IAuthorizationRequirement { }
public class DocumentOwnerHandler : AuthorizationHandler<DocumentOwnerRequirement, Document>
{
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
DocumentOwnerRequirement requirement, Document resource)
{
var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
if (resource.OwnerId == userId)
context.Succeed(requirement);
return Task.CompletedTask;
}
}
builder.Services.AddScoped<IAuthorizationHandler, DocumentOwnerHandler>();
options.AddPolicy("OwnerOnly", policy =>
policy.Requirements.Add(new DocumentOwnerRequirement()));
1 035
در معماری مدرن داتنت، انتخاب صحیح بین کلاسها، رکوردها و نحوه ساختاردهی دادهها نقش کلیدی در سادگی و سُرعت توسعه دارد. با معرفی primary constructor در C# 12، قدرت رکوردها برای مدلسازی دادههای "غیر قابل تغییر" (immutable) بیشتر شده است.
🔹 تفاوت رکورد و کلاس:
- اگر هدف شما مدلسازی داده است که تنها حامل اطلاعات است و نباید هویت معنایی مستقل داشته باشد (مثل DTOها یا Value Objectها)، رکورد انتخاب بهتری است.
- رکوردها پشتیبانی فوقالعادهای از value equality، با الگوی deconstructor و قابلیت رفتار جالب copy-with میدهند.
🔹 Primary Constructor در رکوردها:
در C# 12 میتوانید پارامترهای سازنده را مستقیماً در سرخط record تعریف کنید؛ این باعث شفافیت و کوتاهی کد میشود.
public record Customer(string FirstName, string LastName, int Age);
public class Product(string name, int price)
{
public string Name { get; } = name;
public int Price { get; } = price;
}
1 035
مدیریت آسیبپذیری (Vulnerability Management) تنها یک چکباکس برای compliance نیست، بلکه بخشی کلیدی از فرآیند اطمینانبخشی به دوام و امنیت اکوسیستم نرمافزاری است. یک رویکرد عملی و صنعتی معمولاً شامل سه مرحله کلیدی است: ۱) اسکن آسیبپذیری (Vulnerability Scanning)، ۲) پچ کردن (Patching) و ۳) رفع (Remediation).
در داتنت، میتوانید با ابزارهایی چون dotnet list package --vulnerable و OWASP Dependency Check کتابخانههای آسیبپذیر را شناسایی کنید. برای اسکن Application-level، Static Analysis Tools مانند SonarQube یا dotnet-format قابل استفادهاند.
یک مثال عملی از شناسایی بستههای ناامن:
// اجرای این دستور در دایرکتوری پروژه، پکیجهای آسیبپذیر را فهرست میکند:
dotnet list package --vulnerable
// در فایل csproj:
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
1 035
در دنیای Serverless، مشکل Cold Start برای توابع .NET در هر دو Azure Functions و AWS Lambda یکی از چالشهای کلیدیست—بهویژه برای اپلیکیشنهای حساس به تأخیر.
دلیل اصلی، زمان لازم برای بارگذاری runtime، JIT و dependency injection containerهاست. برای مهندسان فنی، اینها پیشنهادهای قابل اجرا هستند:
🔹 استفاده از Native AOT (در لاندا AWS & Azure Functions با پشتیبانی پیشنمایش):
با Native AOT در .NET 8 میتوانید startup time را بهشدت کاهش دهید—کماکان باید dependencyهای unmanaged و reflection را مدیریت کنید.
// پروژهتان را به نوع exe و حالت Native AOT تنظیم کنید
<PropertyGroup>
<PublishAot>true</PublishAot>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
<SelfContained>true</SelfContained>
</PropertyGroup>
