چک لیست هدر های HTTP که هکر ها باید بدونن و تکنیک های بایپس کردن اونا توی یه خط


@Linuxor

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

google.github.io/eng-practices

@Linuxor

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

heroicons.com

@Linuxor

🐍 برگه تقلب دستورات پایتون



Contact Us : @Prsiaman
Channel : @prsian_store

https://www.linkedin.com/posts/shima-safdari-142501219_%D8%AF%D8%B1-%D9%BE%D8%B1%D9%88%DA%98%D9%87%D9%87%D8%A7%DB%8C-devops-%D9%88-%D8%AA%DB%8C%D9%85%D9%87%D8%A7%DB%8C-%D8%AD%D8%B1%D9%81%D9%87%D8%A7%DB%8C-%D8%AD%D9%81%D8%A7%D8%B8%D8%AA-activity-7365437014009171969-xxX_?

شرکت digitalplat یه طرح گذاشته می‌تونید دامنه رایگان بگیرید ازش ! کنترل کامل DNS هم دست خودتونه

github.com/DigitalPlatDev/FreeDomain

@Linuxor

چیکار کنیم وقتی به اشتباه تو برنچ main پوش میکنیم؟!

دیروز داشتم کد میزدم و پوش میکردم یهو دیدم که دارم توی برنچ main پوش میکنم!!!

داشتیم pair-programming میکردیم و اصلا حواسم نبود ولی خوب همیشه یه راهی باید باشه، نه؟

باید این مراحل رو انجام بدیم:

1- پیدا کردن کامیت آخرین کامیت درست
git log --oneline
با این دستور تاریخچه کامیت ها رو میتونیم ببینیم

path\to\repo> git log --oneline
e74c0b4 (HEAD -> main) by mistake commit 2
d86e63f by mistake commit 1
ed658f3 latest good commit
7975f4e previous commits

2- تغییر برنج به کامیت درست
git reset --hard <commit-hash>

طبق تاریخچه بالا میخوایم به کامیت ed658f3 برگردیم پس:

git reset --hard ed658f3

3- پوش کردن تغییرات
با این دستور برنچ main رو آپدیت میکنیم

git push origin main --force

و تمام!

خوب چندتا سوال پیش میاد؟
1- چرا من تونسته بودم مستقیم روی برنچ main پوش کنم؟
چون ادمین ریپو هستم

2- خوب چرا پوش رو نبستی روی main؟
چون گیتاپ اگر بخوای Rule ست کنی برای ریپوی خصوصی باید گیتاپ Enterprise داشته باشی

چطوری مسیج کامیت‌های گذشته رو عوض کنیم؟

یه چالش دیگه هم که اخیرا درموردش سرچ کردم و توی کار بهش برخوردیم این بود که بریم commit message های چند کامیت قبلی رو تغییر بدیم، کامیت آخر که راحت ترین راه براش کامند معروف زیر هست:

git command --ammend

ولی برای مثلا تغییر دادن پیام کامیت دهم بهترین روش این هست:

Interactive Git Rebasing

با استفاده از کامند:

git rebase -i Head~N

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

وقتی که یه interactive rebase انجام می‌دیم پشت صحنه گیت یه فایل تو دو لیست داخل ادیتور باز می‌کنه و کامیت‌ها رو از از قدیمی ترین به جدیدترین ( بالا به پایین) نمایش می‌ده و می‌تونیم انتخاب کنیم که مرحله بعدی برای کامیت چه کاری می‌خوایم انجام بدیم:

Pick: استفاده از کامیت به همون شکل فعلی

Reword: استفاده از کامیت ولی با ویرایش پیام

Edit: استفاده از کامیت اما با یه وقفه برای تغییر محتوا یا پیام

Squash: مرج کردن این کامیت با کامیت قبلی و با ترکیب کردن پیام اون ها

Fixup: مرج کامیت فعلی با کامیت قبلی بدون نگه داشتن پیام

Drop: حذف کامل کامیت

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


نکات قابل ملاحظه در کار تیمی:

قطعا این کار هیستوری رو عوض می‌کنه و اگه این ربپوی مشترک باشه باید از دستور

git push --force

استفاده کنید که خب بقیه تیم هم باید rebase کنن یا کانفلیکت های احتمالی رو حل کنن که به نظرم به دردسرش نمی‌ارزه.

و اینکه گیت یه قابلیت داره که میشه نوت اضافه کرد و ضمیمه کامیت کرد اگه خیلی توضیح ضروری‌ای باشه که جا افتاده.

git notes add -m "message" <commit hash>

و در نهایت اگه ریپوی لوکال باشه بهتره که این راه رو بریم.
#git

محتوای هک، امنیت، هانت و آموزشی

@ELITE_DRAGONS

@ERO40

روش رفع مسدود شدن اکانت لینکدین

https://tajrobe.wiki/blog/fix-restricted-linkedin-account

#کاربردی

ادامه راه های رفع مسدودی لینکدین

https://www.linkedin.com/posts/zeinab-khakpour-0096b5225_%DB%B4-%D9%87%D9%81%D8%AA%D9%87-%D8%B7%D9%88%D9%84-%DA%A9%D8%B4%DB%8C%D8%AF-%D8%AA%D8%A7-%D8%AF%D9%88%D8%A8%D8%A7%D8%B1%D9%87-%D9%88%D8%A7%D8%B1%D8%AF-%D8%A7%DA%A9%D8%A7%D9%86%D8%AA-%D9%84%DB%8C%D9%86%DA%A9%D8%AF%DB%8C%D9%86%D9%85-activity-7362470528726581248-cr7X?utm_source=share&utm_medium=member_android&rcm=ACoAAD0lsT0BtYSF42wgWR-cYqcAiCrCBgM5hJc

