چرا آسیب‌پذیری اخیر ری‌اکت فقط توی معماری RSC دیده شد و نه در SSR؟

تو روزهای اخیر یک آسیب‌پذیری جدی توی ری‌اکت مطرح شد که به کامپوننت‌های سمت سرور مربوط بود.
این اسیب پذیری لزوما مربوط به ورژن نبود. چون به فرض اگر نکست بالای ۱۴ بودیم اما کماکان page router استفاده میکردیم هیچ خطری وجود نداشت
خب حالا app router با page router چه تفاوتی دارن؟
جواب این سؤال توی تفاوت عمیق معماری SSR و RSC قرار داره.

معماری SSR دقیقاً چه کاری انجام میده؟

تو این مدل، ری‌اکت روی سرور اجرا میشه و خروجی نهایی به شکل HTML کامل ساخته میشه و برای مرورگر فرستاده میشه.
بعد از اون، کد جاوااسکریپت توی مرورگر دانلود میشه و فرآیند هیدریشن انجام میشه.

نکته‌ی مهم اینجاست که HTML فقط یک خروجی نهایی و ایستاست.
این خروجی نه ساختار کامپوننت‌ها رو نگه می‌داره، نه منطق اجرا رو منتقل می‌کنه و نه مرزی بین کد سمت سرور و کلاینت مشخص می‌کنه.

به همین خاطر، سطح حمله توی این معماری معمولاً محدود میشه به چیزهایی مثل XSS یا template injection و خود ری‌اکت توی سمت کلاینت نقش فعالی توی تفسیر داده‌های ورودی نداره.

معماری RSC چه چیزی رو عوض کرد؟

توی معماری RSC، کامپوننت‌ها واقعاً روی سرور اجرا میشن و نتیجه‌ی اجرای اون‌ها به‌جای HTML، به شکل ساختار درختی ری‌اکت به سمت کلاینت میره.
این انتقال با استفاده از یک پروتکل اختصاصی به اسم React Flight انجام میشه.

به زبان ساده‌تر، مرورگر دیگه فقط یک خروجی آماده تحویل نمی‌گیره، بلکه اطلاعات لازم برای ساخت رابط کاربری رو دریافت می‌کنه.

حالا Flight شامل چه نوع اطلاعاتی میشه؟

توی این پروتکل، داده‌هایی جابه‌جا میشن که شامل نوع کامپوننت‌ها، پراپ‌ها، مرز بین کد سمت سرور و کلاینت و همین‌طور ارجاع به ماژول‌هایی هستن که باید توی کلاینت بارگذاری بشن.
توی سمت دریافت‌کننده، ری‌اکت این داده‌ها رو parse می‌کنه، ارجاع‌ها رو resolve می‌کنه و اگه لازم باشه بعضی بخش‌ها رو به شکل lazy لود می‌کنه.

️ چرا این تغییر سطح حمله‌ی جدید درست می‌کنه؟

توی مهندسی نرم‌افزار یک قانون ساده وجود داره:
هرچی داده به لایه‌ی اجرا نزدیک‌تر باشه، ریسک امنیتی هم بالاتر میره.

اینجا داده‌ای که از بیرون وارد سیستم میشه، مستقیم وارد مسیری شامل parse، resolve و تصمیم‌گیری اجرایی میشه.
اگه توی هرکدوم از این مرحله‌ها اعتبارسنجی یا محدودسازی درست انجام نشه، یک سطح حمله‌ی جدید شکل می‌گیره.

چرا چنین ریسکی توی SSR وجود نداشت؟

توی معماری SSR، چیزی که به مرورگر فرستاده میشه صرفاً HTMLه.
این فرمت نه زبان اجرایی حساب میشه، نه ارجاع ماژولی داره و نه منطق پویا رو منتقل می‌کنه.

به همین خاطر، پردازشش ‌ توی مرورگرها بهینه و ایزوله شده و سطح تعاملش با منطق اجرایی برنامه خیلی محدوده.

در مقابل، Flight یک پروتکل جدیده، پیچیده‌ست و خیلی به لایه‌ی اجرای برنامه نزدیکه و همین نزدیکی، دلیل اصلی بالا رفتن ریسک امنیتی محسوب میشه.

جمع‌بندی نهایی
این اتفاق بیشتر یادآوری می‌کنه که هر معماری‌ای که داده رو به اجرای مستقیم نزدیک‌تر می‌کنه، ناچار هزینه‌ی امنیتی بیشتری هم می‌ده.

ری‌اکت برای رسیدن به عملکرد بهتر، کم کردن حجم جاوااسکریپت و حرکت به سمت معماری server-first مجبور شد Flight رو معرفی کنه و همین انتخاب، دلیل تفاوت این آسیب‌پذیری با معماری SSR شد.

@ | <Ali Noori/>

🔵 عنوان مقاله
SentryPeer (GitHub Repo)

