📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: پنجم

#کتاب

‏💎 URI Query Design 💎
این بخش درباره قوانین طراحی کوئری‌های URI صحبت می‌کنه. طبق استاندارد RFC 3986، کوئری URI (که اختیاری هست) بعد از مسیر (path) و قبل از تکه‌ی اختیاری (fragment) قرار می‌گیره:

URI = schema "://" authority "/" path [ "?" query ] [ "#" fragment ]

کوئری تو URI به شناسایی منحصربه‌فرد بودن یه منبع کمک می‌کنه. به این مثال توجه کن:

https://api.college.restapi.org/students/morgan/send-sms

https://api.college.restapi.org/students/morgan/send-sms?text=hello

اولی URI یه منبعی هست که پیامک می‌فرسته. دومی همون منبع رو نشون می‌ده ولی با این تفاوت که توش پیام "hello" فرستاده می‌شه.

قسمت کوئری URI شامل یه سری پارامتره که به عنوان یه نوع تغییر یا نسخه‌ای از منبع اصلی (که تو بخش مسیر URI تعریف شده) تفسیر می‌شه. پس این دو منبع دقیقاً یکی نیستن، ولی به هم خیلی نزدیکن.

قسمت کوئری تو URI می‌تونه به کلاینت‌ها امکانات بیشتری مثل جستجو یا فیلتر کردن بده. به همین دلیل، این بخش از URI ممکنه برای کلاینت‌های یه REST API شفاف باشه (یعنی زیاد براشون مهم نباشه).

در ضمن، کل URI یه منبع باید برای واسطه‌های شبکه مثل کش‌های HTTP غیرشفاف (opaque) باشه. کش‌ها نباید رفتار خودشون رو فقط بر اساس وجود یا عدم وجود کوئری توی URI تغییر بدن. یعنی پیام‌های پاسخ نباید فقط به خاطر وجود کوئری از کش شدن حذف بشن. همونطور که تو فصل ۴ توضیح داده شده، برای کنترل رفتار واسطه‌های کش باید از هدرهای HTTP استفاده بشه، نه کوئری‌ها.

⭕️ قسمت کوئری URI می‌تونه برای فیلتر کردن کالکشن ها یا Store ها استفاده بشه.
یعنی می‌تونی ازش برای مشخص کردن معیار جستجو توی یه مجموعه یا ذخیره استفاده کنی. یه مثال بزنیم:

GET /users
GET /users?role=admin

تو درخواست اول، کلاینت از سرور لیست همه کاربران رو درخواست می‌کنه.
تو درخواست دوم، کلاینت از سرور لیست کاربرانی که نقش (role) "admin" دارن رو می‌خواد.

در واقع، قسمت کوئری (?role=admin) داره لیست کاربرا رو فیلتر می‌کنه تا فقط اونایی که نقش "admin" دارن تو پاسخ نمایش داده بشن.


⭕️ قسمت کوئری (Query) توی URI باید برای صفحه‌بندی (pagination) نتایج مجموعه یا ذخیره‌ها استفاده بشه.
کلاینت یه REST API باید از پارامترهای pageSize و pageStartIndex توی کوئری استفاده کنه. پارامتر pageSize تعداد عناصر حداکثری رو که باید توی پاسخ برگردونده بشه مشخص می‌کنه، و pageStartIndex مشخص می‌کنه که اولین عنصر از کجا شروع بشه (با ایندکس صفر).

مثال:

GET /users?pageSize=25&pageStartIndex=50

این درخواست لیستی از ۲۵ کاربر رو برمی‌گردونه که از کاربر شماره ۵۰ شروع می‌شه.

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

POST /users/search

اینجا، به جای استفاده از کوئری توی URI، کلاینت می‌تونه درخواست‌های پیچیده‌تری مثل محدوده‌های خاص یا ترتیب‌های خاص رو توی بدنه (body) پیام ارسال کنه. فقط باید مطمئن باشی که نتایج کش‌شده کنترلر به درستی مدیریت بشن.


📝 قوانین طراحی URI در REST API 📝

این خلاصه، اصطلاحات مهمی رو که تو طراحی URIs برای REST API ها به کار میره توضیح میده:
‏
🔑 Authority: بخشی از URI که مسئول فضای نام هست.
📂 Collection: نوعی منبع که مثل یه دایرکتوری از منابع سرور مدیریت می‌شه.
🛠 Controller: منبعی که عملکردهای اجرایی رو مدل‌سازی می‌کنه (مثل یه تابع).
💾 CRUD: مخفف چهار عمل اصلی: ایجاد، خواندن، بروزرسانی و حذف.
🌐 Developer portal: یه رابط کاربری وب برای جذب کلاینت‌های جدید به API.
‏🏠 Docroot: نقطه شروع مدل REST API که والد همه منابع دیگه است.
📄 Document: منبعی که یه مفهوم منفرد رو مدل‌سازی می‌کنه.
🔗 Forward slash separator (/): علامتی که برای جدا کردن منابع مرتبط در URI به کار می‌ره.
👁 Opacity of URIs: یه اصل که می‌گه ساختار URI برای کاربر نباید مهم باشه.
📍 Parent resource: منبعی که یه مفهوم زیرمجموعه رو مدیریت می‌کنه.
🔍 Query: بخشی از URI که برای جستجو و فیلتر استفاده می‌شه.
🔧 Resource archetypes: چهار نوع اصلی منابع (مستند، مجموعه، ذخیره، کنترلر).
🗄 Store: یه منبع که به‌عنوان یه مخزن مدیریت‌شده توسط کلاینت مدل‌سازی می‌شه.
📌 URI path segment: بخشی از URI که نمایانگر یه گره (node) تو مدل سلسله مراتبی منبعه.
📑 URI template: فرمت URI که شامل متغیرهایی هست که قبل از استفاده باید جایگزین بشن.

