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

sudo dd if=/dev/sd1    of=/mbr_backup.img    bs=512 count=1

برای بازیابی از grub

sudo dd if=/mbr_backup.img of=/dev/sda bs=512 count=1

نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir

در نسخه 6.12 لینوکس، امکان نمایش کد QR در هنگام وقوع کرنل پنیک به صورت اختیاری اضافه شده است.
این ویژگی از طریق زیرساخت مدیریت خطای DRM Panic اضافه شده و در اواسط سپتامبر به هسته لینوکس اضافه خواهد شد.
این قابلیت به کاربران اجازه می‌دهد تا در صورت وقوع خطای “صفحه مرگ” در DRM، یک کد QR نمایش داده شود. این کد QR می‌تواند اطلاعات زیادی را که ممکن است در خروجی متنی ساده به سختی قابل دریافت باشد، به صورت کاربرپسندتری نمایش دهد.
این ویژگی با زبان برنامه‌نویسی Rust نوشته شده و برای استفاده از آن باید ساخت هسته با پشتیبانی از Rust فعال باشد. همچنین، این قابلیت توسط سوئیچ ساخت Kconfig به نام DRM_PANIC_SCREEN_QR_CODE کنترل می‌شود و امکان تنظیم URL پایه کد QR و نسخه کد QR برای مقدار داده‌های اشکال‌زدایی که می‌توان ذخیره کرد، وجود دارد.
——————-
نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir

📕 کتاب REST API Design Rulebook

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

📍پارت: دوم

#کتاب

💎 استاتوس کدهای ریسپانس (Response Status Codes) 💎

‏REST API‌ ها از قسمت Status-Line توی ریسپانس HTTP استفاده می‌کنن تا به کلاینت‌ها نتیجه درخواستشون رو اعلام کنن. استاندارد RFC 2616، ساختار Status-Line رو به این شکل تعریف کرده:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

‏HTTP حدود ۴۰ تا کد وضعیت استاندارد داره که برای بیان نتیجه درخواست‌های کلاینت استفاده میشه. این کدها به ۵ دسته اصلی تقسیم می‌شن که توی جدول زیر توضیح دادم:

⭕️ دسته‌بندی کدهای وضعیت:

1. 1xx: اطلاعاتی – اطلاعاتی در مورد سطح پروتکل انتقال میده.
2. 2xx: موفقیت‌آمیز – درخواست کلاینت با موفقیت قبول شده.
3. 3xx: تغییر مسیر – کلاینت باید یه کار اضافی انجام بده تا درخواست کامل بشه.
4. 4xx: خطای کلاینت – خطاهای این دسته مربوط به اشتباهات کلاینت هست.
5. 5xx: خطای سرور – سرور مسئولیت این خطاها رو قبول می‌کنه.

⭕️ قوانین استفاده از کدهای وضعیت:

⭕️ کد 200 (OK): برای موفقیت کلی
این کد معمولاً همون چیزیه که کلاینت انتظار داره ببینه. یعنی درخواست با موفقیت انجام شده و نیازی به استفاده از کد خاص دیگه‌ای از سری ۲xx نیست. برعکس کد 204، وقتی 200 برگرده، باید یه بدنه پاسخ (response body) هم داشته باشه.

⭕️ کد 200 (OK) نباید برای اعلام خطا استفاده بشه
همیشه باید از کدهای وضعیت HTTP درست استفاده کنید. به‌خصوص، نباید برای سازگار شدن با کلاینت‌های ساده‌تر از قواعد استاندارد API صرف‌نظر کرد.

⭕️ کد 201 (Created): برای ایجاد موفقیت‌آمیز منابع جدید
هر وقت که یه API یه منبع جدید برای درخواست کلاینت ایجاد می‌کنه (مثلاً توی یه کالکشن یا فروشگاه)، باید از کد 201 استفاده کنه. حتی اگر منبع جدید از طریق یه عمل کنترلر ایجاد بشه، باز هم 201 کد درستی برای پاسخ هست.