🟢 خلاصه مقاله:
SentryPeer یک ابزار تشخیص کلاهبرداری است که با رصد و پیگیری تماس‌های مشکوک، فعالیت‌های مخرب را شناسایی می‌کند. این ابزار با ذخیره کردن آدرس‌های آی‌پی و شماره‌هایی که افراد مخرب قصد تماس با آن‌ها را دارند، به تشخیص رفتارهای مشکوک کمک می‌کند. هدف اصلی SentryPeer ارائه راهکاری کارآمد برای كشف فعالیت‌های غیرقانونی و جلوگیری از کلاهبرداری‌هایی است که ممکن است در سیستم‌های تماس یا پیامک رخ دهد.

این ابزار در واقع با ثبت و نگهداری داده‌های تماس‌های مشکوک، به مدیران شبکه و سرویس‌ها امکان می‌دهد تا جلوی فعالیت‌های مخرب را بگیرند و اطمینان حاصل کنند که از اقدامات احتمالی تقلب جلوگیری می‌شود. SentryPeer یک سیستم هوشمند است که با تحلیل الگوهای تماس، می‌تواند هشدارهای فوری در مورد فعالیت‌های غیرمعمول صادر کند و از نفوذ بی‌درنگ جلوگیری نماید.

#کلاهبرداری #امنیت_شبکه #تشخیص_تقلب #امنیت_سایبری

🟣لینک مقاله:
https://github.com/SentryPeer/SentryPeer?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
No one knows what AI agents will look like next year. How should you approach security today? (Sponsor)

🟢 خلاصه مقاله:
هیچ‌کس نمی‌داند هوش مصنوعی در سال آینده چگونه خواهد شد. بنابراین، چگونه باید امنیت خود را در حال حاضر تامین کنید؟ این سوالی است که بسیاری از متخصصین امنیت در دنیای فناوری امروز به آن فکر می‌کنند. «رهبران فکری» در حوزه فناوری اعتماد دارند که هویت‌های غیرانسانی در آینده نقش مهمی ایفا خواهند کرد، اما آیا آن‌ها می‌توانند پیش‌بینی کنند وضعیت این حوزه در ۱۲ ماه آینده چگونه خواهد بود؟ پاسخ قطعی و مطمئنی برای این سوال ندارند، زیرا آینده فناوری بسیار غیرقابل پیش‌بینی است و تغییرات آن به سرعت رخ می‌دهد. بنابراین، بهترین راهکار برای مقابله با ریسک‌هایی که آینده آن‌ها برای ما نامشخص است چیست؟ بهترین کار آغاز کردن با منابع و ابزارهای مطمئن است؛ همانطور که در این صفحه از شرکت Okta مشاهده می‌شود، کارشناسانی از AWS، Okta و Guidewire دیدگاه‌های خود را در مورد این مرز جدید از فناوری ارائه می‌دهند. این ویدئو فرصت عالی است تا چندین نظر مختلف درباره امنیت در عصر هوش مصنوعی آینده را بشنوید و راهکارهای مؤثر برای محافظت هر چه بهتر از سامانه‌ها و داده‌هایتان بیاموزید.

در دنیای متغیر فناوری، آنچه مهم است داشتن استراتژی‌های انعطاف‌پذیر و به‌روز است که بتواند در مقابل تهدیدهای نامشخص مقاوم باشد. توجه به نظرات و تجربیات این کارشناسان می‌تواند راهنمای خوبی برای ارتقاء امنیت کسب‌وکار شما در مواجهه با فناوری‌های نوین باشد.

#امنیت_فناوری #هوش_مصنوعی #امنیت_سایبری #توسعه_فناوری

🟣لینک مقاله:
https://www.okta.com/webinars/hub/beyond-oktane-how-to-manage-nhi-with-okta-ispm/?utm_source=newsletter&utm_medium=thirdparty&utm_campaign=2025-10%7CWBN-OND%7CBeyondOktane-ISPM-Demo-Part2-VID&utm_id=aNKKZ0000004CAG4A2

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Security flaws in Freedom Chat app exposed users' phone numbers and PINs (3 minute read)

🟢 خلاصه مقاله:
در تازه‌ترین گزارش‌ها، مشکلات امنیتی جدی در برنامه گفت‌وگوی فریدام چت کشف شده است که حفره‌هایی را در حفاظت از حریم خصوصی کاربران ایجاد کرده است. این برنامه، دو نقص بزرگ داشت که یکی از آنها امکان شناسایی تعداد زیادی از شماره تلفن‌های کاربران را فراهم می‌کرد؛ به گونه‌ای که هکرها می‌توانستند با حدس‌زنی گسترده، تقریباً نزدیک به دو هزار شماره تلفن را به‌درستی در سرورهای برنامه فهرست‌بندی کنند. این روش، امنیت کاربران را به شدت تحت‌تأثیر قرار می‌داد و می‌توانست منجر به سوء استفاده‌های مختلف شود.

دومین آسیب‌پذیری نهانی‌تر، لو رفتن کدهای PIN کاربران بود، که از طریق پاسخ‌های سرور به صورت پس‌زمینه و در کانال‌های عمومی پیش‌فرض، امکان دیدن این کدها برای هر فرد در آن گروه‌های عمومی را فراهم می‌کرد. این مسئله باعث نگرانی‌های زیادی درباره حفظ حریم خصوصی و امنیت حساب‌های کاربری شد. پس از کشف این مشکلات، تیم توسعه‌دهنده فریدام چت اقدام به بازنشانی تمامی کدهای PIN کرد، محدودیت‌های سرعت ارسال درخواست‌ها را افزایش داد و شماره‌های تلفن آسیب‌پذیر را حذف نمود.