@ninja_leanr_ir

خب فصل دوم هم تموم شد و از فردا فصل ۳ رو استارت میزنیم 💪

درگیر یه پروژه شدیم و سرمون شلوغ شده به همین دلیل بعضی روزا یادمون میره پست از کتاب بذاریم لطفا به بزرگواری خودتون ببخشید 🌹

⚖ بررسی MySQL: همه چیز درباره یکی از محبوب‌ترین دیتابیس‌های دنیا 💎

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

حالا MySQL چیه؟

خب MySQL یه دیتابیس رابطه‌ای (Relational) و اوپن سورس هست که توی سال 1995 ساخته شده. دیتابیس‌های رابطه‌ای یعنی دیتایی که توش ذخیره میشه توی جدول‌هایی با ردیف‌ها و ستون‌ها قرار می‌گیره و این جداول با همدیگه ارتباط دارن. 🛠️

این دیتابیس از SQL (زبان ساختارمند جستجو) برای مدیریت و پرس‌وجوی اطلاعات استفاده می‌کنه. از اونجایی که MySQL اوپن سورسه، یعنی هرکسی می‌تونه ازش به صورت رایگان استفاده کنه و حتی به کدهاش دسترسی داشته باشه. 💻

چرا MySQL محبوبه؟

1⃣ سرعت و کارایی بالا 🚀: MySQL یکی از سریع‌ترین دیتابیس‌های رابطه‌ای هست. این یعنی درخواست‌ها و عملیات‌های دیتابیس رو خیلی سریع هندل می‌کنه.

2⃣ پشتیبانی از حجم بالا 💾: MySQL می‌تونه مقیاس‌پذیر باشه و دیتابیس‌هایی با حجم زیاد و تعداد کاربران بالا رو به‌خوبی مدیریت کنه.

3⃣ سازگاری با همه چیز 🔗: این دیتابیس تقریباً با همه زبان‌های برنامه‌نویسی و فریمورک‌های محبوب مثل Python, PHP, Node.js و Django به خوبی کار می‌کنه.

- امنیت 🔒: MySQL امنیت بالایی داره و می‌تونید به راحتی دسترسی کاربران به دیتابیس رو مدیریت کنید.

- پشتیبانی از تراکنش‌ها 💡: تراکنش‌ها (Transactions) توی MySQL به شما این امکان رو میدن که چند عملیات دیتابیسی رو به صورت اتمیک انجام بدید، یعنی یا همه اون عملیات‌ها باهم انجام بشن یا هیچکدوم.

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

sudo apt-get install mysql-server

بعد از نصب، برای ورود به دیتابیس MySQL از این دستور استفاده کن:

mysql -u root -p

چطوری با MySQL کار کنیم؟

بعد از نصب، می‌تونی جداول و دیتاهای موردنظرت رو با SQL مدیریت کنی. مثلاً برای ساخت یه جدول جدید:

CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100)
);

حالا برای اضافه کردن اطلاعات:

INSERT INTO users (name, email) VALUES ('John Doe', '[email protected]');

برای گرفتن اطلاعات:

SELECT * FROM users;

کجا از MySQL استفاده کنیم؟

خب MySQL برای پروژه‌های کوچیک و بزرگ مناسبه، از سایت‌های شخصی گرفته تا اپلیکیشن‌های بزرگ و سیستم‌های پیچیده. اگه نیاز داری یه دیتابیس سبک و سریع داشته باشی که هم اوپن سورسه و هم جامعه بزرگی داره، MySQL گزینه خوبیه. خیلی از سرویس‌های بزرگ مثل Facebook, Twitter, YouTube از MySQL استفاده می‌کنن! 😯

جمع‌بندی 🎯

در کل، MySQL یه دیتابیس رابطه‌ای قدرتمند، سریع و امنه که برای مدیریت اطلاعات توی پروژه‌های مختلف عالیه. چه پروژه‌های کوچیک داشته باشی و چه پروژه‌های بزرگ، MySQL می‌تونه نیازت رو برطرف کنه. اگه دنبال یه دیتابیس اوپن سورس و همه‌کاره هستی، حتماً یه سر به MySQL بزن😎🔥

امید وارم براتون مفید بوده باشه :)

#دیتابیس #mysql #db

@ninja_learn_ir

روز برنامه نویس مبارک 🎉


۲۱ شهریور (۱۲ سپتامبر) به عنوان "روز برنامه‌نویس" شناخته می‌شود زیرا این روز، ۲۵۶مین روز سال است. عدد ۲۵۶ برای برنامه‌نویسان معنای ویژه‌ای دارد؛ چون در سیستم دودویی (باینری) که اساس کامپیوترها و برنامه‌نویسی است، ۲۵۶ بزرگ‌ترین توانی است که می‌توان با ۸ بیت (یک بایت) نشان داد. همچنین، عدد ۲۵۶ در بسیاری از مفاهیم کامپیوتری به‌ویژه حافظه و پردازش داده‌ها اهمیت زیادی دارد. به همین دلیل، روز ۲۵۶مین روز سال در تقویم میلادی به عنوان روز برنامه‌نویس انتخاب شده است.

در تقویم میلادی، اگر سال کبیسه باشد، این روز به ۱۳ سپتامبر منتقل می‌شود.


@ninja_learn_ir

💎 بررسی Zero-day Exploit و چجوری جلوشو بگیریم؟ 💎

امروز می‌خوایم در مورد یکی از خطرناک‌ترین و مرموزترین حملات امنیتی به نام Zero-day Exploit صحبت کنیم. شاید اسمش رو شنیده باشی ولی دقیق ندونی چی هست و چطوری میشه ازش جلوگیری کرد. بزن بریم که توضیح بدم 😎