⭕️ کد 202 ("Accepted") باید برای شروع موفقیت‌آمیز یک عملیات غیرهمزمان استفاده بشه
کد 202 یعنی درخواست کلاینت قراره به صورت غیرهمزمان (آسنکرون) پردازش بشه. این کد به کلاینت میگه که درخواستش معتبر به نظر می‌رسه، اما ممکنه بعداً موقع پردازش به مشکل بخوره. این کد معمولاً برای عملیات‌هایی که زمان زیادی می‌برن استفاده می‌شه.
کنترلرها می‌تونن 202 رو برگردونن، اما منابع دیگه نباید این کار رو بکنن.

⭕️ کد 204 ("No Content") باید زمانی استفاده بشه که بدنه پاسخ (response body) خالیه
کد 204 معمولاً وقتی استفاده میشه که API به درخواست‌های PUT، POST یا DELETE پاسخ میده ولی قصد نداره که توی پاسخ، پیام یا داده‌ای برگردونه.
حتی در پاسخ به درخواست GET هم میشه از 204 استفاده کرد تا بگه منبع درخواست‌شده وجود داره، ولی چیزی برای نمایش نداره.

⭕️ کد 301 ("Moved Permanently") برای تغییر مکان دائمی منابع استفاده بشه
- کد 301 وقتی استفاده میشه که مدل منابع توی API تغییر بزرگی کرده و یه آدرس جدید برای منبع به کلاینت اختصاص داده شده. توی این حالت، آدرس جدید باید توی هدر "Location" به کلاینت اعلام بشه.

⭕️ از کد 302 ("Found") نباید استفاده بشه
کد 302 همیشه اشتباه فهمیده شده و برنامه‌نویسا توی پیاده‌سازیش اشتباه کردن. مشکل اصلی اینجاست که کلاینت‌ها به‌طور خودکار برای آدرس جدید یه درخواست GET می‌فرستن، حتی اگر روش اصلی درخواست چیز دیگه‌ای بوده.
برای رفع این مشکل، توی HTTP 1.1 کدهای 303 ("See Other") و 307 ("Temporary Redirect") معرفی شدن که به جای 302 باید استفاده بشن.

⭕️ کد 303 ("See Other") باید برای ارجاع کلاینت به یه URI دیگه استفاده بشه
وقتی یه کنترلر کارش رو تموم کرده، به جای فرستادن پاسخ توی بدنه‌ای که شاید کلاینت نمی‌خواد، می‌تونه با کد 303 یه URI جدید به کلاینت بده. این URI می‌تونه به یه پیام موقت یا یه منبع دائمی‌تر اشاره کنه.
این کد به API اجازه میده که به جای تحمیل دانلود اطلاعات به کلاینت، یه مرجع به منبع بده و کلاینت اگه بخواد می‌تونه با GET به URI جدید دسترسی پیدا کنه.

⭕️ کد 304 ("Not Modified") باید برای صرفه‌جویی در پهنای باند استفاده بشه
این کد شبیه کد 204 ("No Content") هست چون هیچ چیزی توی بدنه پاسخ نیست، اما تفاوت اصلی اینه که 204 وقتی استفاده می‌شه که هیچ داده‌ای برای فرستادن وجود نداره، ولی 304 وقتی استفاده میشه که منبع اطلاعات داره اما کلاینت قبلاً آخرین نسخه‌اش رو گرفته.
این کد بیشتر توی درخواست‌های HTTP شرطی (conditional requests) کاربرد داره.

@ninja_learn_ir

⭕️ کد 307 ("Temporary Redirect") برای تغییر موقتی مکان درخواست کلاینت استفاده بشه
‏- HTTP/1.1 کد 307 رو معرفی کرد تا کاربرد درست کد 302 ("Found") رو مشخص کنه. وقتی کد 307 برگرده، یعنی API قراره درخواست رو پردازش نکنه و کلاینت باید درخواستش رو به یه URI دیگه که توی هدر "Location" داده شده، بفرسته.
- این کد معمولاً برای اختصاص یه آدرس موقت به درخواست منبع استفاده میشه. مثلاً میشه درخواست رو به یه سرور دیگه انتقال داد.