همچنین، نسخه به‌روزرسانی شده برنامه، با اصلاح سریع این نقاط ضعف روانه بازار شد تا امنیت کاربران بهبود یابد. لازم به ذکر است که این مشکلات، دومین بار است که بنیان‌گذار برنامه، تنر هاس، در توسعه یکی از اپ‌های پیام‌رسان او، با مسائل امنیتی جدی مواجه می‌شود. این موضوع نشان‌دهنده اهمیت رعایت نکات امنیتی در طراحی و نگهداری برنامه‌های پیام‌رسان است تا حریم خصوصی کاربران حفظ و سوء استفاده‌ها کاهش یابد.

#امنیت_گفتگو #حریم_خصوصی #فریدام_چت #مدیریت_امنیت

🟣لینک مقاله:
https://techcrunch.com/2025/12/11/security-flaws-in-freedom-chat-app-exposed-users-phone-numbers-and-pins/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
AWS Lambda Managed Instances: A Security Overview (5 minute read)

🟢 خلاصه مقاله:
در همایش re:Invent 2025، شرکت آمازون وب سرویس (AWS) اعلام کرد که قابلیت جدیدی به نام "نمونه‌های مدیریتی لامبدا" (Lambda Managed Instances) عرضه کرده است. این قابلیت به توسعه‌دهندگان اجازه می‌دهد تا توابع لامبدا بر روی نمونه‌های EC2 که توسط خود AWS مدیریت می‌شوند، اجرا شوند. این تغییر، یک گزینه هیجان‌انگیز برای بهبود امنیت و کنترل در محیط‌های سرورless است، چرا که بر خلاف نمونه‌های مدیریتی دیگر، کاربران قادر نیستند نقش نمونه (Instance Role) به این نمونه‌ها اختصاص دهند. این محدودیت، سطح امنیت و کنترل بیشتری را برای کاربران فراهم می‌کند، زیرا دسترسی مستقیم به این نمونه‌ها محدود شده است.

نکته جالب دیگر این است که در حالی‌که نمونه‌های مدیریت شده در سرویس EKS به کاربران اجازه نمی‌دهند تا به صورت مستقیم از ابزارهایی مانند SSM یا EC2 Instance Connect برای دسترسی به نمونه‌ها استفاده کنند، نمونه‌های لامبدا مدیریت شده این محدودیت را ندارند. این طراحی، به منظور کاهش ریسک‌های امنیتی و جلوگیری از دستکاری غیرمجاز است و در عین حال، امکان اجرای توابع لامبدا در محیط‌های جداگانه و کنترل‌شده را فراهم می‌کند. نمونه‌های مذکور از توزیع لینوکس مخصوص کانتینرهای AWS به نام Bottlerocket OS بهره می‌برند، که برای امنیت بالا و کارایی بهینه طراحی شده است.

این نمونه‌ها توابع لامبدا را به صورت کانتینرهای containerd اجرا می‌کنند، که این امر امکان مدیریت بهتر و بهبود امنیت را فراهم می‌آورد. به طور کلی، این توسعه جدید نشان دهنده تعهد AWS به افزایش سطح امنیت و انعطاف‌پذیری در سرویس‌های سرورلس است، و فرصت جدیدی برای توسعه‌دهندگان و مدیران اکانت فراهم می‌کند تا زیرساخت‌های خود را امن‌تر و مقیاس‌پذیرتر کنند.

#آمازون_وب_سرویس #AWS #خدمات_مبتنی_بر_کلود #امنیت

🟣لینک مقاله:
https://www.offensai.com/blog/aws-lambda-managed-instances-security-overview?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
How I Ran Cypress Page Objects Inside Playwright Without Rewriting a Single Line

🟢 خلاصه مقاله:
در دنیای توسعه وب، یکی از چالش‌های اصلی، انتقال پروژه‌ها و کدهای تست از یک ابزار به ابزار دیگر است. در حالت ایده‌آل، این فرآیند باید بدون صرف وقت و هزینه زیاد انجام شود تا تیم‌ها بتوانند به سرعت و بدون مشکلاتِ فنی اضافی، امکانات جدید را آزمایش کنند. در این زمینه، نویسنده و توسعه‌دهنده Aneeshia Sasidharan یک روش غیرمعمول و کارآمد برای استفاده مجدد از اشیاء صفحه‌ی Cypress در محیط Playwright ارائه کرده است، بدون اینکه نیاز به بازنویسی یک خط کد باشد.

در این مقاله، او روش‌های نوآورانه‌ای را برای ادغام دو فریمورک محبوب تست وب، به اشتراک گذاشته است. این روش کمک می‌کند تا تیم‌ها بتوانند با استفاده از ساختارهای موجود، فرآیند انتقال را سریع‌تر و کم‌هزینه‌تر انجام دهند، در حالی که کارایی و دقت تست‌ها حفظ می‌شود. از آنجایی که این استراتژی نیازمند تغییرات کم و بدون نیاز به بازنویسی کامل است، کاربرد آن برای پروژه‌های بزرگ و تیم‌هایی که بر زمان و منابع خود مقید هستند، بسیار مفید است.

