✨️ نقاط قوت مونوریپو
- اشتراک‌گذاری کد: کد مشترک رو یه بار مینویسی و همه پروژه ها ازش استفاده میکنن.
- ریفکتور راحت تر: وقتی یه تابع یا تایپ رو عوض میکنی، همون لحظه میبینی کجاها خراب میشه.
- یک CI/CD برای همه: یه pipeline داری که همه‌چیز رو مدیریت میکنه.
- همکاری تیمی راحت‌تر: یه نفر میتونه همزمان روی چند بخش کار کنه.

✅️ اگه تنهایی یه پروژه کامل رو داری میاری بالا، برات فوق‌العادست؛ یا حتی برای تیم های ۲ ۳ نفره.

✨️ نقاط قوت پلی‌ریپو
- استقلال کامل: هر پروژه زندگی مستقل خودشو داره. به کسی کاری نداره.
- تیم های مستقل: هر تیم میتونه با ریتم خودش کار کنه.
- مدیریت دسترسی راحت‌تر: میتونی مشخص کنی چه کسی به چه پروژه ای دسترسی داشته باشه.

✅️ برای تیم هایی که تعدادشون زیاده و گروهی سر هر بخش کار میکنن فوق‌العادست‌.

💥 ترکیب هردو
پروژه های خیلی بزرگ، ترکیبی از هردو هستن. شرکت های بزرگی مثل گوگل همینکار رو میکنن. یک تیم بزرگ، تقسیم به تیم های کوچیک تر میشن. کل تیم روی یک Polyrepo کار میکنه، و هر بخش خودش یه Monorepo هست...

پروژه های پلی‌ریپو که جزئیات خاصی ندارن. پس میریم سراغ مونوریپو.

🔥 ابزار های مدیریت monorepo
مدیریت کردن این پروژه ها خیلی حیاتی‌عه.
چندین ابزار وجود داره:
- Turborepo
- Nx
- Lerna
- pnpm workspaces
- Bazel

از اونجایی که همشون مزخرف هستن و دردسر هایی دارن که به مرور برنامه نویس رو خسته میکنن، میریم سراغ اصل کاری، یعنی Moon ( Moonrepo ).

🔥 ابزار Moon: مدیریت پروژه های monorepo
بعد از تست تمام ابزار های مدیریت، بهترین‌شون رو اوردم بهتون معرفی کنم.

🌐 چند زبانه
برخلاف بقیه ابزارها، تمام زبان هارو ساپورت میکنه.

⚙️ یه CI/CD کامله
درحد یک github actions قابلیت بهتون میده. میتونین دقیقا مثل اون task ( همون job ) تعریف کنین. به هم وابسته‌شون کنین. براشون متغییر های env و secret مشخص کنین. و ...

🙃 به کد شما کاری نداره
کانفیگ کردنش به کد شما کاری نداره. فقط به فایل های خودش ( که moon.yml هستن ) کار داره. برعکس بقیه ابزار ها که بعد یه مدت کدتونو خراب میکنن. 💥

⚡ قدرت caching
قبل از بیلد کردن پروژه‌تون، بررسی میکنه که اصلا کدتون تغییری داشته یا نه؟

🖥️ برای ادیتور ضعفی ایجاد نمیکنه
توی بیشتر ابزار ها، شما مجبور بودین کل پروژه رو با ادیتور باز کنید. اما اینجا، فقط بخشی که میخواید رو باز کنین، و با کامند های ساده از همونجا کل پروژه رو مدیریت کنین. 🎯

فقط کم مونده بره نون بگیره بیاد 😂

داکیومنت:
https://moonrepo.dev/moon

گیتهاب:
https://github.com/moonrepo/moon

@CodingLovers_OFF

تازه میگن اینترنت احتمالااااا ۴۰ تا ۹۰ روز دیگه برمیگرده حالت قبل

ای بر پدرشون ...

اینترنت پرو خیانت به مردمه، هرکسی هم که بگیره فقط مسیر رو برای بدتر شدن همین شرایط هموار کرده

واقعا چی باید گفت فکرشو بکن مثل اینه تو حق داری نفس بکشی بیان دی اکسید کربن بزنن توی هوا بعد بیان قیمت درخت رو زیاد کنن یا بیان اکسیژن بفروشن دقیقا یه چیزی مثل اینه

دقیقا داستان همینه

یه مقاله مهم پیدا کردم که خالی از لطف نیست بدونیم.

چرا نباید از HTTP 1.1 استفاده کرد و خطرناک است؟