⭕️ کد 400 ("Bad Request") برای اعلام شکست عمومی درخواست کلاینت استفاده بشه
کد 400 یه خطای کلی سمت کلاینت هست و زمانی استفاده میشه که هیچ کد دیگه‌ای از سری 4xx مناسب نباشه.

⭕️ کد 401 ("Unauthorized") باید زمانی استفاده بشه که مشکلی با اعتبارسنجی کلاینت وجود داره
این کد یعنی کلاینت سعی کرده به یه منبع محافظت‌شده دسترسی پیدا کنه ولی اعتبارنامه مناسب ارائه نداده. ممکنه اعتبارنامه‌ها اشتباه باشن یا اصلاً وجود نداشته باشن.

⭕️ کد 403 ("Forbidden") باید زمانی استفاده بشه که دسترسی به منبع غیرممکنه، فارغ از وضعیت اعتبارسنجی
- این کد یعنی درخواست کلاینت درسته ولی API اجازه انجامش رو نمیده. این موضوع ربطی به مشکل اعتبارنامه‌ها نداره (اون مورد 401 هست).
‏- APIهای REST از 403 برای مدیریت سطح دسترسی‌ها استفاده می‌کنن. مثلاً ممکنه یه کلاینت اجازه دسترسی به بعضی منابع رو داشته باشه ولی نه به همه. اگه کلاینت سعی کنه خارج از محدوده مجازش به منبعی دسترسی پیدا کنه، API باید با 403 پاسخ بده.

⭕️ کد 404 ("Not Found") باید زمانی استفاده بشه که URI کلاینت به منبعی مرتبط نمیشه
کد 404 یعنی API نمی‌تونه URI درخواست‌شده رو به منبعی متصل کنه.

⭕️ کد 405 ("Method Not Allowed") باید زمانی استفاده بشه که روش HTTP پشتیبانی نمیشه
‏- API با کد 405 پاسخ میده تا به کلاینت بگه که از روشی استفاده کرده که برای اون منبع مجاز نیست. مثلاً یه منبع فقط قابل خواندن ممکنه فقط GET و HEAD رو پشتیبانی کنه، ولی یه کنترلر ممکنه GET و POST رو مجاز بدونه اما PUT یا DELETE رو نه.
- پاسخ 405 باید شامل هدر "Allow" باشه که روش‌های مجاز برای اون منبع رو لیست کنه. مثلاً:

Allow: GET, POST

⭕️ کد 406 ("Not Acceptable") باید زمانی استفاده بشه که نوع داده‌ای که کلاینت درخواست داده قابل سرویس‌دهی نیست
- کد 406 یعنی API نمی‌تونه نوع مدیا (media type) درخواستی کلاینت رو ایجاد کنه. مثلاً اگه کلاینت درخواست داده به فرمت application/xml بده و API فقط با application/json کار کنه، کد 406 برمی‌گرده.

⭕️ کد 409 ("Conflict") باید زمانی استفاده بشه که درخواست کلاینت باعث نقض وضعیت منبع بشه
- کد 409 به کلاینت میگه که درخواستش باعث شده منبع API توی حالت ناسازگار یا غیرممکن قرار بگیره. مثلاً اگه کلاینت بخواد یه منبع پرشده رو حذف کنه و اون منبع هنوز داده داره، ممکنه API با 409 پاسخ بده.

⭕️ کد 412 ("Precondition Failed") باید برای پشتیبانی از عملیات‌های شرطی استفاده بشه
- این کد یعنی کلاینت یه سری شرایط رو توی هدر درخواستش مشخص کرده و به API گفته که فقط اگه اون شرایط برقرار باشه درخواستش رو انجام بده. اگه شرایط محقق نشه، API با کد 412 پاسخ میده.