در نهایت، این رویکرد نشان می‌دهد که نوآوری در فرآیندهای توسعه و آزمایش‌های نرم‌افزاری، می‌تواند به سادگی و با کم‌ترین دردسر ممکن، عملی شود. با بهره‌گیری از این تکنیک، توسعه‌دهندگان و مهندسان تست می‌توانند بهره‌وری خود را افزایش دهند و فرآیندهای آزمایش را به شکل مؤثرتری پیاده‌سازی کنند، بدون اینکه از ساختارهای قدیمی خود بیرون بیایند یا زمان زیادی صرف اضافه کردن کدهای جدید کنند.

#تست_وب #Playwright #Cypress #توسعه_نرم‌افزار

🟣لینک مقاله:
https://cur.at/iKYs6OB?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

سایت System Design یکی از بهترین منابع برای فهم طراحی سیستم‌های بزرگیه که هر روز استفاده می‌کنیم.
خودم تقریبا هر روز یکی از مطالبش رو می‌خونم و واقعا دید خوبی برای پیاده‌سازی نرم‌افزار می‌ده؛
از WhatsApp و YouTube تا Instagram و Redis و ...

https://newsletter.systemdesign.one/

🥇 اگر عاشق تکنولوژی‌های روز دنیا هستی، اینجا هر روز تازه‌ترین و مهم‌ترین مطالب درباره:👇

🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژی‌های نو
🔌 دنیای الکترونیک و گجت‌های هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حمل‌ونقل

همه چیز به‌صورت کوتاه، خلاصه و کاملاً قابل‌فهم👇👇

🥈 @futurepulse_persian

🔵 عنوان مقاله
Scaling DAA: Mastering the Action Layer with Composite Patterns

🟢 خلاصه مقاله:
در شماره گذشته، به موفقیت‌های قابل توجه معماری اقدام اعلانی در اتوماسیون آزمایش پرداختیم و مفاهیم کلیدی آن را بررسی کردیم. حال، در این بخش، تمرکز بر روی رشد و توسعه لایه عملیاتی (Action Layer) است که نقش مهمی در ساختار کلی این معماری دارد. با بهره‌گیری از الگوهای ترکیبی (Composite Patterns)، می‌توان درک بهتری از نحوه مدیریت، سازماندهی و مقیاس‌پذیری بخش عملیاتی کسب کرد. این روش‌ها به تیم‌های تست کمک می‌کنند تا عملیات پیچیده را ساده‌تر و قابل کنترل‌تر کنند، در نتیجه فرآیندهای تست را کارآمدتر و انعطاف‌پذیرتر می‌سازند.

با توسعه این مفاهیم، اهمیت استفاده از الگوهای ترکیبی در طراحی لایه‌های عملیاتی آشکار می‌شود. این الگوها امکان ترکیب اقدامات گوناگون در ساختارهای درختی را فراهم می‌کنند و نتیجه‌اش، پویایی و قابلیت برنامه‌ریزی بهتر در سیستم‌های اتوماسیون است. بنابرین، mastery در این حوزه، مهارتی است که می‌تواند سطح اتوماسیون آزمایش‌ها را به شکل قابل توجهی ارتقاء دهد.

در نهایت، مقاله به تشریح نحوه به کارگیری این الگوها در عمل پرداخته و نمونه‌هایی عملی از پیاده‌سازی آنها ارائه می‌دهد. با فهم عمیق‌تر این مفاهیم و تکنیک‌ها، توسعه‌دهندگان و تیم‌های تست می‌توانند سیستم‌های مقیاس‌پذیر و انعطاف‌پذیرتری بنا کنند که پاسخگوی نیازهای پیچیده و در حال تغییر هستند.

کلام پایانی، تاکید بر اهمیت mastery در طراحی لایه عملیاتی (Action Layer) با استفاده از الگوهای ترکیبی است، روشی که آینده‌نگر و مؤثر در ارتقاء کیفیت و عملکرد سیستم‌های اتوماسیون است.



#اتوماسیون_آزمایش #الگوهای_ترکیبی #معماری_اقدام #توسعه_پیشرفته

🟣لینک مقاله:
https://cur.at/whVcVwF?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Weaponizing the AWS CLI for Persistence (5 minute read)

