قانون پارتو توی ایران هم کلی مثال واقعی داره. مثلاً در اسنپ‌باکس، کسب‌وکارها فقط حدود یک‌سوم کاربران رو تشکیل می‌دادن، اما نزدیک به ۸۰ درصد سفرهای این سرویس از سمت همین گروه می‌اومد. یعنی همه کاربران به یک اندازه اثرگذار نیستن؛ یک سگمنت خاص می‌تونه بار اصلی مصرف، درآمد و حساسیت محصول رو بسازه.

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

@codehalics | کدهالیک

صبح زیباتون رو با خبر هک TanStack شروع کنیم؛ همون اکوسیستمی که React Query یا TanStack Query از دلش اومده. طبق گزارش Snyk، در حمله زنجیره تأمین npm، ده‌ها پکیج @tanstack آلوده منتشر شده و هدف اصلی هم سرقت اطلاعات و توکن‌های CI/CD بوده.

https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

@codehalics | کدهالیک

نکته مهم اینجاست که طبق گزارش خود TanStack، پکیج‌های خانواده Query آلوده نبوده‌اند. بنابراین تیتر دقیق ماجرا این نیست که «React Query هک شد».
اتفاق اصلی در بخشی از اکوسیستم TanStack و از مسیر GitHub Actions، کش آلوده و فرآیند انتشار پکیج‌های npm رخ داده است.
ماجرا از یک Pull Request ظاهراً عادی شروع شد. مهاجم‌ها از یک الگوی خطرناک در GitHub Actions به نام pull_request_target سوءاستفاده کردند.