⭕️ کد 415 ("Unsupported Media Type") باید زمانی استفاده بشه که نوع مدیا در payload درخواست قابل پردازش نباشه
- این کد یعنی API نمی‌تونه نوع مدیایی که کلاینت فرستاده رو پردازش کنه. مثلاً اگه کلاینت داده‌ها رو به فرمت application/xml بفرسته ولی API فقط با application/json کار کنه، کد 415 برگردونده می‌شه.

⭕️ کد 500 ("Internal Server Error") باید برای اعلام مشکل داخلی API استفاده بشه
- کد 500 یه خطای عمومی API هست که بیشتر فریم‌ورک‌های وب خودکار این کد رو برمی‌گردونن وقتی که درخواست کلاینت باعث ایجاد یه استثنا توی کد بشه.
- این خطا تقصیر کلاینت نیست، پس کلاینت می‌تونه همون درخواست رو دوباره امتحان کنه و امید داشته باشه که نتیجه متفاوتی بگیره.

@ninja_learn_ir

یه بازی خیلی ساده تحت وب ساختم که بهت اسکرین شات بازی‌های مختلف رو نمایش می‌ده و باید عنوان بازی رو حدس بزنی.
هنوز کامل نیست. یعنی فقط ۲۰ تا بازی رو پوشش می‌ده و دسته بندی ها کارکرد ندارن.
اگه دوست داشتی تست بزن.
دم شما گرم.
bardialatifi.github.io/Guessing-Game/‎

@DevTwitter | <Bear The Yara/>

اون روزهایی که تازه داشتم React یاد می‌گرفتم خیلی سر درگم بودم و دنبال منابع خوب می‌گشتم!
به مرور از جاهای مختلف به یک سری newsletterهای مشتی دسترسی پیدا کردم و الان هر هفته کلی مقاله جذاب و جدید به دستم می‌رسه که باعث پیشرفت سریع‌ترم میشن.
حالا که دارم Vue.js رو یاد می‌گیرم، می‌خوام این گنجینه رو به شما انتقال بدم. یه عالمه نیوزلتر خوب که مطمئنم بهتون کمک می‌کنه. میتونید برید موضوع هر newsletter رو ببینید و هرکدوم رو که دوست داشتید subscribe کنین.
بعضی از newsletterهای جذابی که دارم:

React Digest:‌ یه گنجینه‌ی واقعی از مقالات
https://reactdigest.net/

Kent C. Dodds: این آقا یه نابغه است و بلاگش پر از نکات کاربردیه.
https://lnkd.in/dVR4sTH9

This Week in React: هر هفته خلاصه‌ای از مهم‌ترین اخبار React رو براتون می‌فرسته.
https://lnkd.in/dny5aBdU

Large Apps: برای ساختن اپلیکیشن‌های بزرگ، این newsletter عالیه.
https://lnkd.in/dArS4VK3

The T-Shaped Dev: اگه می‌خواید توسعه‌دهنده‌ی همه کاره بشید، این newsletter رو از دست ندید.
https://lnkd.in/dzipuC9r

Daily.dev:‌ یه پلتفرم جامع برای developerهاست که هر روز مقاله‌های جدید داره.
https://app.daily.dev/

Craft Better Software: برای اونایی که به تست نویسی علاقه دارن، این newsletter فوق‌العادست.
https://lnkd.in/dPseSv4V

Cassidoo:‌ یه newsletter فان و خنده‌دار با کلی نکته‌ی کاربردی.
https://lnkd.in/dBGGgfFW

System Design: اگه به معماری سیستم علاقه‌مندید، این newsletter براتون جذابه.
https://lnkd.in/d6gZXeqX

The Hustling Engineer: برای مهندس‌هایی که می‌خوان حرفه خودشون رو ارتقا بدن.
https://lnkd.in/dPWEsFgS