این یک مقالهٔ پژوهشی مهم از James Kettle (مدیر تحقیقاتی PortSwigger) است که در اوت ۲۰۲۵ منتشر شد. در ادامه، خلاصه‌ای از ایده‌های کلیدی آن آمده است:

استدلال اصلی
پروتکل HTTP/1.1 ذاتاً ناامن است و مرتباً میلیون‌ها وب‌سایت را در معرض تصاحب مخرب قرار می‌دهد. شش سال تلاش برای کاهش این مشکل فقط آن را پنهان کرده، اما موفق به حلش نشده است. مقاله استدلال می‌کند که HTTP/1.1 باید کنار گذاشته شود و برای ارتباطات upstream از HTTP/2 یا نسخه‌های جدیدتر استفاده شود.

نقص مرگبار
مرزهای درخواست‌ها در HTTP/1.1 بسیار ضعیف هستند — درخواست‌ها صرفاً روی اتصال TCP/TLS زیربنایی به هم چسبانده می‌شوند و هیچ جداکنندهٔ واقعی ندارند، ضمن اینکه چندین روش مختلف برای تعیین طول آن‌ها وجود دارد.
وقتی reverse proxyها درخواست‌های چند کاربر را روی اتصال‌های مشترک عبور می‌دهند، یک اختلاف کوچک در parser بین سرور front-end و back-end به مهاجم اجازه می‌دهد دادهٔ مخرب را به ابتدای درخواست کاربران دیگر تزریق کند — که اغلب منجر به تصاحب کامل سایت می‌شود.

چرا راهکارهای فعلی شکست می‌خورند
سرورها و CDNها معمولاً ادعا می‌کنند از HTTP/2 پشتیبانی می‌کنند، اما در عمل درخواست‌های HTTP/2 ورودی را برای انتقال upstream به HTTP/1.1 تبدیل (downgrade) می‌کنند و در نتیجه بیشتر مزایای امنیتی از بین می‌رود.
دفاع‌های مبتنی بر WAF نیز از الگوهای regex استفاده می‌کنند که به‌راحتی قابل دور زدن هستند و صرفاً «توهم امنیت» ایجاد می‌کنند.

کلاس‌های جدید حمله معرفی‌شده
1. شناسایی اختلاف Parser
یک ابزار متن‌باز جدید به نام HTTP Request Smuggler v3.0 به‌صورت سیستماتیک اختلاف‌های V-H (Visible-Hidden) و H-V (Hidden-Visible) بین parserهای front-end و back-end را بررسی می‌کند و امکان ایجاد desyncهای نوع CL.0 را فراهم می‌کند؛ حملاتی که WAFها معمولاً جلویشان را نمی‌گیرند.

2. حملات Desync نوع 0.CL
قبلاً تصور می‌شد این حملات قابل بهره‌برداری نیستند، چون باعث deadlock می‌شوند.
کلید فرار از deadlock در 0.CL پیدا کردن یک «early-response gadget» است — یعنی راهی برای وادار کردن back-end به پاسخ دادن قبل از دریافت کامل body.
یکی از نمونه‌های کشف‌شده:
درخواست مسیر /con روی IIS باعث فعال شدن یک رفتار قدیمی ویندوز می‌شود که پاسخ زودهنگام ایجاد می‌کند.
تکنیکی به نام «double-desync» دو درخواست را زنجیره می‌کند تا حملهٔ 0.CL را به یک حملهٔ عملیاتی و قابل‌استفاده از نوع CL.0 تبدیل کند.

3. حملات Desync مبتنی بر Expect
هدر Expect: 100-continue درخواست HTTP را به یک فرآیند دو مرحله‌ای تبدیل می‌کند و مدیریت صحیح آن برای reverse proxyها بسیار پیچیده است.
مشخص شد که هم هدرهای Expect معمولی و هم نسخه‌های obfuscated آن می‌توانند روی زیرساخت‌های بزرگ باعث desyncهای نوع 0.CL و CL.0 شوند.

یافته‌های مهم در دنیای واقعی
Cloudflare:
یک desync از نوع H2.0 در زیرساخت داخلی Cloudflare بیش از ۲۴ میلیون وب‌سایت را در معرض تصاحب کامل قرار داد. مشکل ظرف چند ساعت patch شد و ۷۰۰۰ دلار bounty پرداخت شد.

Akamai CDN:
یک desync از نوع CL.0 از طریق هدر Expect مبهم‌شده (CVE-2025-32094) تعداد بسیار زیادی از سایت‌های میزبانی‌شده روی Akamai را تحت تأثیر قرار داد.
در مجموع ۷۴ bounty جداگانه ثبت شد که مجموعاً ۲۲۱ هزار دلار پرداخت داشت و رفع کامل مشکل ۶۵ روز زمان برد.