اگر از Docker Desktop استفاده می‌کنید حتما باید آپدیتش کنید؛ یک vulnerability سطح بالا توی نحوه پیاده‌سازی داره (آپدیت آخر مشکل رو حل کرده)

https://nvd.nist.gov/vuln/detail/CVE-2025-9074

این مورد باعث میشه با ۲ خط کد بشه تمام موارد امنیتی رو دور زد و به سیستم عامل اصلی دسترسی گرفت.

توی گزارش اصلی فقط ویندوز گفته شده (نمی‌دونم مک هم داره یا نه)

اینم یه لیست دیگه از دوره های رایگان و همراه با مدرک دانشگاه های معتبر برای مهندسی کامپیوتر

github.com/ForrestKnight/open-source-cs

@Linuxor

[ Source >> @srfirouzi_channel ]

#مهندسی_نرم_افزار

آنتی‌پترن‌ها در برنامه‌نویسی
(الگوهای که باید از آنها دوری کرد)

در دنیای توسعه نرم‌افزار، الگوهای طراحی (Design Patterns) راه‌حل‌هایی اثبات‌شده برای مشکلات تکراری هستند. در مقابل، آنتی‌پترن (Anti-Pattern) ظاهراً راه‌حلی منطقی ارائه می‌دهد، اما در عمل به مشکلات جدی و هزینه‌های بلندمدت منجر می‌شود.
ویژگی کلیدی آنتی‌پترن این است که همیشه یک راه‌حل بهتر و جایگزین برای آن وجود دارد.

این مفهوم از دهه‌ی ۹۰ میلادی وارد ادبیات مهندسی نرم‌افزار شد و کتاب AntiPatterns (۱۹۹۸) به شناخته شدن آن کمک زیادی کرد.
نمونه‌های رایج آنتی‌پترن‌ها

- اسپاگتی کد (Spaghetti Code): کدی درهم‌تنیده و بی‌ساختار که تغییر یا توسعه‌اش کابوس است.
- شی خدا (God Object): کلاسی که بیش از حد مسئولیت دارد و اصل Single Responsibility را زیر پا می‌گذارد.
- چکش طلایی (Golden Hammer): استفاده از یک ابزار، متد یا تکنولوژی برای همه‌چیز، فقط به خاطر آشنایی یا راحتی.
- بهینه‌سازی زودهنگام (Premature Optimization): بهینه‌سازی‌ای که اغلب پیچیدگی بیهوده ایجاد می‌کند.
- کپی و پیست (Copy-and-Paste Programming): تکرار کد در بخش‌های مختلف به جای استفاده از انتزاع و ماژولار کردن.
- جریان مذاب (Lava Flow): باقی ماندن کدهای قدیمی و بلااستفاده که فهم و نگهداری پروژه را دشوار می‌کند.
- طراحی بیش از حد (Overdesign): افزودن پیچیدگی و امکانات غیرضروری برای نیازهایی که هنوز وجود ندارند
- و ...


چگونه از آنتی‌پترن‌ها دوری کنیم؟

- از همه مهمتر آشنایی با آنتی پترن های مطرح
- بازبینی مستمر کد (Code Review).
- بازسازی ساختار کد (Refactoring) بدون تغییر رفتار.
- رعایت اصول ساده و پایه‌ای مانند:
DRY (Don’t Repeat Yourself)
KISS (Keep It Simple, Stupid)
- انتخاب ابزار و تکنولوژی بر اساس نیاز واقعی، نه صرفاً تجربه یا سلیقه شخصی.
- تمرکز بر حل مسئله‌ی فعلی و پرهیز از طراحی بیش‌ازحد برای آینده‌ای نامعلوم.


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

🚁 Hicte Blog | (smm)

یه حرکتی که امروز با iptables زدم رو خدمتتون بگم شاید به درد شما هم بخوره :))

معمولا تیم های امنیت خیلی از پورت ها رو میبندن ولی پورت ۸۰ و ۴۴۳ معمولا بازه برای سرویس وب و ریکوست های http

ما قرار بود یه سری دیتا رو از یه دیتاسنتر انتقال بدیم یه دیتاسنتر دیگه ولی تیم امنیت پورت sshرو بین دوتا دیتاسنتر بسته بود. فلذا ما نمیتونستیم با scp یا rsync دیتا رو انتقال بدیم.

اولین ایده این بود که دیتا بیاریم روی یه سرور واسط (مثلا لپ تاپ خودمون) و بعد از اونجا مجدد انتقالش بدیم رو سرور مقصد.

ولی یه کار دیگه هم میشه کرد.
معمولا شما وب سرورت تو محیط پروداکشن همیشه باید رو ۴۴۳ لیسن کنه و اصلا ریکوست پورت ۸۰ قبول نکنه یا اگرم قبول کرد ریدایرکت کنه به ۴۴۳.

من یه رول iptables زدم اگر درخواستی اومد به پورت 80 شما ریداریکت کن به ۲۲ و اینطوری قبل از اینکه وب سرور بخواد ریدارکت کنه تو لایه پایینتر شما داری ریدایرکت میکنی.

حالا ما الان داریم rsync رو روی پورت ۸۰ انجام میدیم که بازه و اینطوری تیم امنیت رو یه کوچولو دور میزنیم :))

پ.ن: میشه پورت sshرو هم انداخت روی ۸۰ که بازه ولی خب ما معذوریت داشتیم و امکانش نبود