PHP :: یوشا

۳۱ مطلب با موضوع «نرم افزار :: برنامه نویسی :: PHP» ثبت شده است

۲۱

فروردين

PHP Security Linter

اگر شما هم از توسعه دهندگان PHP هستید یا با پروژه های مبتنی بر این زبان سروکار دارید، حتماً میدونید که امنیت کدها چقدر اهمیت داره... باگهای امنیتی میتونن به راحتی به یک کابوس برای کسب و کار تبدیل بشن، مخصوصا از نوع باج افزار/Ransomware اش!

اما خب ابزارهایی وجود دارن که به ما کمک میکنن قبل از رسیدن به مرحله production، مشکلات امنیتی رو شناسایی کنیم... یک خانواده از این ابزارها Security linter ها هستن که با اسکن static کدها، حفره ها و اسیب پذیریهای امنیتی رو برنامه نویس ایجاد کرده رو شنایی و گزارش می کنند.

یکی از این ابزارها، PHP Security Linter هستش که دست ساز خودم هست:

PHP Security Linter

این ابزار یک Static analysis tool (تحلیل ایستای کد) برای زبان PHP هست که با اسکن کدها، آسیب پذیری های امنیتی رو بر اساس استانداردهای CIS و OWASP شناسایی میکنه. یعنی بکمک این ابزار و بدون نیاز به اجرای کد، میتونید مشکلاتی مثل SQL Injection، XSS، قرار دادن اطلاعات حساس در کد و غیره... رو پیدا کنید.

آدرس مخزن: https://github.com/Yousha/php-security-linter

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

پشتیبانی از بیش از ۲۰۰ قانون امنیتی (مطابق با CIS و OWASP)
سریع و سبک: بدون اجرای کد، آسیب پذیری ها رو تشخیص میده.
پشتیبانی از PHP 7.4 و 8.3
خروجی های متنوع: هم بصورت متن در کنسول و هم JSON.
قابلیت شخصی سازی: میتونید قوانین خودتون رو اضافه یا برخی رو غیرفعال کنید.
مناسب برای DevSecOps: به راحتی با DevSecOps ادغام میشه.
با حداقل dependency و سبک!

نصب و استفاده

نصبش بسیار سادست، فقط کافیه با Composer اونرو به پروژه اضافه کنید:

composer require --dev yousha/php-security-linter

بعد برای اسکن یک پوشه:

php vendor/bin/php-security-linter --path ./src

اگرم میخوایید پوشه هایی مثل vendor یا tests رو اسکن نکنید:

php vendor/bin/php-security-linter --path ./app --exclude vendor,tests

مثال خروجی ابزار

وقتی اسکن انجام میشه، نتیجه رو به صورت خوانا مشاهده میکنید:

Scan Results
========================================

File: /src/auth.php
  ✗ [CRITICAL] OWASP: SQL Injection vulnerability detected (Line 42)
  ✗ [HIGH] CIS: Hardcoded database credentials (Line 15)

File: /src/utils.php
  ✗ [MEDIUM] OWASP: XSS vulnerability possible (Line 88)

Summary: Scanned 24 files, found 3 potential issues.

۰ نظر

یوشا آل ایوب

۰۵

اسفند

اکستنشن OpCache

OpCache اکستنشنی در PHP هست که برای بهبود پرفورمنس و سرعت پردازش فایلهای PHP ایجاد شده.

این اکستنشن با ذخیره کردن OpCode تولید شده فایلهای PHP در قسمت shared memory حافظه، از بارگذاری و تفسیر مجدد اسکریپت ها در هر درخواست جلوگیری میکنه. و همیشه همون OpCode ذخیره شده رو مصرف میکنه. در نتیجه اسکریپت با سرعت بیشتری پردازش میشه.

در حال حاضر سریعترین، کاملترین و قوی ترین سیستم cache برای PHP اکستنشن opcache هستش که هم optimization و هم caching رو فراهم میکنه.

فهرست مندرجات

الزامات و نیازمندیها
فعالسازی
مقایسه OPcache با سایر ابزارهای مشابه
نکات
تنظیم محیط گرافیکی
ابزارهای کمکی در فریمورک ها
قابلیت Preloading در PHP 8+
رفع مشکلات

ادامه مطلب...

۰ نظر

یوشا آل ایوب

۱۸

آذر

حذف اصولی API از پروژه Laravel

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

- نیاز نداشتن به API و تمرکز روی توسعه‌ وب‌ سایت

- کاهش پیچیدگی و تمیزکاری

- کاهش دردسرهای امنیتی

- بهبود مصرف منابع سرور

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

برای حذف اصولی API و موارد مرتبط از یک پروژه Laravel، باید مراحل زیر رو انجام داد:

1- حذف فایل API از Route ها

مسیرهای API معمولاً در فایل routes/api.php تعریف میشن. این فایل رو باید پاک کنید.

routes/api.php

2- حذف Loader فایل api.php در RouteServiceProvider