🟢 خلاصه مقاله:
در این مقاله، به بررسی روش‌های بهره‌برداری مخفیانه از ابزار AWS CLI برای ایجاد جا پای ماندگار در سیستم هدف پرداخته شده است. یکی از قابلیت‌های AWS CLI، امکان تعریف نام‌های مستعار برای دستورات است که می‌تواند این دستورات را با اجرای فرمان‌های bash دلخواه جایگزین کند. اما محدودیتی که در گذشته وجود داشت، این بود که اگر هکر نام مستعاری برای نمونه برای دستور `aws sts` تعریف کرده و آن را مخرب می‌کرد، نمی‌توانست نسخه اصلی آن را اجرا کند، چون راهی برای بازگرداندن فرمان اوریجینال در دست نبود. در این مقاله، راه‌حلی مبتکرانه و در عین حال ساده ارائه شده است؛ یک خط کد که به صورت دینامیک فایل نام‌های مستعار را تغییر می‌دهد و نسخه اصلی فرمان را مجدداً فعال می‌کند، تا بتوان در هنگام نیاز از آن استفاده کرد و پس از اجرا، دوباره قابلیت مخرب را برمی‌گرداند. این تکنیک می‌تواند برای افرادی که قصد سوء استفاده دارند، ابزار موثری باشد، زیرا به آن‌ها اجازه می‌دهد پس از حذف محدودیت‌ها، به راحتی ادامه فعالیت‌های مخرب خود را داشته باشند.

در نتیجه، فهم صحیح و آگاهی از این روش‌ها اهمیت زیادی دارد، چرا که می‌تواند راه‌های پیشگیری و مقابله با حملات سایبری در محیط‌های ابری و به‌خصوص در زیرساخت‌های مبتنی بر AWS را تقویت کند. درک چگونگی عملکرد چنین تکنیک‌هایی، به مدیران امنیتی کمک می‌کند تا با تنظیمات مناسب، از بروز چنین آسیب‌پذیری‌هایی جلوگیری کرده و سیستم‌های خود را در برابر حملات مخفیانه محافظت نمایند.

#امنیت_ابری #AWS #حملات_سایبری #مدیریت_امنیت

🟣لینک مقاله:
https://slayer0x.github.io/awscli/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
HTTPS certificate industry phasing out less secure domain validation methods (4 minute read)

🟢 خلاصه مقاله:
در صنعت گواهینامه‌های امنیتی HTTPS، تمرکز روزافزون بر حذف روش‌های قدیمی و کم‌امنیت تایید دامنه است. در این راستا، برنامه ریشه‌های مرورگر Chrome و انجمن CA/Browser Forum تصمیم گرفتند با تصویب رأی‌گیری‌های SC-080، SC-090 و SC-091، روش‌های تایید کنترل دامنه که بر اساس ایمیل، تماس تلفنی، فکس، نامه پستی و بررسی معکوس DNS بودند، تا تاریخ مارس ۲۰۲۸ کنار گذاشته شوند. این تغییر عمدتاً با هدف ارتقاء سطح امنیت و جلوگیری از صدور گواهینامه‌های جعلی صورت گرفت.

در طول زمان، روش‌های قدیمی مانند تایید از طریق ایمیل یا تماس تلفنی، هم به دلیل سهولت سوءاستفاده و هم به دلیل ضعف در اثبات مالکیت واقعی دامنه، مورد انتقاد قرار گرفته بودند. بنابراین، نهادهای صادرکننده گواهینامه همگام با این تغییر، به سمت استانداردهای جدیدی حرکت می‌کنند که بیشتر مبتنی بر خودکارسازی و امنیت کریپتوگرافی است. این رویکرد، فناوری مبتنی بر پروتکل ACME را ترویج می‌کند که امکان تایید دیجیتال و خودکار اصالت گواهینامه‌ها را فراهم می‌آورد و خطر صدور گواهینامه‌های تقلبی را تا حد زیادی کاهش می‌دهد.

در نهایت، این تحولات نه تنها موجب ارتقاء امنیت فضای اینترنت می‌شود، بلکه فرآیند صدور گواهینامه‌ها را نیز کارآمدتر و قابل اعتمادتر می‌سازد، ضمن جلوگیری از فعالیت‌های مخرب و حفظ اعتماد کاربران در استفاده از صفحات وب ایمن. بنابراین، تصمیماتی مانند کنار گذاشتن روش‌های سنتی و تکیه بر فناوری‌های نوینی چون ACME، آینده‌ای مطمئن‌تر و امنیت بیشتر برای دنیای دیجیتال رقم خواهد زد.

#امنیت_وب #گواهینامه_امنیت #SSL #تایید_دامنه

🟣لینک مقاله:
https://security.googleblog.com/2025/12/https-certificate-industry-phasing-out.html?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

پاول دوروف: تلگرام 30 میلیارد دلار ارزش دارد و تنها 30 کارمند دارد که همگی از خانه کار میکنند. بدون دفتر، بدون منابع انسانی!
➖➖➖➖➖➖➖➖
👑 @futurepulse_persian

👉Amir Rahimi Nejad


یک Junior کد می‌نویسه؛
هدفش اینه که «کار کنه».
یک Mid-Level کد رو تمیز می‌کنه؛
می‌فهمه کدی که کار می‌کنه، لزوماً کد خوبی نیست.
یک Senior می‌دونه کِی کد بزنه،
کِی کد نزنه،
و کِی کد رو حذف کنه.
یک Lead جلوی اشتباه نوشته شدن کد رو می‌گیره؛
قبل از اجرا، مسئله رو درست تعریف می‌کنه.

حقیقت ساده ولی مهم اینه:
هرچی جلوتر می‌ری، کمتر کد می‌زنی
ولی مسئولیت تصمیم‌هات بیشتر می‌شه.