حالا این Zero-day Exploit چیه؟ 🤔

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

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

مثال از Zero-day Exploit

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

چجوری جلوی Zero-day Exploit رو بگیریم؟ 🛡️

1⃣ آپدیت منظم نرم‌افزارها
   آپدیت کردن همیشه مهمه. خیلی از ما آپدیت‌ها رو پشت گوش می‌ندازیم ولی همین آپدیت‌ها معمولاً پچ‌های امنیتی مهمی دارن که می‌تونن جلوی حملات zero-day رو بگیرن. پس همیشه نرم افزار ، سخت افزار یا مروگر رو آپدیت نگه دار. 🔄

2⃣ استفاده از فایروال و آنتی‌ویروس قوی
   یه فایروال و آنتی‌ویروس خوب می‌تونن جلوی حملات مشکوک رو بگیرن یا حداقل هشدار بدن. مثلاً اگه یه برنامه یا فایل مشکوک بخواد از باگی استفاده کنه، آنتی‌ویروس می‌تونه اون رو قرنطینه کنه. 🛡️

3⃣ محدود کردن دسترسی‌ها
   یکی از راه‌های مهم برای کاهش آسیب اینه که همیشه سطوح دسترسی رو محدود کنی. یعنی نرم‌افزارها و کاربران فقط به چیزهایی که واقعاً نیاز دارن دسترسی داشته باشن. اگه هکرها وارد سیستم بشن، محدودیت دسترسی می‌تونه آسیب رو کم کنه. 🚪

4⃣ نظارت و لاگ‌گیری دقیق  
   همیشه باید روی ترافیک شبکه و سیستم‌های خودت نظارت داشته باشی. لاگ‌ها می‌تونن نشون بدن که آیا فعالیت مشکوکی اتفاق افتاده یا نه. اگه چیز غیرعادی دیدی، باید سریع اقدام کنی تا از گسترش حمله جلوگیری کنی. 👁️‍🗨️

5⃣ آموزش به کاربرها
   بیشتر حملات zero-day از طریق ایمیل‌های فیشینگ یا لینک‌های مخرب شروع میشن. آموزش به کاربرها و تیم‌ت در مورد امنیت و خطرات فیشینگ می‌تونه تا حد زیادی جلوی این حملات رو بگیره. کاربران باید بدونن روی هر لینکی کلیک نکنن! 🎣

جمع‌بندی 🎯

فهمیدیم Zero-day Exploit حمله‌ایه که خیلی خطرناکه چون قبل از اینکه فرصتی برای اصلاحش داشته باشیم، هکرها ازش استفاده می‌کنن. اما با آپدیت منظم نرم‌افزارها، استفاده از ابزارهای امنیتی مناسب و محدود کردن دسترسی‌ها می‌تونیم تا حد زیادی از خطراتش جلوگیری کنیم. 🔐

امید وارم مفید بوده باشه :)

#امنیت #ZDE

@ninja_learn_ir

مرسی از دوستانی که تو نظر سنجی شرکت کردن
این گل تقیدم شوما 🌹

💎 پکیج Django Cleanup مدیریت خودکار فایل‌های اضافی 💎

امروز می‌خوام در مورد یه کتابخونه خیلی کاربردی به اسم Django Cleanup صحبت کنم که کلی از مشکلات مربوط به مدیریت فایل‌ها رو توی پروژه‌های جنگو حل می‌کنه. 😎 اگه تا حالا با فایل‌های اضافی و بی‌استفاده دست‌وپنجه نرم کردی، این کتابخونه می‌تونه حسابی به کارت بیاد.

حالا Django Cleanup چیه؟ 🤔
به طور خلاصه، Django Cleanup به صورت خودکار فایل‌ها و تصویرهای ذخیره‌شده توی پروژه رو مدیریت می‌کنه. فرض کن یه فایل یا عکس توی پروژه آپلود کردی و بعد اون رکورد یا مدل رو حذف کردی. معمولاً فایل مرتبط توی سرور باقی می‌مونه و فضای سرور رو اشغال می‌کنه. 😒 Django Cleanup این فایل‌های اضافی رو به صورت خودکار حذف می‌کنه تا دیگه نیاز نباشه خودت دستی این کارو انجام بدی.

چرا Django Cleanup کاربردیه؟ 🤔

1⃣ مدیریت خودکار فایل‌های اضافه 🗑️:

بعد از حذف رکوردهای مدل، فایل‌های مرتبط بهش هم خود به خود حذف میشن.

2⃣ جلوگیری از انباشت فایل‌های اضافی 🚮:

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

3⃣ ساده و راحت در استفاده 🛠️:

فقط با نصب و یه سری تنظیمات ساده، همه چی رو هندل می‌کنه.

چطوری نصبش کنیم؟ 🛠️
نصب و استفاده از Django Cleanup خیلی ساده‌ست. اول از همه باید نصبش کنی:

pip install django-cleanup

بعد از نصب، باید این کتابخونه رو به تنظیمات جنگو اضافه کنی:

INSTALLED_APPS = [
    # بقیه اپ‌ها...
    'django_cleanup.apps.CleanupConfig',
]

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

مثال از استفاده 📂
فرض کن یه مدل ساده برای کاربر داری که یه عکس آپلود می‌کنه:

class UserProfile(models.Model):
    avatar = models.ImageField(upload_to='avatars/')

وقتی یه پروفایل کاربر رو حذف می‌کنی، فایل avatar مربوط به اون کاربر هم به صورت خودکار از پوشه avatars/ پاک میشه و دیگه فضای اضافی نمی‌گیره.

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