https://www.linkedin.com/posts/reihaneh-sadat-shokouhi-78b22a233_%D8%B3%D9%84%D8%A7%D9%85-%D8%A8%DA%86%D9%87%D9%87%D8%A7-%D8%A7%D9%85%D8%B1%D9%88%D8%B2-%D8%A8%D8%A7-%D8%AF%D8%B3%D8%AA-%D9%BE%D8%B1-%D8%A7%D9%88%D9%85%D8%AF%D9%85-%D8%A7%D9%88%D9%86-%D8%B1%D9%88%D8%B2%D9%87%D8%A7%DB%8C%DB%8C-activity-7241657143618088964-57Wm?utm_source=share&utm_medium=member_desktop


💻@DevAcaademy
💬@DevAcademyGroup

آشنایی با Error Handling در Go : بررسی عمیق

🔺 مدیریت خطا (Error Handling) یک جنبه حیاتی در هر زبان برنامه نویسی است و Go نیز از این قاعده مستثنی نیست. در این مقاله از سری مقالات گولنگ در آنوفل، به بررسی اشتباهات معمولی که حتی توسعه دهندگان باتجربه مرتکب می شوند اختصاص یافته است، ما بر Error Hand...

🌐 : آشنایی با Error Handling در Go : بررسی عمیق

یه آسیب پذیری ظاهرا بی ارزش =

کد زیر رو در نظر بگیرین:

<?php
session_start();
if($_SESSION['is_admin'] != true)
{
    header("Location: /home.php");
}
// Application code is here
?>

سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:

curl https://target.com/admin_panel.php

نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :

<?php
if($_SESSION['is_admin'] != true)
{
    hedaer("Location : /home.php");
}

echo "username : adm2ish";
echo "password : pa19ehw";
?>

2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:

<?php
session_start();
if($_SESSION['is_admin'] != true)
{
    header("Location: /home.php");
}
if (isset($_GET['cmd']) && !empty($_GET['cmd'])) {
    $admin_input = $_GET['cmd'];
    echo system("ping $admin_input");
} else {
    echo "No command provided.";
}
?>

آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :

curl "https://target.com/admin_panel.php?cmd=1.1.1.1|whoami"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1||whoami||"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1;whoami"

نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.

⁉️روش جلوگیری چیه؟

بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:

<?php
exit()
die()
?>

اسم آسیب پذیری :
Execution After Redirect = EAR

#EAR
#parameter_fuzz

🔶 کامپایل و اجرای زبان C از جاوا اسکریپت در نسخه ۱.۲۸ ران تایم Bun.js

#جاوااسکریپت

@TheRaymondDev

سلام، پیشنهاد می کنم حتما پادکست «تفکر شفاف» بی پلاس رو گوش بدید. هم به مهارت های نرم شما کمک میکنه که ارتباط موثرتری با همکاراتون داشته باشید، هم بهتون کمک میکنه تحلیلگر و معمار و مهندس بهتری باشید، چون مهندسی همه ش فکر کردن و تصمیم گرفتنه، پس بهتر بستر مناسبی برای تفکر خودتون آماده کنید.


https://bpluspodcast.com/podcast/seventh-season/%D8%AA%D9%81%DA%A9%D8%B1-%D8%B4%D9%81%D8%A7%D9%81/


@gocasts

t.iss.one/joinchat/P2Pv304Nh19E_uiD

گروه کاربران گنو/لینوکس گیلان (GulLUG):

#موقت

Persepolis Download Manager 5.0.0 is out! 🎉

Release notes

#news #tools

Deno 2 is set to be released tomorrow! 🎉

Milestone

#news #deno

نگارش جدید پارچ منتشر شد.

مشکل کالامارس در این نگارش رفع شده.

دریافت نگارش پلاسما

دریافت نگارش گنوم (با گنوم ۴۷)

@ParchLinux

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

@TheRaymondDev

🔵 عنوان مقاله
How I Made My GitHub Profile README Dynamic

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

🟣لینک مقاله:
https://tduyng.github.io/blog/dynamic-github-profile-readme/

➖➖➖➖➖➖➖➖
👑 @gopher_academy