این workflow کدی را که از سمت یک fork بیرونی آمده بود اجرا کرد و همان‌جا مسیر آلودگی باز شد. کد مخرب مستقیماً همان لحظه پکیجی منتشر نکرد، بلکه cache مربوط به pnpm را آلوده کرد.
چند ساعت بعد، زمانی که یکی از maintainerهای اصلی TanStack یک تغییر سالم را merge کرد، release workflow رسمی اجرا شد. اما این workflow در زمان اجرا از همان cache آلوده استفاده کرد.
در این مرحله، بدافزار توانست از حافظه GitHub Actions Runner توکن OIDC را استخراج کند و با همان توکن، بدون اینکه npm token کسی دزدیده شده باشد، نسخه‌های آلوده را روی npm منتشر کند.
نتیجه این شد که در تاریخ ۱۱ می ۲۰۲۶، طی حدود ۶ دقیقه، ۸۴ نسخه آلوده از ۴۲ پکیج tanstack/* روی npm منتشر شد.

این نسخه‌ها در زمان نصب با npm install، pnpm install یا yarn install می‌توانستند روی سیستم توسعه‌دهنده یا محیط CI اجرا شوند و به دنبال اطلاعات حساسی مثل توکن‌های AWS، GCP، Kubernetes، Vault، GitHub، npm، فایل‌های .npmrc و کلیدهای SSH بگردند.

اهمیت این خبر دقیقاً همین‌جاست. این فقط یک باگ در یک کتابخانه فرانت‌اند نبود؛ یک نمونه جدی از حمله به زنجیره تأمین نرم‌افزار بود.
یعنی به‌جای حمله مستقیم به اپلیکیشن‌ها، مهاجم سراغ ابزارها و پکیج‌هایی رفته که هزاران پروژه به آن‌ها اعتماد می‌کنند.
خوش‌شانسی ماجرا این بود که نسخه‌های آلوده خیلی زود شناسایی شدند. حدود ۲۰ دقیقه بعد از انتشار، یک researcher خارجی الگوی مشکوک را گزارش کرد و تیم TanStack هم سریع وارد incident response شد.

نسخه‌های آلوده deprecated شدند، cacheها پاک شدند، دسترسی‌ها محدود شد و موضوع با npm security پیگیری شد.
در نهایت بخشی از اکوسیستم TanStack از مسیر GitHub Actions و npm supply chain آلوده شده است.

اگر کسی در تاریخ ۱۱ می ۲۰۲۶ نسخه‌های affected را نصب کرده، باید سیستم نصب‌کننده را potentially compromised فرض کند و credentialهای مهم مثل GitHub، npm، AWS، GCP، Kubernetes، Vault و SSH را rotate کند.

@codehalics | کدهالیک

حالا بهتر می‌فهمم چرا بعضی SDKهای جدید، مخصوصاً در اکوسیستم‌هایی مثل Telegram Mini Apps، تا این حد روی zero-dependency بودن حساس شده‌اند.

ماجرا فقط سبک‌تر شدن پکیج یا کم شدن حجم bundle نیست. بحث اصلی امنیت زنجیره تأمین است.

وقتی یک SDK وابستگی خارجی ندارد، یعنی با نصب آن، یک زنجیره بلند از پکیج‌های ناشناس، maintainerهای مختلف، workflowهای جداگانه و releaseهای غیرقابل‌ردیابی وارد پروژه نمی‌شود.

در اکوسیستم npm، خطر فقط خود پکیجی نیست که نصب می‌کنیم. خطر واقعی گاهی در dependencyهای عمیق‌تر است؛ همان پکیج‌های کوچکی که مستقیم نمی‌شناسیم، اما در زمان install یا build می‌توانند کد اجرا کنند.

اتفاق TanStack دقیقاً همین را دوباره یادآوری کرد. مهاجم لازم نداشت مستقیم به اپلیکیشن نهایی حمله کند. کافی بود بخشی از مسیر build، cache و release را آلوده کند تا نسخه‌های مخرب از چند پکیج منتشر شوند.

برای همین zero-dependency یک تصمیم صرفاً فنی نیست؛ یک تصمیم امنیتی است.

یعنی تیم توسعه می‌گوید تا وقتی واقعاً مجبور نیستیم، اعتمادمان را بین ده‌ها پکیج و maintainer پخش نمی‌کنیم. هر dependency جدید، فقط چند کیلوبایت کد اضافه نیست؛ یک نقطه اعتماد جدید است.

البته zero-dependency یعنی ریسک کمتر، نه امنیت مطلق. خود همان پکیج هم ممکن است compromise شود، release pipeline آن هم ممکن است آسیب ببیند، اما حداقل سطح حمله کوچک‌تر می‌شود.

پس وقتی می‌بینیم یک SDK جدی تلاش می‌کند بدون dependency خارجی کار کند، دلیلش فقط performance نیست. بخشی از ماجرا این است که هک کردنش سخت‌تر شود، audit کردنش ساده‌تر باشد و زنجیره اعتمادی که وارد پروژه می‌کند کوتاه‌تر بماند.

درس ساده ماجرا:

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

البته شما از tanstack استفاده کنین اینجا ایرانه چرخ از اول اختراع نکنین خواهشا خداروشکر ما ها اینترنت نداریم که هک بشیم ( البته کاش داشتیم هک میشدیم ولی وضعمون این نبود )

@codehalics | کدهالیک

فک کنم در جریان Rust-base شدن Bun هستید؛
امروز بالاخره Bun Image رو ریلیز کرد و صادقانه یکی از جذاب‌ترین فیچراییه که تا الان برای این ران‌تایم دیدم
دیگه لازم نیست برای image processing سمت سرور برید سراغ پکیج‌هایی مثل Sharp (همون چیزی که Next.js هم استفاده می‌کنه).
خود Bun یه image processor نیتیو نوشته که مستقیم توی ران‌تایم کار می‌کنه؛
با چند خط ساده می‌تونید resize کنید، کیفیت عکس رو کم کنید، فرمت عوض کنید، crop بزنید و کلی کار دیگه.
مثلاً:
const image = await Bun.file("./photo.jpg").image();

await image
.resize(800, 800)
.jpeg({ quality: 70 })
.write("./optimized.jpg");

بنظرم یه سر به ریپو bun بزنین چیزای باحالی تو این ران تایم هست ک میتونید ازش استفاده کنید

@codehalics | کدهالیک

این حرفی که این آقا میزنه رو من صد در صد باهاش موافقم چون خودم یه بار این مسیرو رفتم و واقعا دیدم که کار جالبی نیست این هزینه بابت این لپتاپ به این سنگینی !

feel free to change my mind btw ...

پ.ن : البته بگم این عقیده حداقل یه بابای پولدار یا یه خط ۱ ۹۱۲ یا ... میخواد الان متاسفانه قبلا اینطوری نبود با ۴ تا قرض و قوله میشد مک بخری الان نمیشه ولی اگر پولشو داشتید نکنید اینکارو مک بخرید برای برنامه نویسی !

@codehalics | کدهالیک

من توی فرانت چپتر ۱۴۰۲ دقیقا همین اتفاق برام افتاد یه لجیون داشتم خدا ! بعد هر کی میومد مک اش در میاورد بدون شارژر بدون هیچی
من رفتم بالا این گولاخ دراوردم شارژر میخواست شارژ نداشت اصلا جاش نمیشد تو اون استند جایی که میخوام توضیح بدم و خلاصه یه طور خاصی بود که فهمیدم از بعد اون چرا مردم میرن مک میخرن !

بازم میگم این عقیده برای قبل دلار ۱۸۵ ت ای پایدار و استیبل بود الان دیگ کلا هر چی گیرتون اومد بخرید واقعا از این گرون تر نشه !

@codehalics | کدهالیک

اگر پروژه خاصی دارید که دارید روش کار می‌کنید، Claude همین الان این لینک رو گذاشت برای کسایی که می‌خوان open source کار بکنن روی پروژه‌هاشون و بهتون Claude Max 20X رو می‌ده کاملاً رایگان.

https://claude.com/contact-sales/claude-for-oss

@codehalics | کدهالیک

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

شاید ذهن هم چیزی شبیه یک سیستم پیچیده باشد؛ سیستمی که قضاوت می‌کند، تصمیم می‌گیرد، خطا می‌کند، یاد می‌گیرد و در طول زمان evolve می‌شود.
از این زاویه، تفکر انتقادی و فراشناخت فقط مهارت‌های ذهنی نیستند؛ نوعی مهندسیِ خودآگاهانه‌اند.

این نوشته تلاشی است برای نگاه کردن به ذهن، نه از درونِ عادت‌های روزمره، بلکه از بیرونِ یک نگاه سیستمی.

این مقاله از محمد حسن رشیدی که تکنیکال لید آسان پرداخت هست رو حتما بخونید !
تقریبا اولین مقاله فارسیه که من دارم اینجا ریفر میدم که خونده شه

لینک مقاله در لینکدین

@codehalics | کدهالیک

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

جناب رشیدی بعد وارد بحث تفکر انتقادی و فراشناخت می‌شه. تفکر انتقادی یعنی فقط سریع و خودکار فکر نکنیم، بلکه باورها و نتیجه‌گیری‌هامون رو بررسی کنیم. فراشناخت هم یعنی بتوانیم به خودِ فرایند فکر کردن‌مان نگاه کنیم و بفهمیم کجا ممکنه دچار خطا، سوگیری یا خودفریبی شده باشیم. مثلا confirmation bias باعث می‌شه فقط اطلاعاتی رو ببینیم که باورهای قبلی‌مون رو تأیید می‌کنه.

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

جمع‌بندی مقاله اینه که تفکر انتقادی و فراشناخت می‌تونن نوعی «مهندسی ذهن» باشند؛ یعنی به جای اینکه هر خروجی ذهن رو بی‌چون‌وچرا قبول کنیم، ورودی‌ها، پردازش‌ها و خروجی‌های ذهنی‌مون رو بررسی کنیم. در نهایت، رشد واقعی فقط به بیشتر دانستن نیست، بلکه به بهتر فکر کردن وابسته است.

@codehalics | کدهالیک

حالا که صحبت از سوگیری تاییدی یا کانفرمیشن بایاس شد داغ دل من تازه شد که چند روزه قوانین مهندسی نرم افزار رو نگفتم خب پس بریم ادامه قوانین مهندسی نرم افزار :

سوگیری تأییدی یعنی ذهن ما معمولاً دنبال چیزهایی می‌گردد که حرف، حدس یا باور قبلی‌مان را تأیید کند؛ نه چیزهایی که آن را به چالش بکشد. مثلا وقتی یک برنامه‌نویس فکر می‌کند باگ از ماژول A است، ممکن است فقط همان بخش را زیر و رو کند و خطاهای ماژول B را نبیند، چون از قبل تصمیم گرفته «مشکل آنجاست». این اتفاق در کد ریویو هم می‌افتد؛ اگر به یک نفر اعتماد زیادی داشته باشیم، شاید کدش را سطحی‌تر ببینیم، یا اگر از یک نیروی junior انتظار خطا داشته باشیم، ممکن است چیزهای کم‌اهمیت را جدی تلقی کنیم.


#lawsofsoftwareengineering

@codehalics | کدهالیک

راهکار چیه حالا :
برای کم کردن این خطا باید عمداً خلاف حدس خودمان را هم بررسی کنیم. یعنی وقتی نظری داریم، از خودمان بپرسیم: «اگر اشتباه کنم، چه نشانه‌ای باید ببینم؟» در تصمیم‌های تیمی هم بهتر است فقط دنبال تأیید نظر جمع نباشیم؛ مثلاً اگر همه فکر می‌کنند یک تکنولوژی بهترین انتخاب است، یک نفر مأمور شود دیدگاه مخالف را بررسی کند. تست‌های خودکار، معیارهای عملکردی، آزمایش، A/B تست و کد ریویو با نگاه تازه کمک می‌کنند تصمیم‌ها کمتر بر اساس حس و تعصب باشند و بیشتر روی شواهد واقعی بنا شوند.

@codehalics | کدهالیک

قبل تر ها هم اینو بررسی کردیم اما امروز برای اینکه صحه بزارم رو صحبت دوست عزیزمون دوباره با بیان خودش بیانش کردم
اونروز یادم رفت از خاطرات خودم راجب بایاس بگم
تقریبا اگر بخوام بگم یکی از مهم ترین چیز هایی ک یه تیم نرم افزاری رو از هم میپاشونه چیه دقیقا میگم همین کانفرمیشن بایاس عه اس !
از اون سمت پروداکت میگه من درست میگم تو برنامه نویس میگی نه من درست میگم یکی دیگ میگه نه من درست میگم میزنید تو سر کله هم دیگ !

حالا سوال پیش میاد دوست دارم که جواب بدید فرض کن یه تیمی همشون دچار این بایاسه شدن و هیچ جوره حل نمیشه داستانت باهاشون رفتار تو نسبت به این داستان چیه ؟!

feel free to explain your idea in comment :

@codehalics | کدهالیک

چهار مدل این سوال در مصاحبه ها همیشه پرسیده میشه من توی 4 تیپ آوردمش جواب این سوال با جواب سوالای پایین تقریبا یکیه

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

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

اگر در محیط کار با موقعیتی مواجه شوی که بر اساس دانش، تجربه یا داده‌هایی که داری، فکر می‌کنی یک تصمیم درست نیست، اما مدیر یا فرد بالادستی‌ات با تو مخالف است، چطور موضوع را مطرح و مدیریت می‌کنی؟

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


پس در نهایت دوست دارم نظرتونو بدونم ! بعد امشب راجبش صحبت میکنیم حتما حتی اگر نظری ندادید من نظر و تجربه شخصیم توی جواب این سوال رو میگم


@codehalics | کدهالیک

بیش از دو ماهه که اینترنت توی ایران قطع شده.

توی این شرایط سخت، برنامه‌نویس ها، DevOpsها و هر کسی که به ریپوها و میرورهای Docker, Linux, NPM, Golang, Python, Java و ... نیاز داره، واقعاً به مشکل خورده.

برای همین ما پروژه «میراوا» رو ساختیم.

این پروژه یک لیست از ریپوزیتوری‌ها و میرورهای داخلی و قابل دسترس هست که تو این وضعیت کمک می‌کنه بهمون

شما می‌تونین توی سایت، راحت سرچ کنین

مثلاً ریپو برای Kali Linux رو جست‌وجو می‌کنین و دقیقاً می‌بینین که کدوم ریپو فعال هست، کدوم در دسترسه و به راحتی به منابع مورد نیازتون دست پیدا می‌کنین.

سایت پروژه:
https://miravaorg.ir/

کانال اطلاع رسانی میراوا:
https://xn--r1a.website/miravaorg

گیت‌هاب:
https://github.com/MiravaOrg/Mirava

@TehranLUG

من اگر بخوام جواب این سوال رو بدم، میگم:

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

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

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

به‌نظرم بلوغ کاری دقیقاً همین‌جاست؛ اینکه هم جرئت مخالفت داشته باشی، هم بلد باشی مخالفتت رو تبدیل به دعوای قدرت نکنی، هم وقتی تصمیم نهایی شد مسئولانه کنار تیم بمونی. چون هدف این نیست که ثابت کنم من درست می‌گفتم؛ هدف اینه که محصول، پروژه و تیم کمترین آسیب رو ببینن.

@codehalics | کدهالیک

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

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

@codehalics | کدهالیک

🚨 یه آسیب‌پذیری خیلی جدی توی Next.js پیدا شده (CVSS 8.6) که نسخه‌های 13.4.13 به بعد، سری 14 و 15، و همینطور 16.0.0 تا 16.2.4 رو درگیر کرده.

این باگ از نوع SSRF ـه و مهاجم می‌تونه فقط با یه request ساده و بدون لاگین، به سرویس‌های داخلی، API Keyها، credentialهای cloud و حتی پنل‌های ادمین دسترسی پیدا کنه

گفته میشه الان حدود ۷۹ هزار instance آسیب‌پذیر روی اینترنت وجود داره.
البته اپ‌هایی که روی Vercel هستن امن اعلام شدن و بیشتر self-hostedها در خطرن.

اگر از Next.js استفاده می‌کنید، سریعاً به نسخه‌های زیر آپدیت کنید:
✅ 15.5.16
✅ 16.2.5+

https://hadrian.io/blog/next-js-websocket-ssrf-unauthenticated-access-to-internal-resources-cve-2026-44578-2-


@codehalics | کدهالیک

هر روز اینترنتو باز می‌کنی:
«اینو هک کردیم»، «اونو اکسپلویت کردیم»، «اون‌ور بک‌دور کشف شد»...

آقا این چه وضعشه؟ یکی دوتا خبر درست‌وحسابی و امیدوارکننده بدید، شاید تو این بی‌اینترنتی یه ذره حالمون خوب شد :)))))))

من دیگه حتی حوصله ندارم بگم nginx هم امروز از گزند داسِ دروگر در امان نبوده و دوباره ترکوندنش...

exploit for CVE-2026-42945

https://github.com/DepthFirstDisclosures/Nginx-Rift

@codehalics | کدهالیک

لکسو‌رنک دقیقا برای حل مشکل reorder کردن لیست‌های خیلی بزرگه. مثلا توی جیرا وقتی یه تسک رو drag میکنی بین دوتا تسک دیگه، نمیاد position صد هزار تا رکورد رو آپدیت کنه چون از نظر دیتابیسی فاجعه‌ست. به جاش هر تسک یه rank استرینگی داره که sortable ـه و الگوریتم میتونه همیشه بین دو تا rank یه rank جدید بسازه. مثلا اگه داشته باشیم:

ali_1210
ali_1211

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

اصل ایده‌ش اینه که به جای integer sequence از fractional string استفاده میکنه. یعنی همیشه میشه قبل یا بعد یه آیتم یه rank جدید ساخت و فقط همون رکورد آپدیت میشه. برای همین performance روی board های خیلی بزرگ عالی میمونه و drag & drop عملا O(1) میشه. فقط اگر سال‌ها هی بین دو آیتم insert انجام بشه، رشته‌ها ممکنه خیلی بلند بشن و سیستم هر از گاهی یه rebalance انجام بده تا rank ها normalize بشن.


@codehalics | کدهالیک