امید وارم مفید بوده باشه :)

#django #django_clean_up #trick

@ninja_learn_ir

💎 ردیس (Redis) چیه و چرا اینقدر محبوبه؟ 💎

امروز می‌خوام در مورد Redis صحبت کنم. شاید اسمشو شنیده باشی ولی ندونی دقیقاً چیه و چه کاربردی داره. بیاید یه نگاه دقیق‌تر بندازیم به این دیتابیس پرسرعت و جذاب 😎

حالا Redis چیه؟ 🤔

خب Redis یه دیتابیس NoSQL از نوع In-memory هستش. یعنی داده‌ها رو به‌جای اینکه روی دیسک ذخیره کنه، توی RAM نگه می‌داره و این باعث میشه که فوق‌العاده سریع باشه ⚡. به خاطر همین، معمولاً از Redis برای کشینگ (Caching)، مدیریت صف‌ها و ذخیره‌سازی موقت داده‌ها استفاده می‌کنن.

باید بدونید که Redis یه سری ساختار داده‌های پیچیده مثل لیست‌ها، مجموعه‌ها (Sets)، هش‌ها و حتی پایگاه‌داده‌های جفت‌کلید/مقدار رو به شکلی خیلی بهینه پشتیبانی می‌کنه. یعنی هر چی داده لازم داری باهاش کار کنی، Redis از پسش برمیاد 😁

حالا Redis چه کاربردهایی داره؟ 🔥

1⃣ کشینگ (Caching) داده‌ها:
خب Redis برای ذخیره موقت داده‌ها توی کش عالیه. مثلاً می‌تونی نتیجه درخواست‌های API یا کوئری‌های سنگین دیتابیس رو توی Redis ذخیره کنی تا دفعات بعد با سرعت بیشتری بهشون دسترسی داشته باشی 🚀
 
2⃣ مدیریت Sessionها:
توی اپلیکیشن‌های تحت وب، می‌تونی Sessionها رو توی Redis ذخیره کنی. اینجوری سریع و با امنیت بیشتری میشه اطلاعات کاربر رو نگه داشت 🔐

3⃣ مدیریت صف‌ها (Queues):
اگه با صف‌های پردازشی سروکار داری (مثل صف ایمیل‌ها یا پیام‌ها)، Redis به راحتی می‌تونه این صف‌ها رو مدیریت کنه. سرعت و پایداری Redis توی این زمینه بی‌نظیره 📩

4⃣ ذخیره داده‌های Real-time:
مثلا اگه یه اپ چت یا اپلیکیشنی که نیاز به پردازش ریل تایم داره، Redis بهترین انتخابه چون داده‌ها رو خیلی سریع مدیریت می‌کنه 🕒

چرا Redis اینقدر سریع و محبوبه؟ ⚡

1⃣ اول In-memory بودنش:
چون داده‌ها رو توی RAM نگه می‌داره، دسترسی بهشون خیلی سریعه.

2⃣ دوم پشتیبانی از ساختار داده‌های متنوع: برخلاف دیتابیس‌های سنتی، Redis ساختارهای پیشرفته‌ای مثل لیست‌ها، هش‌ها و مجموعه‌ها رو پشتیبانی می‌کنه.

3⃣ سوم سادگی در استفاده:
نصب و راه‌اندازیش خیلی راحته و استفاده از دستوراتش هم سرراست و ساده‌ست.

4⃣ چهارم پشتیبانی از Replication و Persistence:
یعنی می‌تونی داده‌ها رو بین چندین سرور کپی کنی یا اگه خواستی داده‌ها رو به دیسک هم بنویسی تا در صورت قطعی سیستم از بین نرن.

حالا چطوری Redis رو نصب و راه‌اندازی کنیم؟ 🛠️

برای نصب Redis، فقط کافیه که از دستورات زیر استفاده کنی:

روی اوبونتو:

sudo apt update
sudo apt install redis-server

بعد از نصب، Redis به طور پیش‌فرض روی پورت 6379 در حال اجراست. می‌تونی با دستور زیر مطمئن بشی که Redis درسته اجرا شده:

redis-cli ping

اگه جواب PONG رو گرفتی، یعنی Redis داره به درستی کار می‌کنه 👌

جمع‌بندی ✅

فهمیدیم Redis یه دیتابیس خیلی قدرتمند و پرسرعته که بیشتر برای کشینگ، مدیریت صف‌ها و داده‌های ریل تایم استفاده میشه. با استفاده ازش می‌تونی سرعت اپلیکیشن‌هات رو چند برابر کنی و از ساختار داده‌های پیچیده و کاربردی بهره ببری 😎

امید وارم مفید بوده باشه :)

#redis

@ninja_learn_ir

💎 حمله CSRF و چطوری ازش جلوگیری کنیم؟ 💎

امروز می‌خوایم در مورد یکی از حملات معروف تو دنیای وب، یعنی CSRF یا همون Cross-Site Request Forgery صحبت کنیم.

حالا CSRF چیه؟ 🤔

خب CSRF یه جور حمله‌ست که هکر سعی می‌کنه با سوءاستفاده از سشن (session) کاربر، کارهایی رو به نمایندگی از کاربر انجام بده بدون اینکه اون کاربر خبر داشته باشه 😱. یعنی اگه کاربر توی یه سایت لاگین کرده باشه (مثل یه بانک یا شبکه اجتماعی) و بعد روی لینک یا دکمه‌ای توی یه سایت دیگه کلیک کنه، هکر می‌تونه درخواست‌هایی رو به سایت اصلی (که کاربر لاگین کرده) بفرسته و کارهایی مثل انتقال پول یا تغییر اطلاعات کاربر رو انجام بده.