مسیر:

app/Providers/RouteServiceProvider.php

کدها:

public function boot()
{
    $this->routes(function () {
        // این قسمت رو حذف یا کامنت کنید
        // Route::middleware('api')
        //     ->prefix('api')
        //     ->group(base_path('routes/api.php'));

        Route::middleware('web')
            ->group(base_path('routes/web.php'));
    });
}

3- حذف middleware های مربوط به API در Kernel.php

مسیر:

app/Http/Kernel.php

کدها:

protected $middlewareGroups = [
    'web' => [
        // Middlewareهای وب
    ],

    // این قسمت رو حذف یا کامنت کنید
    // 'api' => [
    //     \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
    //     'throttle:api',
    //     \Illuminate\Routing\Middleware\SubstituteBindings::class,
    // ],
];

4- درصورت وجود: پاک کردن کنترلرها و منابع API

مسیر:

app/Http/Controllers/API
و
app/Http/Resources

5- پاک کردن cache ها

دستور زیر رو بزنید تا cache ها پاکسازی بشن:

php artisan optimize:clear

6- حذف دستورات پکیج Sanctum

مسیر:

app\Models\User.php

کدها:

   //use Laravel\Sanctum\HasApiTokens;

   final class User extends BaseUser
   {
      //use HasApiTokens;

اگر از این Trait در مسیرهای دیگه هم استفاده شده، حذفش کنید.

7- کانفیگ Path در CORS

مسیر:

config\cors.php

کدها:

'paths' => ['api/*', 'sanctum/csrf-cookie'], // -> 'paths' => [],

8- حذف فایل کانفیگ پکیج Sanctum و Passport

مسیر:

config\sanctum.php
و
config\passport.php

9- حذف کدهای Sanctum و Passport از داخل فایلهای tests

مسیر:

tests/unit/
و
tests/feature/

10- حذف کدها و جدول personal_access_tokens

جدول personal_access_tokens رو از دیتابیس حذف کنید. همچنین:

مسیر:

routes\console.php

کدها:

//DB::table('personal_access_tokens')->truncate();

11- نهایتاً حذف پکیج laravel/sanctum و laravel/passport

دستور:

composer remove laravel/sanctum
composer remove laravel/passport

و مجدد دستور زیر رو بزنید تا cache ها پاکسازی بشن:

php artisan optimize:clear

۰ نظر

یوشا آل ایوب

۱۷

خرداد

بررسی عمیق PHP JIT

یکی از مهمترین ویژگی‌ های جدید در PHP 8.0، کامپایلر JIT است. JIT می‌تواند با کامپایل کردن و ذخیره‌ کردن کامل یا بخش‌ هایی از اسکریپت PHP، به کد ماشین CPU، عملکرد را بسیار بهبود بخشد و به طور مستقیم کد ماشین را اجرا کند، بطوریکه Zend VM و سربار ناشی از عملیات و فرایندهای آنرا دور می‌ زند و نادیده می‌ گیرد.

JIT ترکیبی از مفسران traditional و کامپایلرهای AoT است. این مدل ترکیبی/Hybrid، مزایا و معایب هر دو مفسر و کامپایلر را به ارمغان می‌آورد.
پیاده‌ سازی PHP JIT تنها با تلاش‌ های شگفت‌ انگیز Dmitry Stogov در چند سال اخیر، ارزش بحث، اجرا و آزمایشات را پیدا کرده است.

این مقاله در مورد benchmark ها، نحوه‌ی کار JIT، امکانات و گزینه‌ های پیکربندی در php.ini می باشد.

دانلود مقاله PDF

۰ نظر

یوشا آل ایوب

۰۱

بهمن

Quick guide to Laravel package development

Contents

Introduction
Types of packages
Characteristics of a package
The Laravel package!
Components of a Laravel package
Example of a Laravel package
Creating your Laravel package
- 1- Package structure
- 2- Required equipments
- 3- Create package structure
- 4- Update package manifest
- 5- Create route
- 6- Create configuration file
- 7- Create command for package
- 8- Create controller
- 9- Create middleware
- 10- Create [database] migration
- 11- Create view
- 12- Create [view] assets
- 13- Create service provider
- 14- Create a manual/help file
- 15- Build our package
- 16- Test/Use our package
Helpful information

Introduction

In context of software development - particularly with PHP - a package is a modular, reusable piece of functionality that can be integrated into an application. Packages are designed to extend or enhance capabilities of a application by adding specific features or tools without reinventing wheel!

Now why packages? why not develop built-in codes and features?

Because:
Save time & effort - Instead of coding complex functionality (like payments, authn, or APIs), you use a well-tested package, by too many users (well-cooked)
Follow best practices - Good packages are built by experts(mostly), ensuring security, performance, and maintainability.
Easy updates - When a package improves, you get upgrades without rewriting your code. (composer update vendor/package)
Community-Powered - Many packages are open-source, meaning developers worldwide contribute to imptove them.

So let's avoid reinventing wheel!

ادامه مطلب...

۰ نظر

یوشا آل ایوب

۱۴

فروردين

مروری بر CI/CD

دانلود مقاله

https://bayanbox.ir/view/327904009501239085/Overview-of-CI-CD.pdf

۰ نظر

یوشا آل ایوب

۱۳

دی

#4 - نکات و اصول مهم در برنامه نویسی PHP

1- برای بدست اوردن میزان حافظه مصرف شده باید از دستور memory_get_usage(FALSE) استفاده کنید و برای میزان حافظه رزرو شده باید از دستور memory_get_usage(TRUE) استفاده کنید.

اما این نکته در مستندات سایت PHP.net برعکس توضیح داده شده:

int memory_get_usage ([ bool $real_usage = FALSE ] )

Returns the amount of memory, in bytes, that's currently being allocated to your PHP script.

2- زمانی از دستور strcmp استفاده کنید که قراره مقدار رشته ها شمارش(کمتر/بیشتر) بشن، درغیراینصورت استفاده از اپراتور === برای برابر بودن/نبودن رشته ها بهترین گزینست.

3- آیا میدونید به 4 روش مختلف میتونید تصاویر رو در مرورگر نمایش/output بدید؟

header('Content-Type: image/jpg');
$image = imagecreatefromjpeg('yourfilename.jpg');
header('Content-Length: ' . filesize('yourfilename.jpg'));
imagejpeg($image);
imagedestroy($image);

header('Content-Type: image/jpg');
header('Content-Length: ' . filesize('yourfilename.jpg'));
readfile('yourfilename.jpg');

header('Content-Type: image/jpg');
header('Content-Length: ' . filesize('yourfilename.jpg'));
echo file_get_contents('yourfilename.jpg');

header('Content-Type: image/jpg');
header('Content-Length: ' . filesize('yourfilename.jpg'));
header('X-Sendfile: ' . 'yourfilename.jpg'); 
exit;

4- اگر از PHP CLI در محیط text UI سیستم عامل استفاده می کنید و مشکلات output و نمایشی دارید، بهتره از دستور passthru استفاده کنید.

5- نکته جزیی: فراموش نکنید که تابع json_decode فقط اعضای public شی موردنظر رو تبدیل میکنه، و نه private / protected.

ادامه مطلب...

۰ نظر

یوشا آل ایوب

۱۰

مهر

چند نکته در طراحی اصولی test case در Unit Test

هر قطعه کد تست باید کوتاه، قابل فهم و خوانا باشه.
کدهای تست باید قطعه قطعه و به واحدهای مستقل از هم تقسیم بشن.
کدهای تست باید مستقل از محیط اجرایی باشن و وابستگی به platform نداشته باشن.
بهتره شیوه اجرای کدهای تست بسادگی و توسط یک دستور انجام بشه.
امکان گزارش گیری Test code coverage باید فراهم باشه.
اجرای تست case ها از پایین ترین سطح(Unit) به بالاترین سطح(E2E) باید باشه.
تست case هارو توسط الگوی AAA بنویسید.
در کدهای تست باید از نقل/انتقال اطلاعات حجیم خودداری کرد تا پروسه تست بسرعت انجام بشه.
کدهای تست باید بروز باشن و با هر تغییر جدی روی کدهای اصلی باید تغییر کنند.
حجم کل کدهای تست تولید شده معمولاً باید برابر یا بیشتر از حجم کدهای اصلی باشه. (یعنی برای همه موارد تست نوشته شده باشه)
کدهای تست باید در همان روزی که کدهای اصلی پروژه نوشته میشن تولید بشن. (به روزهای آینده موکول نشه)
تست case ها باید کدها، متدها و امکانات پروژه رو به سخت ترین شکل به چالش بکشن.
از test double ها استفاده مجدد کنید.
تا حد امکان از تست کردن محتوای private کلاس ها و Private API ها پرهیز کنید. (بواسطه کدهای public تست blackbox انجام بدید یا CUT رو redesign کنید)
هنگام نوشتن تست case تا حد امکان از بکار بردن دستورات شرطی if/else/switch... پرهیز کنید.
بهتره کدهای تست به خارج از محدوده پروژه dependency نداشته باشن.
بهتره نام فایل تست به کلمه Test ختم بشه. مثل EmailTest, UtilityTest, DatabaseTest
بهتره نام توابع/متدهای داخل فایل تست با کلمه test شروع بشن. مثل test_if_email_is_valid یا testIsEmailValid
همیشه تست هارو هم برای سناریوی happy path و هم unhappy path بنویسید. (تست happy path تضمین می کنه که سیستم در شرایط عادی به درستی کار می کنه، اما unhappy path به کشف و رسیدگی به مسائل مربوط به مدیریت خطا، امنیت و انعطاف پذیری در مواجهه با سناریوهای غیرمنتظره کمک می کنه.)