https://virgool.io/feed/@miladj fa 2026-06-16 11:01:34 https://files.virgool.io/upload/users/1896536/avatar/n5JDl0.jpg?height=120&width=120 https://virgool.io/@miladj https://virgool.io/@miladj/%D8%A2%D8%B3%DB%8C%D8%A8-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-angular-ssr-%D9%86%D8%B4%D8%AA-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A8%D9%87-%D8%AF%D9%84%DB%8C%D9%84-race-condition-%D8%AF%D8%B1-platform-injector-c161mr7cquf5 در نسخه‌های خاصی از Angular SSR، یک آسیب‌پذیری امنیتی کشف شده که می‌تواند باعث نشت داده بین درخواست‌های هم‌زمان شود. این مشکل به دلیل استفاده از یک متغیر سراسری (global) برای نگهداری وضعیت تزریق وابستگی‌ها (Dependency Injection) در سمت سرور رخ می‌دهد.جزئیات آسیب‌پذیریAngular برای نگهداری وضعیت مربوط به هر درخواست در SSR از یک container به نام platform injector استفاده می‌کند. این container به‌صورت یک متغیر سراسری در سطح ماژول جاوااسکریپت تعریف شده بود. در شرایطی که چند درخواست به‌طور هم‌زمان پردازش شوند، این متغیر می‌تواند به اشتباه بین درخواست‌ها به اشتراک گذاشته شود یا بازنویسی شود. نتیجه‌ی این رفتار، ارسال داده‌های مربوط به یک درخواست در پاسخ به درخواست دیگر است—که می‌تواند شامل اطلاعات حساس یا توکن‌ها باشد.نسخه‌های آسیب‌پذیرماژول‌های زیر تحت تأثیر قرار گرفته‌اند:@angular/platform-server: نسخه‌های 16.0.0 تا قبل از 18.2.14، 19.0.0 تا قبل از 19.2.15، 20.0.0 تا قبل از 20.3.0، و 21.0.0 تا قبل از 21.0.0-next.3@angular/ssr: نسخه‌های مشابه با بالا@nguniversal/common: نسخه‌های 16.0.0 تا 16.2.0راه‌حل‌ها و اصلاحاتAngular تغییراتی در APIهای SSR اعمال کرده تا از بروز این مشکل جلوگیری شود:تابع bootstrapApplication اکنون نیاز به آرگومان جدیدی به نام BootstrapContext دارد.توابع getPlatform و destroyPlatform در محیط سرور دیگر رفتار قبلی را ندارند و به‌صورت امن بازنویسی شده‌اند.برای پروژه‌هایی که از CommonEngine استفاده می‌کنند، آرگومان context به تنظیمات bootstrap اضافه شده است.برای اعمال اصلاحات، می‌توان از دستور ng update استفاده کرد. به‌عنوان مثال:ng update @angular/cli @angular/coreیا برای نسخه‌های خاص:ng update @angular/core@19 --name add-bootstrap-context-to-server-mainاقدامات پیشگیرانهغیرفعال‌سازی SSR در مسیرهای سرور یا تنظیمات builderحذف رفتارهای ناهمگام در توابع bootstrap سفارشیعدم استفاده از getPlatform() در کد برنامهاطمینان از اینکه ngJitMode در ساخت سرور برابر false باشدشدت آسیب‌پذیریاین آسیب‌پذیری با امتیاز 7.1 از 10 در سیستم CVSS طبقه‌بندی شده و در دسته‌ی «شدید» قرار می‌گیرد.لینک منبع:Angular SSR: Global Platform Injector Race Condition Leads to Cross-Request Data Leakage · Advisory · angular/angular میلاد جعفری میلاد جعفری Wed, 17 Sep 2025 11:57:38 +0330 https://virgool.io/@miladj/%D8%B3%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D8%AF-%D8%A8%D8%A7-%D9%82%D8%AF%D8%B1%D8%AA-deconstruction-%D8%AF%D8%B1-csharp-bxggvdvuycus در دنیای توسعه نرم‌افزار، نوشتن کدی که هم خوانا باشد و هم قابل نگهداری، یک هنر است. یکی از ویژگی‌هایی که زبان #CSharp در اختیار ما گذاشته، قابلیت Deconstruction است؛ راهی هوشمند برای استخراج مقادیر از توابع، اشیاء، رکوردها و حتی دیکشنری‌ها.👨‍💻 Deconstruction چیست؟ به جای نوشتن چند خط برای استخراج مقادیر از Tuple یا Property‌های یک شیء، با Deconstruction می‌توانیم همه چیز را در یک خط انجام دهیم:var (city, population, area) = QueryCityData("New York City");📦 کجا می‌توان استفاده کرد؟TupleهاRecordهاکلاس‌های شخصی‌سازی شده با متد Deconstructحتی KeyValuePair در Dictionary‌ها🎯 مزایاخوانایی بهتر کدنگهداری ساده‌ترتمرکز روی مقادیر مورد نیاز (Discards با _)🚀 نمونه کاربردی: اگر تنها به برخی مقادیر Tuple نیاز دارید، کافیست از _ برای نادیده گرفتن سایر عناصر استفاده کنید:var (_, _, _, pop1960, _, pop2010) = QueryCityDataForYears("NYC", 1960, 2010); Console.WriteLine($"Population change: {pop2010 - pop1960:N0}");🧩 برای کلاس‌های خودتان هم می‌توانید متد Deconstruct بنویسید تا قابلیت تجزیه‌پذیری داشته باشند. حتی با Extension Method می‌توان این ویژگی را به کلاس‌هایی افزود که خودتان ننوشته‌اید! میلاد جعفری میلاد جعفری Mon, 04 Aug 2025 09:10:25 +0330 https://virgool.io/@miladj/%D8%A7%D8%AC%D8%AA%D9%86%D8%A7%D8%A8-%D8%A7%D8%B2-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-effect-%D8%AF%D8%B1-%D8%A7%D9%86%DA%AF%D9%88%D9%84%D8%A7%D8%B1-bv7gedgkx3sh این مقاله برگرفته از صحبتهای Alex Rickabaugh، یکی از اعضای تیم انگولار، درباره اجتناب از استفاده‌ی effect و معرفی راه‌حل‌های جایگزین در state management در انگولار است.تا آنجایی که توانستم، سعی کردم بخاطر آشنایی با مفاهیم اولیه، از کلمات و واژه‌های انگلیسی، که روزانه با آنها درگیر هستیم، استفاده کنم که خواننده‌ها، ذهنشون درگیر معنی کلمات نشود.مقدمهدر دنیای Reactive Programming در انگولار، استفاده از signal و computed signal به توسعه‌دهندگان اجازه می‌دهد تا به صورت مستقیم و با هماهنگی، تغییرات در UI را مدیریت کنند. effect ابزاری است که برای هماهنگ‌سازی بین بخش‌های Reactive (مثل signal و computed ) و دنیای Non-Reactive (مانند به‌روز‌رسانی یک المان DOM) طراحی شده‌ است. هرچند این ابزار قدرتمند و انعطاف‌پذیر هست، اما استفاده از آن‌ می‌تواند مشکلات و چالش‌هایی به همراه داشته باشد.مشکلات استفاده از effectناهماهنگی‌های زمان‌بندی: effect به صورت غیرهم‌زمان (asynchronously) اجرا می‌شود. این بدان معناست که وقتی signal مرتبط تغییر می‌کنند، effect ممکن است با تاخیر اجرا شود. به عنوان مثال، در سناریویی که یک کامپوننت select دارای یک items و یک selected Item انتخاب شده است، تغییر آیتمهای select ممکن است باعث شود که selected Item انتخاب شده (که مربوط به آیتمهای قبلی است) به صورت ناخواسته برای مدت زمان کوتاهی باقی بماند. این تأخیر می‌تواند باعث ایجاد Glitch in the Matrix شود که در آن UI اطلاعات نادرستی نمایش می‌دهد، حتی اگر داده‌های اصلی تغییر کرده باشند.ایجاد Single Source of Truth مستقل: وقتی هر کدام از بخش‌های state، مثل items و selected Item انتخاب شده به صورت جداگانه مدیریت شوند و سپس نیاز به همگام‌سازی بین آن‌ها ایجاد شود، Single Source of Truth به وجود می‌آید. این موضوع چالش‌های زیادی را در مدیریت منطق و همگام‌سازی به‌وجود می‌آورد.پیچیدگی‌های کدنویسی: بسیاری از توسعه‌دهندگان به دلیل قدرت effect ممکن است به سراغ آن‌ها بروند، در حالی که در بسیاری از موارد ممکن است رفتار مورد انتظار را ایجاد نکند یا به عنوان یک "کد بد" تلقی شود. الزام به استفاده از effect برای همگام‌سازی حالت، اغلب نشانه‌ای از مشکل در طراحی ساختار حالت است.راه‌حل‌های جایگزین پیشنهادی:بایستی به جای استفاده از effect، ساختار حالت کامپوننت‌ها به گونه‌ای تغییر داده شود که آنچه باید همیشه sync باشد، در یک منبع واحد (Single Source of Truth) متمرکز گردد. در مثال توضیح داده شده در بالا، استفاده از computed signal به جای effect توصیه میشود.به جای اینکه selected index انتخاب شده به عنوان یک signal مستقل در نظر گرفته شود، بهتر است این selected index به عنوان بخشی از یک state محاسبه شود. به عبارت دیگر، وقتی options تغییر می‌کند، state مربوط به انتخاب از نو ایجاد می‌شود؛ یعنی signal قبلی (برای selected index انتخاب شده) کنار گذاشته شده و یک signal جدید با مقدار پیش‌فرض (مثلاً -۱ برای هیچ انتخابی) ساخته می‌شود. این کار هم نه تنها هماهنگی بین داده‌ها را تضمین می‌کند، بلکه یک Single Source of Truth برای کامپوننت به وجود می‌آورد.درس‌های کلی در state management در انگولار:تمرکز بر Single Source of Truth: ایده اصلی در Reactive programming این است که تمام states های مرتبط با UI از یک source واحد نشأت بگیرند. اگر بخواهیم از دو یا چند source مستقل استفاده کنیم و سپس آن‌ها را sync کنیم، احتمال بروز خطا یا رفتار غیرمنتظره افزایش می‌یابد.طراحی مجدد روابط داخل states: به جای تلاش برای synchronization states مجزا با effect، بهتر است ساختار داده‌ای خود را بازنگری کنید تا رابطه بین آن‌ها به صورت طبیعی برقرار شود. اگر یک state (مثل selected index انتخاب شده) وابسته به state دیگری (مثل options) است، باید آن را به گونه‌ای تعریف کرد که به صورت computed signal و در چارچوب همان source state واقعی به‌روز شود.استفاده‌ی هوشمندانه از signal و computed signal: سیگنال‌های انگولار این امکان را می‌دهند که تغییرات در داده‌ها به صورت خودکار به‌روز شود و نیازی به مداخله مستقیم و دستی (مانند استفاده‌ی مکرر از effect) نداشته باشید. این امر موجب کاهش بار فکری و افزایش پیش‌بینی‌پذیری در برنامه‌های کاربردی می‌شود.هدف نهایی: استفاده از رویکردی متکی بر signal و computed signal باعث می‌شود که سیستم Reactive به صورت دقیق و بدون تاخیر، تغییرات وضعیت را مدیریت کند. از این رو، effect بیشتر برای کاربران پیشرفته مناسبند؛ در حالی که در اکثر موارد، راه‌حل‌های ساده‌تر و بومی‌تری در دسترس هستند.نتیجه‌گیریاگرچه effect در انگولار، ابزارهایی قدرتمند برای هماهنگ‌سازی بین دنیای Reactive و non Reactive ارائه می‌دهند، اما استفاده از آن‌ها می‌تواند مشکلات timing و ناسازگاری در synchronization states ایجاد کند. به همین دلیل، توصیه میشود که به جای آن، ساختار حالت کامپوننت‌ها به گونه‌ای طراحی شود که وابستگی‌ها به صورت computed signal و signal های تو در تو مدیریت شوند. این شیوه نه تنها وابستگی‌ها را به‌روش بهتری مدلسازی می‌کند، بلکه از بروز مشکلاتی مانند "Glitch in the Matrix" جلوگیری کرده و کدهای تمیزتر و قابل نگهداری‌تری به دست می‌دهد.در نهایت به توسعه‌دهندگان انگولار یادآوری میشوذ، که همیشه باید قبل از تصمیم‌گیری برای استفاده از هر ابزاری، رابطه‌ی بین داده‌های خود را به دقت در نظر بگیرند و اگر امکان استفاده از یک single source وجود دارد، از آن بهره ببرند. این رویکرد در state management باعث می‌شود مشکلاتی مانند همگام‌سازی نادرست و تاخیر در به‌روزرسانی داده‌ها به حداقل برسد.این مقاله می‌تواند نقطه‌ی شروع خوبی برای همه کسانی باشد که می‌خواهند درک بهتری از مفاهیم Reactive در انگولار داشته باشند و به دنبال راهکارهایی جایگزین بهینه برای state management در برنامه‌های خود هستند.همچنین اگر به مباحث پیشرفته‌تر، مانند نحوه‌ی Input management و getters/setters در کنار Signals علاقه‌مندید، می‌توانم در مقالات بعدی به این موضوعات بپردازم. میلاد جعفری میلاد جعفری Tue, 03 Jun 2025 11:42:03 +0330