چجوری این حمله کار می‌کنه؟ 🎯

1️⃣ کاربر لاگین می‌کنه:
مثلا کاربر وارد حساب بانکی خودش میشه و یه سشن معتبر داره.

2️⃣ هکر یه لینک مخرب می‌سازه:
یه هکر توی یه سایت دیگه یه لینک یا فرم مخرب می‌سازه که درخواست‌هایی رو به حساب کاربر توی سایت بانکی ارسال می‌کنه.

3️⃣ کاربر روی لینک کلیک می‌کنه:
وقتی کاربر بدون اینکه خبر داشته باشه روی اون لینک کلیک می‌کنه، درخواست از طرف سشن کاربر به سرور سایت بانکی ارسال میشه.

4️⃣ هکر درخواست‌ها رو اجرا می‌کنه:
سرور چون کاربر لاگین کرده، درخواست رو معتبر می‌دونه و اون کار انجام میشه (مثل انتقال پول، تغییر پسورد و...)

چجوری میشه جلوی CSRF رو گرفت؟ 🛡️

1️⃣ استفاده از CSRF Token
هر وقت کاربر یه فرم رو پر می‌کنه یا عملیاتی رو انجام میده، سرور یه توکن منحصربه‌فرد به فرم اضافه می‌کنه. این توکن رو سرور چک می‌کنه تا مطمئن بشه درخواست از طرف خود کاربر ارسال شده نه یه سایت دیگه. جنگو، فلکس و خیلی از فریمورک‌های معروف به صورت پیش‌فرض از این مکانیزم پشتیبانی می‌کنن 🔑.

2️⃣ استفاده از روش POST به جای GET
برای درخواست‌هایی که نیاز به تایید کاربر دارن (مثل انتقال پول یا تغییر اطلاعات)، از POST استفاده کن، نه GET. توی درخواست‌های GET داده‌ها توی URL قرار می‌گیرن که راحت‌تر میشه ازشون سوءاستفاده کرد. با POST درخواست‌ها ایمن‌تر میشن 🛠️.

3️⃣ محدود کردن Referer Header
   سرورها می‌تونن Referer header رو چک کنن تا مطمئن بشن که درخواست‌ها از یه منبع قابل اعتماد (مثلاً همون سایت خودت) ارسال شدن نه از یه سایت دیگه‌ای که هکرها توش لینک مخرب گذاشتن. اینجوری درخواست‌های مشکوک رد میشن 🚫.

4️⃣ استفاده از Double Submit Cookies
  
   یه راه دیگه برای جلوگیری از CSRF اینه که هم از کوکی‌ها و هم از پارامترها استفاده کنی. توی این روش، یه کوکی حاوی CSRF token ارسال میشه و سرور مطمئن میشه که درخواست معتبره.

5️⃣ لاگ‌اوت خودکار
  
   اگه کاربر برای مدت زیادی هیچ فعالیتی توی سایت نداشت، اونو به صورت خودکار از سیستم خارج کن. اینجوری خطر CSRF کمتر میشه چون سشن کاربر خیلی طولانی باز نمی‌مونه ⏳.

جمع‌بندی ✅

فهمیدیم CSRF یه حمله جدیه که اگه درست ازش جلوگیری نشه، می‌تونه خیلی از اطلاعات حساس رو به خطر بندازه. با استفاده از CSRF Token، چک کردن Referer header و بقیه روش‌هایی که گفتیم، می‌تونی از اپلیکیشن‌هات در برابر این حمله محافظت کنی و امنیتشون رو بالا ببری 💪.

امید وارم مفید بوده باشه :)

#csrf #امنیت

@ninja_learn_ir

قسمت ۱۹ دوره DRF منتشر شد 🥳

برای مشاهده کلیک کنید

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

#fun

خدا بود😂😂😂

@ninja_learn_ir

🌿 استفاده از پکیج dotenv در Node.js 🌿

امروز می‌خوایم در مورد پکیج dotenv توی Node.js صحبت کنیم. شاید برات سوال شده باشه که چطوری میشه اطلاعات حساس مثل API key‌ها، پسوردها و تنظیمات مهم رو به‌صورت امن توی پروژه نگه داشت. اینجاست که dotenv میاد وسط و کار رو خیلی راحت می‌کنه! 😎

❓حالا dotenv چیه؟ 🤔
خب dotenv یه پکیجه که بهت اجازه می‌ده اطلاعات حساس رو توی یه فایل به اسم .env ذخیره کنی. به‌جای اینکه این اطلاعات رو مستقیم توی کدت بنویسی (که خیلی خطرناکه 😱)، می‌تونی توی فایل .env نگه‌شون داری و وقتی اپلیکیشن اجرا میشه، dotenv این مقادیر رو لود می‌کنه ومتغیرهای محیطی  اضافه می‌کنه.

❓چرا باید از dotenv استفاده کنیم؟ 🔐

1⃣ امنیت بیشتر:
اطلاعات حساس رو مستقیم توی کدت نمی‌نویسی

2⃣ سادگی در مدیریت تنظیماتات:
برای هر محیطی (مثل توسعه، تولید و تست) می‌تونی فایل‌های .env جداگانه داشته باشی

3⃣ خوانایی بهتر کد:
وقتی اطلاعات حساس بیرون از کد اصلی باشه، کد تمیزتر و قابل نگهداری‌تر میشه.

❓ چطوری نصبش کنیم؟ 🛠️
نصب و استفاده از dotenv خیلی ساده‌ست. اول با دستور زیر نصبش کن:

npm install dotenv

نحوه استفاده از dotenv 🚀
بعد از نصب، یه فایل .env توی پروژه‌ات بساز و اطلاعات حساسی مثل API key، پسورد دیتابیس و بقیه تنظیمات رو توش ذخیره کن. مثلا:

DB_HOST=localhost
DB_USER=root
DB_PASS=supersecret

حالا توی app.js (یا هر فایل اصلی پروژه‌ات) باید dotenv رو لود کنی:

require('dotenv').config();

با این کار، dotenv تمام اطلاعات توی فایل .env رو لود می‌کنه و می‌تونی با استفاده از process.env بهشون دسترسی داشته باشی:

const dbHost = process.env.DB_HOST;
const dbUser = process.env.DB_USER;
const dbPass = process.env.DB_PASS;

console.log(`Database: ${dbHost}, User: ${dbUser}`);

نکته مهم 🛑
هیچ‌وقت فایل .env رو توی مخزن گیت (git) قرار نده! چون ممکنه اطلاعات حساسی مثل API key‌هات لو بره. برای جلوگیری از این کار، فایل .env رو به .gitignore اضافه کن:

.env

✅ جمع‌بندی:
پکیج dotenv خیلی به دردبخوره چون هم بهت کمک می‌کنه اطلاعات حساس رو به صورت امن مدیریت کنی و هم کدت تمیزتر و سازمان‌یافته‌تر بشه. پس حتماً توی پروژه‌هات ازش استفاده کن تا هم امنیت بالا بره هم تنظیمات محیطیت راحت‌تر مدیریت بشه. 😁

امید وارم مفید بوده باشه :)

#nodejs #js #dotenv

@ninja_learn_ir

اونایی که هنوز سربازی نرفتن یه سر به پست آخرمون بزنن 😉

https://www.instagram.com/p/DADR31eIFbk/?igsh=ajNrbHltYzMxMHVu

رفقا شرمنده چند روزی میشه که پست از ادامه کتاب نذاشتیم

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

از امشب ادامه کتابو استارت میزنیم ✌️

📕 کتاب REST API Design Rulebook

📌 فصل سوم: Interaction Design with HTTP

📍پارت: اول

#کتاب

‏💎 HTTP/1.1 💎
‏APIهای REST همه جنبه‌های پروتکل HTTP نسخه ۱.۱ رو شامل می‌شن، مثل متد های درخواست، کدهای ریسپانس و هدرها. این کتاب HTTP رو به دو فصل تقسیم کرده؛ این فصل درباره متد های درخواست و استاتوس کدهای ریسپانس صحبت می‌کنه.

فصل ۴ هم درباره گنجاندن متا داده‌ها در طراحی API REST و هدرهای درخواست و پاسخ HTTP صحبت می‌کنه.

‏💎 Request Methods 💎‏
کلاینت‌ها متد تعامل مورد نظر رو در قسمت Request-Line یک درخواست HTTP مشخص می‌کنن. استاندارد RFC 2616 نحوه نوشتن Request-Line رو این‌طوری تعریف کرده:

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

هر متد HTTP معنای مشخص و خاصی در زمینه منابع REST API داره. هدف GET اینه که نمایی از وضعیت یک منبع رو بگیره. HEAD برای دریافت متا داده‌های مربوط به وضعیت منبع استفاده می‌شه. PUT باید برای به‌روزرسانی یک منبع استفاده بشه. DELETE هم برای حذف یک منبع از والدش به کار می‌ره. POST هم برای ایجاد یک منبع جدید در یک مجموعه و اجرای کنترلرها استفاده می‌شه.

‏⭕️ GET و POST نباید برای تونل‌کردن سایر متد های درخواست استفاده بشن.
تونلینگ به هر نوع سوءاستفاده از HTTP گفته می‌شه که هدف یک پیام رو پنهان یا به اشتباه نمایش می‌ده و شفافیت پروتکل رو تضعیف می‌کنه.
یک API REST نباید طراحی خودشو با سوءاستفاده از متد های درخواست HTTP برای سازگاری با کلاینت‌هایی که دانش محدودی از HTTP دارن، به خطر بندازه. همیشه باید از متد های HTTP به‌طور صحیح و طبق قواعد این بخش استفاده کنی.


‏⭕️ GET باید برای دریافت نمایی از وضعیت یک منبع استفاده بشه.
یک کلاینت REST API از متد GET در درخواستش استفاده می‌کنه تا وضعیت یک منبع رو در یک فرم نمایشی دریافت کنه. پیام درخواست GET می‌تونه شامل هدرها باشه ولی body نداره.

معماری وب به شدت به ماهیت متد GET وابسته‌است. کلاینت‌ها باید بتونن درخواست‌های GET رو تکرار کنن بدون اینکه عوارض جانبی ایجاد بشه. کش‌ها هم به این قابلیت اتکا دارن که بتونن نمایه‌های کش‌شده رو بدون تماس با سرور اصلی ارائه بدن.

در مثال زیر، می‌بینیم که چطور یک توسعه‌دهنده کلاینت ممکنه از curl در یک ترمینال برای دریافت نمایی از وضعیت فعلی یک منبع "greeting" استفاده کنه:

1️⃣ curl -v https://api.example.restapi.org/greeting

