نکات طراحی pop-up های delete :
۱- از باتن های مشخص برای حذف یا تایید استفاده کنیم تا کاربر راحت تر بفهمه چیکار میکنه.

۲- از رنگ‌هایی مانند قرمز برای باتن حذف استفاده کنیم تا توجه کاربر جلب بشه.

۳-باتن ها رو در مکان‌های قابل دسترس قرار بدیم تا کاربر راحت بتونه تصمیم بگیره.
(در تصویر به نمونه‌های ایده‌آل و اشتباه اشاره شده)
#UI
@GoldenCodeir
(به منبع و مثالش توجه کنین 👇🏾)
https://x.com/uxpeak_/status/1718579351644410367?s=19

-اصل Vertical Openness Between Concepts در کلین کد

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

import CleverDevs from telegram
function helloWorld(){
    console.log("hello world");
}
function sendStarRaction(){
    console.log('send star reaction on CleverDevs Posts');
}

تو کد بالا بین بخش های مختلف کد فاصله ای نذاشتیم حالا اگه کدمون بیشتر و پیچیده تر بشه خوندنش خیلی سخت تر میشه حالا اگه بیایم و مثل کد پایین یه خط خالی بین هر بخشی از کد بزاریم خوندنش به مراتب راحت تر میشه

import CleverDevs from telegram

function helloWorld(){
    console.log("hello world");
}

function sendStarRaction(){
    console.log('send star reaction on CleverDevs Posts');
}

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

#CleanCode
@CleverDevs - @CleverDevsGp

لاراول با Artisan به ما امکان این رو داده تا وضعیت دیتابیس رو در ترمینال به خوبی بتونیم بررسی کنیم.

حالا یه سری کامند رو مرور کنیم:

Php artisan db:table 

(میاد ی آمار جامع و عالی از دیتابیس میده)

Php artisan db:monitor