Netlify:
یک آسیب‌پذیری CL.0 RQP باعث شد جریان مداومی از پاسخ‌ها از تمام وب‌سایت‌های CDN نتلیفای ارسال شود و tokenهای احراز هویت و محتوای سایت‌های ثالث افشا گردد.
همچنین سرویس‌های:
T-Mobile
GitLab
LastPass (auth.lastpass.com)
نیز از طریق desyncهای مبتنی بر Expect مورد نفوذ قرار گرفتند.

مجموع bountyهای این تحقیق: بیش از ۳۵۰ هزار دلار

راه‌حل
HTTP/2 یک پروتکل باینری است که دربارهٔ طول پیام‌ها هیچ ابهامی ندارد؛ به همین دلیل احتمال بروز آسیب‌پذیری‌های desync در آن بسیار کمتر است.
اما downgrade کردن HTTP/2 — یعنی زمانی که front-end با کلاینت HTTP/2 صحبت می‌کند ولی upstream را به HTTP/1.1 بازنویسی می‌کند — تقریباً مزیت امنیتی خاصی ندارد و حتی سایت‌ها را بیشتر در معرض خطر قرار می‌دهد.
فروشنده‌ها و سرویس‌هایی که از HTTP/2 در upstream پشتیبانی می‌کنند:
HAProxy
F5
Google Cloud
Imperva
Apache (به‌صورت آزمایشی)
Cloudflare (هرچند هنوز در داخل از HTTP/1 استفاده می‌کند)
سرویس‌هایی که هنوز upstream HTTP/2 ندارند:
nginx
Akamai
CloudFront
Fastly
پیام پایانی مقاله:

«حملات desync بیشتری همیشه در راه هستند»

و تنها راه‌حل واقعی این است که HTTP/1.1 در ارتباطات upstream کاملاً حذف شود.

منبع:
https://portswigger.net/research/http1-must-die

باورم نمیشه
یه باگ لینوکس که فکر کنم چند ماه پیش کشف شد ( تمام لینوکس هارو در بر میگیره ) که باهاش میشه بدون هیچ چیزی به دسترسی root رسید.

فقط یه اسکریپت پایتونه که ران کردنش باعث میشه به root دسترسی مستقیم پیدا کنین ...!

لینک یوتیوب جادی:
https://youtu.be/0GUEoWEDqlo

فیلم کم حجمشم همینجا فرستادم که بتونین ببینین اگه یوتیوب سخت براتون باز میشه

https://t.me/jadivarlog/483

همین الان بعدیشم اومد😂😂😂😂
دیروز پابلیک شده

فیلم کم حجمش، اگه دسترسی به یوتیوب ندارین ...

چیزی نیست فقط ۴ هزار میلیارد تومان
چیز خاصی نیست که

بخدا ۱ میلیارد بده من برات اینستاهم میگیرم، واتساپ که هیچی

یه ویدیو رو تقریبا دو ماه پیش قبل از قطع شدن اینترنت گذاشته بودم روی یوتوب، از اون موقع پرایوت بود

فردا شب پابلیک میشه ساعت 8 شب
بنظرم سکوت رو کم کم بشکنیم بهتره، با هیچ کاری نکردن چیزی درست نمیشه

دیگه امنیت نداریم بخدا
خیلی مراقب پروژه ها و سیستم هاتون باشین !!!

یک ویروس جدید با احتمال یک‌ششم، سیستم‌های ایران یا اسرائیل را پاک می‌کند

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

هکرها کدهای مخرب را به ده‌ها مخزن متن‌باز، از جمله کتابخانه پایتون Mistral AI و بیش از ۱۵۰ بسته دیگر، تزریق کردند.

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

دیگه فکر کنم بیشترشون رفع شدن
زیاد توی پایتون خرابکاری نکردن
بیشتر توی npm رو ترکوندن

دلیل اینکه هنوز ویدیو رو نزاشتم چون گوشیم ترکید و ندارم الان، با کامپیوتر هم نمیتونم وارد اکانتم بشم چون پسورد شو فراموش کردم :)

امشب ساعت 8 به وقت ایران ❤️

توی این ویدیو با قابلیت Popover API در HTML آشنا میشی :)
این قابلیت باعث میشه خیلی بهینه تر بعضی کارهایی که تا الان با JS انجام میدادیم رو انجام بدیم. و البته ساده تر...

📺 اینجا تماشا کنید:
https://youtu.be/FBCOtw1i3UY