2️⃣ > GET /greeting HTTP/1.1
3️⃣ > User-Agent: curl/7.20.1
> Host: api.example.restapi.org
> Accept: */*
4️⃣ < HTTP/1.1 200 OK
5️⃣ < Date: Sat, 20 Aug 2011 16:02:40 GMT
< Server: Apache
< Expires: Sat, 20 Aug 2011 16:03:40 GMT
< Cache-Control: max-age=60, must-revalidate
< ETag: text/html:hello world
< Content-Length: 130
< Last-Modified: Sat, 20 Aug 2011 16:02:17 GMT
< Vary: Accept-Encoding
< Content-Type: text/html

6️⃣ <!doctype html><head><meta charset="utf-8"><title>Greeting</title></head>
<body><div id="greeting">Hello World!</div></body></html>

1️⃣ در اینجا، GET متد پیش‌فرض curl هست، بنابراین نیاز نیست به‌طور صریح مشخص بشه. گزینه -v هم باعث می‌شه خروجی curl جزئیات بیشتری داشته باشه.

2️⃣ خط Request-Line در درخواست نشون می‌ده که از متد GET برای منبع greeting استفاده شده.

3️⃣ لیست هدرهای پیام درخواست هم از اینجا شروع می‌شه. هدرهای درخواست و پاسخ HTTP در فصل ۴ توضیح داده شدن.

4️⃣ پیام پاسخ هم از اینجا شروع می‌شه، با خط وضعیت که در بخش "کدهای وضعیت پاسخ" در صفحه ۲۸ بحث شده. کد وضعیت ۲۰۰ OK به curl می‌گه که درخواستش موفقیت‌آمیز بوده.

5️⃣ لیست هدرهای پیام پاسخ هم از اینجا شروع می‌شه.

6️⃣ بدنه پیام ریسپانس هم از اینجا آغاز می‌شه. در این مثال، بدنه شامل یک نمای HTML از پیام خوشامدگویی هست.


⭕️ برای اینکه فقط هدرهای ریسپانس رو بگیریم بدون اینکه body دریافت کنیم، می‌تونیم از متد HEAD استفاده کنیم.
یعنی HEAD همون جواب GET رو میده، ولی بدون بدنه. از این روش میشه برای این استفاده کرد که ببینیم یه منبع وجود داره یا اینکه اطلاعات متادیتاش رو بخونیم.

مثال زیر یه دستور curl رو نشون میده که با استفاده از متد HEAD فقط هدرهای پاسخ رو می‌گیره:

curl -I https://example.com/resource

توضیح:
- -I یا --head: این گزینه به curl میگه که به جای درخواست معمولی GET`، یه درخواست `HEAD بفرسته.
- https://example.com/resource: آدرس منبعی که می‌خوایم چک کنیم رو باید اینجا بذاریم.

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

@ninja_learn_ir

HTTP/1.1 200 OK
Date: Wed, 18 Sep 2024 10:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Connection: keep-alive
Server: Apache/2.4.29 (Ubuntu)

این متد برای وقتی خوبه که بخوایم چک کنیم یه منبع هست یا نه، یا اینکه اطلاعات کلی مثل حجم محتوا و نوع سرور رو ببینیم.



⭕️ متد PUT باید هم برای اضافه کردن و هم برای به‌روزرسانی یک منبع ذخیره شده استفاده بشه. این یعنی:
- اضافه کردن یک منبع جدید: وقتی می‌خواهیم یک منبع جدید اضافه کنیم، URL یا URI (آدرس منبع) توسط کلاینت مشخص میشه.
- به‌روزرسانی یا جایگزینی منبع موجود: برای به‌روزرسانی یا جایگزینی یک منبعی که از قبل ذخیره شده هم از PUT استفاده می‌کنیم.

مثال:
فرض کنید یه API داریم که یه فروشگاه منابع رو برای کلاینت‌هاش فراهم می‌کنه تا داده‌هاشون رو به‌صورت آبجکت ذخیره کنن. درخواست PUT به این صورت می‌تونه باشه:

PUT /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

درخواست PUT:
در پیام درخواست PUT، باید نمایشی از منبعی که کلاینت می‌خواد ذخیره کنه وجود داشته باشه. ولی محتوای درخواست ممکنه دقیقاً همونی نباشه که بعداً از طریق `GET دریافت میشه. برای مثال، ممکنه API اجازه بده که کلاینت فقط بخش‌های قابل تغییر (mutable) منبع رو بفرسته.

پشتیبانی از درخواست‌های شرطی (Conditional PUT):
در بخش بعدی ("قانون: فروشگاه‌ها باید از درخواست‌های شرطی PUT پشتیبانی کنند") توضیح داده شده که چطور یه API باید از هدرهای HTTP استفاده کنه تا PUT رو برای هم اضافه کردن و هم به‌روزرسانی منابع استفاده کنه.


⭕️ متد PUT باید برای به‌روزرسانی منابع قابل تغییر استفاده بشه. یعنی وقتی یک کلاینت می‌خواد تغییراتی روی یک منبع اعمال کنه، باید از PUT استفاده کنه.
درخواست PUT باید شامل یک بدنه (body) باشه که تغییرات مورد نظر رو نشون میده. این بدنه، وضعیت جدید منبع رو مشخص می‌کنه و وقتی که درخواست پردازش بشه، منبع با این داده‌های جدید جایگزین میشه.


⭕️ از متد POST باید برای ایجاد یک منبع جدید در یک مجموعه (collection) استفاده بشه. یعنی وقتی کلاینت می‌خواد یک منبع جدید به یک مجموعه اضافه کنه، از POST استفاده می‌کنه.
بدنه (body) درخواست POST شامل یک نمایش از وضعیت پیشنهادی منبع جدیدیه که قراره به مجموعه‌ای که توسط سرور مدیریت میشه، اضافه بشه.

مثال:
فرض کنید کلاینت می‌خواد یک بازیکن جدید به یک تیم اضافه کنه:

POST /leagues/seattle/teams/trebuchet/players

توضیح:
- در اینجا درخواست POST برای اضافه کردن یک بازیکن جدید به مجموعه بازیکنان تیم "trebuchet" در لیگ "seattle" است.
- بدنه درخواست ممکنه شامل اطلاعاتی باشه که حالت اولیه بازیکن جدید رو نشون میده، مثلاً نام، سن و مشخصات دیگه.
این استفاده از POST شبیه اینه که یک پیام جدید روی یک تابلوی اعلانات قرار بدیم، یعنی یک آیتم جدید به یک مجموعه اضافه می‌کنیم.


⭕️ از متد POST برای اجرای کنترلرهای تابع‌محور (function-oriented controller resources) استفاده می‌شه. یعنی کلاینت‌ها زمانی از POST استفاده می‌کنند که بخواهند یک عملکرد یا عملیاتی رو فراخوانی کنند. پیام درخواست POST می‌تونه شامل هم هدر و هم بدنه (body) باشه که ورودی‌های لازم برای عملکرد کنترلر رو ارائه می‌ده.

نکات مهم:
- POST به صورت مفهومی "نامحدود" در نظر گرفته شده، به این معنی که این متد می‌تونه هر کاری انجام بده، صرف‌نظر از تکرارپذیری (idempotency) یا عواقب آن. به همین دلیل، POST انتخاب مناسبی برای کنترلرهای تابع‌محور هست که کارکرد مشخصی ندارند.
- از POST نباید برای گرفتن، ذخیره‌سازی یا حذف منابع استفاده بشه، چون HTTP برای هر کدام از این عملیات متدهای خاص خودش رو داره (مثل GET`، `PUT و DELETE).
‏- POST یک متد "unsafe" (ناامن) و "non-idempotent" (غیرتکرارپذیر) در نظر گرفته می‌شه. به این معنا که نتایجش غیرقابل پیش‌بینی و ممکنه تکرارش عواقب ناخواسته‌ای داشته باشه. مثلاً اگر یک فرم وب که از POST استفاده می‌کنه دوباره ارسال بشه، ممکنه باعث شارژ مضاعف کارت اعتباری کاربر بشه.

مثال:
فرض کنید کلاینت می‌خواد یک هشدار را مجدداً ارسال کنه:

POST /alerts/245743/resend

توضیح:
- در اینجا درخواست POST به کنترلر resend مربوط به هشدار مشخص شده (با آی‌دی 245743) ارسال شده تا عملیات ارسال مجدد انجام بشه.

این نوع استفاده از POST شبیه به مکانیزم "PostMessage" در سیستم‌های اجرایی (runtime) هست که به کلاینت اجازه می‌ده عملکردهایی رو از طریق یک مرز (مثل شبکه یا یک سرویس) فراخوانی کنه.


⭕️ متد DELETE باید برای حذف کامل یک منبع از والد خودش (که معمولاً یک مجموعه یا فروشگاه است) استفاده بشه. وقتی یک کلاینت درخواست DELETE می‌فرسته، هدف اینه که منبع مورد نظر به‌طور کامل حذف بشه.

@ninja_learn_ir

نکات کلیدی:
- بعد از پردازش موفقیت‌آمیز درخواست DELETE`، منبع دیگه توسط کلاینت‌ها قابل دسترسی نخواهد بود. یعنی اگر بعداً کلاینت‌ها با استفاده از متدهای `GET یا HEAD سعی کنند وضعیت اون منبع رو بگیرند، باید پاسخ 404 (Not Found) برگرده.
- DELETE در HTTP معنای خاصی داره و نباید توسط طراحی API تغییر داده یا بیش از حد بسط داده بشه. اگر API نیاز به یک حذف "نرم" (soft delete) یا یک تعامل دیگه داره که فقط حالت منبع رو تغییر می‌ده ولی اون رو کاملاً حذف نمی‌کنه، بهتره از یک کنترلر ویژه با متد POST استفاده کنه، نه DELETE.

مثال:
فرض کنید یک کلاینت می‌خواد یک سند رو از یک فروشگاه حذف کنه:

DELETE /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

توضیح:
- در اینجا درخواست DELETE برای حذف کامل شیء (document) با شناسه 4321 از داخل یک سطل (bucket) مشخص در حساب کاربری ارسال شده.

پس از موفقیت‌آمیز بودن درخواست، منبع کاملاً حذف می‌شه و هر تلاشی برای دسترسی به اون منبع با پاسخ "Not Found" مواجه می‌شه.

⭕️ متد OPTIONS باید برای دریافت متادیتایی استفاده بشه که تعاملات قابل دسترسی یک منبع رو توضیح می‌ده. کلاینت‌ها می‌تونن از درخواست OPTIONS استفاده کنن تا بفهمند چه متدهایی برای یک منبع در دسترس هستند.

نکات کلیدی:
- پاسخ به درخواست OPTIONS معمولاً شامل هدر Allow است که لیستی از متدهای HTTP قابل اجرا روی منبع رو نشان می‌ده. برای مثال:

    Allow: GET, PUT, DELETE
    

- علاوه بر این، یک API ممکنه در بدنه پاسخ (response body) جزئیات بیشتری درباره هر گزینه تعامل فراهم کنه. این جزئیات می‌تونن شامل فهرستی از فرم‌های ارتباط (link relation forms) باشند که نحوه تعامل با منبع رو نشان می‌دهند.

مثال:
فرض کنید یک کلاینت می‌خواد بفهمه که چه متدهایی روی یک منبع خاص در دسترس هستند:

OPTIONS /accounts/4ef2d5d0-cb7e-11e0-9572-0800200c9a66/buckets/objects/4321

پاسخ:
API ممکنه هدر Allow رو برگردونه که نشون می‌ده کدوم متدها روی منبع مورد نظر قابل استفاده هستند. برای مثال:

Allow: GET, PUT, DELETE

این متد به کلاینت اجازه می‌ده قبل از انجام عملیات، درباره تعاملات ممکن با یک منبع اطلاعات بیشتری کسب کنه.

@ninja_learn_ir