(بررسی تعداد کانکشن های دیتابیس(خیلی خفنه و آپشنای ديگه هم داره)

Php artisan db:show

(یه نمای کلی از db و تعداد کانکشن های فعال و نوع دیتابیس...)
@GoldenCodeir
( منبع و مثالش)
https://x.com/OussamaMater/status/1833235842321756608?t=zoRINh3pYLRRThSPXX5cXw&s=19

علاوه بر منبع، اینم یه مقاله جامع:👇🏾
https://magecomp.com/blog/laravel-9-new-database-commands/

-اصل Do One Thing در کلین کد

این اصل میگه هر تابعی باید فقط یه کار انجام بده و اگه نیاز به دوتا کار شد باید دوتا فانکشن بکنیش

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL THEY SHOULD DO IT ONLY.

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


#CleanCode
@CleverDevs - @CleverDevsGp

در لاراول orderByRaw بهتون این امکان رو میده که نتایج رو بتونید بر اساس یه سری محاسبات خاصی مرتب کنید.

مثلا ؟
میتونیم نتایج رو بر اساس اختلاف بین دو ستون ( قیمت و تخفیف) مرتب کنیم!
این آپشن یه سری جاها کدارو واقعا بهینه میکنه.
#laravel
@GoldenCodeir
(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/laravelbackpack/status/1836004683594469864?t=IGgicccC4LllTLBm0hRviw&s=19

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

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

<?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

🔰تعریف مهندسی معکوس

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

🔵کاربرد اصلی مهندسی معکوس در یکی از دو مورد زیر است:

🔴وقتی جواب یک مسئله را می‌دانیم. اما نمی‌دانیم این جواب پاسخ به چه سوالی است.

🔴وقتی سوال و پاسخ را می‌دانیم. اما نمی‌دانیم مسیر و فرایند رسیدن به این پاسخ چه بوده است.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

متود times در لاراول برای ایجاد یک Collection و تکرار یک تابع به تعداد مشخصی استفاده میشه.
ینی چی؟

این متد بهتون این امکانو میده تا یک تابع رو به تعداد مشخصی اجرا کنید و نتایجش رو در یک Collection جمع‌آوری کنید.

خروجیه پایین چیزی شبیه به [1, 2, 3] میشه

times(3, function($number) {
return $number; 
})

#laravel
@GoldenCodeir
(در منبع مثال دیگه هم گفته شده👇🏾)
https://x.com/laravelbackpack/status/1838541404689318158?s=19

Authentication & Authorization =

پروتکل HTTP یک پروتکل stateless هست. اگه شخصی دوبار پشت سرهم به وب سرور درخواست بفرسته، HTTP متوجه نمیشه که این کاربر همون کاربر قبلیه که درخواست فرستاده بود یعنی وضعیت کاربر رو نگه نمیداره. واسه حل این مشکل پروتکل باید وضعیت کاربر رو جایی ذخیره کنیم(باید یک شناسه از کاربر رو نگه داریم). یکی از اولین ویژگی ها و مکانیزمی که واسه این کار به وجود اومد session بود. برنامه نویس بعد از login برای کاربر یک session سمت سرور ست میکرد که بتونه کاربر رو بشناسه و Authentication و Authorization رو میتونست هندل کنه. session سمت سرور معمولا داخل یک فایل ذخیره میشه و بعد بسته شدن مرورگر کاربر از بین میره.

❓حالا Authentication و Authorization چین؟ Authentication مشخص میکنه من کیم و ما تو این مرحله باید ثابت کنیم که چه کسی هستیم. Authorization بعد از مرحله Authentication میاد و مشخص میکنه کاربر به چه چیز هایی دسترسی داره(سطح دسترسی های مختلفی تو یک web application وجود داره، هر کاربر فقط باید بتونه اطلاعات خودش رو ویرایش کنه و ببینه و همچنین کاربر معمولی نباید به فایل های ادمین سایت دسترسی داشته باشه)
❓کوکی یا cookie چیه؟
بخاطر مشکلی که session داشت و بعد بستن مرورگر از بین میرفت، cookie رو ساختن. Cookie تو مرورگر کاربر ذخیره میشه و طول عمرش دست برنامه نویسه و به خاطر همین کاربر میتونه مدت زمان بیشتری لاگین باشه. Session ID که سمت سرور بود رو به صورت encrypt داخل cookie قرار میدن که کاربر نتونه دست کاریش کنه. به ازای هر درخواستی که کاربر میفرسته سمت سرور، مرورگر به صورت خودکار cookie رو هم واسه اون دامنه میفرسته.
❓ انواع روش های Authentication:
1⃣ Basic Authentication
2⃣ Dijest Authentication
3⃣ Form base Authentication
4⃣ Certificate Authentication
5⃣ Integrated Windows Authentication
6⃣ Token base Authentication(JWT in header)
7⃣ OAuth
8⃣ SSO

هر کدوم از روش های Authentication محدودیت ها و آسیب پذیری های مربوط به خودش رو داره. برای مثال :
- تو token base Authentication آسیب پذیری هایی مثل csrf و cors misconfiguration و cache deception به وجود نمیاد.
- وقتی اطلاعات تو cookie یا localstorage ذخیره میشه با xss میشه اطلاعات رو خوند ولی اگه تو header باشه با xss نمیتونیم بخونیمش.
- روش Basic Authentication آسیب پذیره به MITM.
- تو OAuth یک آسیب پذیری نسبتا بی ارزش مثل open redirect میتونه منجر به Account Takeover بشه.
- روش Integrated Windows Authentication مختص شبکه های مایکروسافتیه.
- روش های certificate Authentication و Integrated Windows Authentication رو تو شبکه های داخلی معمولا استفاده میکنن.
- اگه private key تو certificate Authentication لو بره منجر به mitm میشه.
- وقتی از session استفاده بشه کاربر نمیتونه دست کاریش کنه بر خلاف سایر موارد که سمت کاربر ذخیره میشه(برنامه نویس باید با encryption جلوی تغییر cookie/jwt و.... رو بگیره).
- تو form base Authentication اگه مواردی مثل Error handling رو انجام ندیم ممکنه آسیب پذیری username enumeration به وجود بیاد.
#Authentication