این سطوح به سالهایی که پای کد نشستی نیست،
طرز فکرته که سطحت رو مشخص میکنه

#SoftwareEngineering #Programming
#برنامه_نویسی #رشد_حرفه‌ای

🚀 Strong vs Eventual Consistency

از اون مفاهیمیه که خوب فهمیدنش توی مصاحبه‌های فنی به‌خصوص System Design به شدت کمکمون می‌کنه!

یا حتی موقع انتخاب و استفاده ى ابزارها!

مثلاً اگه ندونيم Redis Cluster برامون Strong Consistency رو گارانتی نمیكنه، ممکنه توی یه سری Use Case اشتباه ازش استفاده كنيم و نتایجی که انتظار نداريم اتفاق بيفته.

یا مثلاً MongoDB برای رسیدن به High Availability داره از Eventual Consistency استفاده میكنه كه البته کنارش هم داره از مکانیزم‌هایی مثل Write Concerns و Read Concerns استفاده میكنه که این نرخ ناسازگاری دیتا (یا تاخیر انتشار دیتا) رو كم كنه.


توی این ویدیو از چنل Inspect میخوایم بریم سراغش و به این سوالات جواب بدیم:

🔹 مفهوم Consistency چیه؟
🔸 چه مدل‌هایی داره؟
💡 هر کدوم چه مزایایی برامون دارند؟ (سرعت در برابر دقت و دسترسی‌پذیری)
🛠 چطوری میتونیم به دستشون بیاریم؟
🔎مفاهیمی مثل Replication و Consensus چطور به این هدف کمک می‌کنند؟


📺 ویدیو کامل: «چرا داده‌هامون فرق می‌کنه؟ | Data Consistency در سیستم‌های توزیع‌شده»

https://lnkd.in/dT94cDCi

وقتی میکروسرویس‌ها بدون API Management وارد Production می‌شن…

خیلی از تیم‌ها با هیجان می‌رن سمت معماری Microservices؛
سرویس‌ها کوچک می‌شن، تیم‌ها مستقل می‌شن، deploy سریع‌تر می‌شه…
اما یه سؤال مهم معمولاً جا می‌مونه:

چه کسی قراره این همه API رو مدیریت کنه؟
اینجاست که API Management از یک ابزار لوکس تبدیل می‌شه به یک ضرورت.
در معماری Monolith، کنترل دسترسی، rate limit، versioning و monitoring معمولاً داخل خود اپلیکیشن پیاده‌سازی می‌شه.

اما در معماری Microservices، تکرار این موارد داخل هر سرویس یعنی کد تکراری، رفتارهای ناسازگار، policyهای امنیتی متفاوت و دردسر در نگهداری

دقیقاً اینجا API Management وارد بازی می‌شه:
- یک نقطه‌ی مرکزی برای Authentication و Authorization
- اعمال Rate Limiting و Throttling به‌صورت یکپارچه
- مدیریت Versioning بدون دست‌زدن به سرویس‌ها
- امکان Observability متمرکز (Logs، Metrics، Traces)
- محافظت از سرویس‌ها در برابر traffic ناخواسته یا مخرب

نکته مهم اینه که API Manager جای Microservice رو نمی‌گیره،
بلکه مثل یک قرارداد پایدار بین سرویس‌ها و مصرف‌کننده‌ها عمل می‌کنه.
تجربه‌ی من این بوده:
هر چقدر تعداد سرویس‌ها بیشتر می‌شه، نبود API Management هزینه‌ی بیشتری به تیم تحمیل می‌کنه — چه از نظر امنیت، چه پایداری، چه سرعت توسعه. Microservices بدون API Management قابل اجرا هست…
اما به‌سختی قابل رشد و نگهداریه.


| <Mobin Mokhtarzadeh/>

بزرگترین درسی که در سِمت CTO آموختم:
اصول Clean Code اغلب دروغ هستند!

این یک اعتراف است: من سال‌ها به تیمم اجازه نمی‌دادم کدی بنویسند که برای بیزینس حیاتی بود، فقط چون از نظر فنی "تمیز" نبود.

​من یک CTO وسواسی بودم که برای رعایتِ قوانین SOLID یا داشتن یک معماری بی‌نقص، سرعت رسیدن به بازار (Time-to-Market) را قربانی می‌کردم.
ما تبدیل شده بودیم به تیمی که سریع‌ترین کدهای تاریخ را برای محصولی نوشت که هنوز مشتری نداشت!

​کمال‌گرایی فنی (Technical Perfectionism) در فاز MVP، قتلِ خاموش استارتاپ‌هاست.
کتاب‌های معروف مهندسی نرم‌افزار به ما "چگونه خوب کد زدن" را یاد می‌دهند، اما هیچوقت نمی‌گویند "چه زمانی باید به عمد بد کد بزنیم."

​بدهی فنی، اما این‌بار آگاهانه:
​امروز، دیدگاه من ۱۸۰ درجه تغییر کرده است. به جای وسواس روی "Clean Code"، تمرکز من روی "کد تاکتیکی" است.

​تصمیم‌گیری به عنوان یک CTO، مدیریت تریدآف (Trade-off) است. من بدهی فنی (Tech Debt) را نه به عنوان یک شکست، بلکه به عنوان یک ابزار استراتژیک می‌بینم:

​بدهی ناآگاهانه: نوشتن کد کثیف از روی تنبلی یا بی‌دانشی (این غیرقابل بخشش است و باید حذف شود).

​بدهی آگاهانه (وام بیزینسی): ما آگاهانه، کیفیت نگهداری را فدای سرعت عرضه می‌کنیم. این شبیه به گرفتن وام تجاری با نرخ بهره مشخص است. ما باید سریع به بازار برسیم، و قول می‌دهیم که وقتی ارزش (Value) اثبات شد، اصل و سود این وام را با Refactoring پس دهیم.

​ سه حقیقت تلخ مهندسی
​کتاب Clean Code به ما یاد داد تمیز بنویسیم، اما یاد نداد "کی" تمیز بنویسیم.
​کتاب Clean Code رابرت مارتین مقدس است، اما "Time-to-Market" مقدس‌تر.
​اگر استارتاپ هستید، معماریِ "Good Enough" (به اندازه کافی خوب)، تنها معماری درستی است که نیاز دارید.

​اگر تیم شما ۶ هفته وقت می‌گذارد تا زیرساختی بسازد که توانایی مدیریت ۵ میلیون کاربر را دارد، در حالی که شما ۱۰ کاربر هم ندارید، شما در حال "بیش‌مهندسی" (Over-engineering) هستید.

​من امروز یک کد کثیف که ارزش را به سرعت می‌رساند را به یک شاهکار معماری که هفته‌ها طول کشیده، ترجیح می‌دهم.


<Bijan Biria/>

‏⚠️ رکورد ترسناک هکرهای کره شمالی: سرقت 2.02 میلیارد رمزارز در سال 2025

▪️هکرهای وابسته به کره شمالی در سال 2025 موفق به سرقت 2.02 میلیارد دلار رمزارز شدند ؛ رقمی که حدود 60% از کل سرقت‌های رمزارزی امسال رو تشکیل میده.

▪️طبق گزارش Chainalysis، مجموع سرقت‌های رمزارزی منتسب به این کشور تاکنون به 6.75 میلیارد دلار رسیده.  گفته می‌شود دولت کره شمالی از این حملات برای تأمین مالی و دور زدن تحریم‌های بین‌المللی استفاده میکنه.

🔵 عنوان مقاله
Infostealer has entered the chat (7 minute read)

🟢 خلاصه مقاله:
با افزایش محبوبیت مرورگر Atlas شرکت OpenAI، مجرمان سایبری نیز از این فرصت سوءاستفاده کرده‌اند. آن‌ها با خرید تبلیغات در گوگل، کاربران را به سمت یک گفتگوی مشترک در ChatGPT هدایت می‌کنند که ادعا می‌کند راهنمای نصب مرورگر Atlas مخصوص مک‌اواس است. در این راهنما، کاربرانی که به دنبال نصب این مرورگر هستند، تشویق می‌شوند تا فرمان ترمینال ساده‌ای را اجرا کنند. این فرمان، به صورت مخفیانه اسکریپتی را بارگیری و اجرا می‌کند که نه تنها اطلاعات حساس کاربر، مانند رمزعبور و داده‌های مرورگر، را سرقت می‌کند، بلکه ابزارهای مخرب دیگری مانند کی‌لاگر و بدافزار AMOS را نصب می‌نماید. این ابزارهای مخرب اطلاعات مربوط به کیف پول‌های رمزارزی، فایل‌ها و اسناد مهم کاربر را جمع‌آوری می‌کنند و در کنار آن، درب پشتی را برای دسترسی همیشگی و کنترل از راه دور فعال می‌کنند. این نوع حملات نشان‌دهنده اهمیت مراقبت‌های امنیتی و اعتماد نکردن به راهنماهای ناشناخته در فضای مجازی است، مخصوصاً زمانی که منابع رسمی و معتبر نیستند.

---

با رشد روزافزون محبوبیت مرورگر Atlas از سوی کاربران، کلاهبرداران سایبری هم به همین میزان با نوشته‌ها و تبلیغات فریبنده، قصد دارند به اطلاعات حساس کاربران دست پیدا کنند. آن‌ها با تبلیغات در موتورهای جستجو، کاربران را فریب داده و به جلسات گفت‌وگو در ChatGPT هدایت می‌کنند، در حالی که در ظاهر، این گفت‌وگوها راهنمای نصب و راه‌اندازی مرورگر Atlas برای سیستم‌عامل مک‌اواس به نظر می‌رسند. در حقیقت، زمانی که کاربران فرمان ترمینال را اجرا می‌کنند، یک اسکریپت مخرب به صورت پنهانی اجرا می‌شود که نه تنها داده‌ها و رمزعبورهای آن‌ها را سرقت می‌کند، بلکه ابزارهای مخرب قدرتمندی مانند AMOS و کی‌لاگر را نصب می‌نماید. این ابزارها اطلاعات حساس، از جمله کیف پول‌های رمزارزی، اسناد مهم و تمامی داده‌های مرورگر را جمع‌آوری می‌کنند و به مهاجمین این امکان را می‌دهد که کنترل کامل بر سیستم فرد قربانی داشته باشند. نگهداری از امنیت سایبری و هوشیاری نسبت به تبلیغات و لینک‌های مشکوک، کلید مقابله با این نوع تهدیدات است؛ زیرا آن‌هایی که بدون بررسی دقیق، فرمان‌هایی را اجرا می‌کنند، ممکن است آرام‌آرام در دام حملات سایبری گرفتار شوند.

#امنیت_سایبری #حملات_مخرب #سرقت_اطلاعات #پیشگیری_امنیت

🟣لینک مقاله:
https://www.kaspersky.com/blog/share-chatgpt-chat-clickfix-macos-amos-infostealer/54928/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Method-Based Approach for Readable E2E Tests Without Cucumber

🟢 خلاصه مقاله:
در دنیای توسعه نرم‌افزار، اطمینان از کیفیت کد و صحت عملکرد برنامه‌ها اهمیت زیادی دارد. یکی از روش‌های محبوب برای تضمین کیفیت، نوشتن آزمایش‌های End-to-End (E2E) است که تمامی روند عملکرد برنامه را در بر می‌گیرد. مسأله این است که چگونه می‌توان این آزمایش‌ها را به صورت قابل‌فهم و خوانا نوشت، بدون نیاز به استفاده از ابزارهای پیچیده مانند Cucumber یا زبان‌های خاص مانند Gherkin.

در این زمینه، جوزفین جوب نشان می‌دهد که می‌توان آزمایش‌ها را به روشی توصیفی و ساده پیاده‌سازی کرد، بدون اینکه نیاز به لایه‌های اضافی یا زبان‌های تخصصی باشد. این رویکرد به توسعه‌دهندگان امکان می‌دهد کدهای تست را طوری بنویسند که گویی داستانی کوتاه و قابل فهم برای همه باشد. این روش نه تنها فرآیند نوشتن آزمایش‌ها را ساده‌تر می‌کند، بلکه خوانایی و نگهداری آن‌ها را نیز افزایش می‌دهد. هم‌چنین، این ایده در یک بحث اخیر در ردیت مورد توجه قرار گرفت، جایی که درباره نوشتن تست‌های BDD بدون نیاز به Gherkin و ابزارهای پیچیده‌تر صحبت شد. در نتیجه، این رویکرد می‌تواند راهکار مناسبی برای تیم‌های توسعه باشد که به سادگی و خوانایی در آزمایش‌های خود اهمیت می‌دهند و می‌خواهند کیفیت کد را بدون پیچیدگی‌های اضافی تضمین کنند.

#آزمایش_EndToEnd #کیفیت_کد #توسعه_ساده #تست_خوانا

🟣لینک مقاله:
https://cur.at/DF0FTPV?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Top Automation Anti-Patterns to Avoid (With Real Examples)

🟢 خلاصه مقاله:
در دنیای توسعه نرم‌افزار، اتوماسیون تست‌ها اهمیت فراوانی دارد و می‌تواند فرآیند تست را سریع‌تر و موثرتر کند. اما گاهی اوقات، تیم‌های توسعه دچار اشتباهاتی می‌شوند که در نتیجه، کارایی و دقت فرآیند اتوماسیون کاهش می‌یابد یا حتی به مشکل‌های جدی منجر می‌شود. وولادیمیر یوسیفوسکی در مقاله‌ای خلاصه‌ای از مهم‌ترین الگوهای منفی در اتوماسیون را ارائه می‌دهد و راهکارهای عملی برای جلوگیری از این اشتباهات را با نمونه‌های واقعی بیان می‌کند.

در این مقاله، ابتدا به شایع‌ترین خطاهایی اشاره می‌شود که در فرآیند طراحی و پیاده‌سازی تست‌های اتوماتیک رخ می‌دهد. سپس، پیشنهاداتی کاربردی برای جایگزینی این الگوهای منفی و بهبود کلی فرآیند ارائه می‌شود. آگاهی از این خطاها و راه‌حل‌های پیشنهادی نقش کلیدی در ایجاد سیستم‌های اتوماسیون مطمئن و کاربردی دارد.

این راهنمایی‌ها نه تنها برای توسعه‌دهندگان و تیم‌های تست مفید است، بلکه به مدیران پروژه کمک می‌کند تا استراتژی‌های مناسب‌تری برای پیاده‌سازی اتوماسیون تعریف کنند و از اتلاف منابع و زمان جلوگیری نمایند.

در نهایت، توجه به نمونه‌های واقعی و تجربه‌های عملی، درک بهتری از چالش‌ها و روش‌های مقابله با آن‌ها فراهم می‌کند و مانع تکرار اشتباهات رایج می‌شود. این مقاله منبع ارزشمندی است که با رعایت نکات آن، می‌توان فرآیند آزمایش‌های خود را به سمت بهتر و موثرتر هدایت کرد.

#اتوماسیون #تست_نرم‌افزار #خطاهای_اتوماتیک #بهبود_کامل

🟣لینک مقاله:
https://cur.at/EWPSoor?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon