Röviden: A Composer a PHP csomagkezelője. A composer.json fájlból kiolvassa, mely programkönyvtárakra van szüksége egy projektnek, betölti őket a vendor mappába, a pontos verziókat a composer.lock fájlban rögzíti, és létrehoz egy autoloadert, amely automatikusan megtalálja az osztályokat. A Composer ezzel az alkalmazás kódját kezeli, nem magát a PHP-értelmezőt: egy Composer-frissítés nem zár be a PHP-ban lévő rést, mint a PHP2Shell.
Mi a Composer, és mire jó?
Ma már alig áll egy PHP-alkalmazás csak saját kódból. Keretrendszerek, levelező programkönyvtárak, PDF-előállítás vagy fizetési kapcsolatok kész csomagokként érkeznek hozzá. A Composer, a PHP csomagkezelője, gondoskodik arról, hogy ezek a csomagok megfelelő verziókban álljanak össze, és hogy minden függőség magával hozza a saját függőségeit.
Döntéshozóknak ez azt jelenti: a szerverén futó kód nagy része harmadik féltől származik. Ez hatékony, de gondozást igényel. Adminisztrátoroknak és fejlesztőknek ez azt jelenti: aki a Composert rendesen használja, bármikor visszakövetheti, hogy melyik programkönyvtár melyik verziója fut éles üzemben.
A csomagok alapértelmezett forrása a Composer-dokumentáció szerint a Packagist.org. További források, például egy ügynökség belső tárolói, a composer.json fájlban a repositories alatt adhatók meg.
composer.json, composer.lock és vendor: a három építőelem
A Composer három dologgal dolgozik, amelyeket ismerni kell, mielőtt valaki átvesz egy szervert, vagy megbíz egy ügynökséget.
| Építőelem | Tartalom | A tárolóba tartozik? |
|---|---|---|
composer.json |
a kívánt csomagok verziótartományokkal (require, require-dev), autoload-szabályok, beállítások |
igen |
composer.lock |
az összes csomag pontosan feloldott verziója, a közvetettekéi is | igen, a Composer-dokumentáció szerint kifejezetten |
vendor/ |
a csomagok letöltött kódja és a létrehozott autoloader | nem, telepítéskor jön létre |
A require alatt azok a csomagok állnak, amelyekre az alkalmazásnak üzem közben szüksége van. A require-dev alatt a fejlesztés és a tesztelés eszközei, például tesztkeretrendszerek vagy statikus elemzés. Ez az elkülönítés azért fontos, mert a fejlesztői eszközöknek semmi keresnivalójuk egy éles szerveren.
{
"require": {
"php": ">=8.3",
"monolog/monolog": "^3.0"
},
"require-dev": {
"phpunit/phpunit": "^11.0"
},
"autoload": {
"psr-4": { "App\\": "src/" }
}
}
A példában szereplő verziómegjelölések csak szemléltetésként szolgálnak. Hogy a projektjének mely verziókra van szüksége, az az igényeiből adódik.
install vagy update: a különbség üzem közben
A két parancs hasonlóan hangzik, de nagyon eltérő következményei vannak.
- A
composer installbeolvassa acomposer.lockfájlt, és pontosan az abban rögzített verziókat telepíti. Ez reprodukálható, és a kiszállításhoz tartozik. - A
composer updateújra feloldja az összes függőséget, a legújabb megfelelő verziókat hozza, és újraírja acomposer.lockfájlt. Ez a fejlesztéshez tartozik, az ezt követő tesztekkel.
A Composer-dokumentáció szerint az update a lock-fájl írása után további biztonsági ellenőrzést (audit) is lefuttat, hacsak nem kapcsolják ki a --no-audit kapcsolóval. Az install alapértelmezetten nem ellenőriz; erre való a --audit kapcsoló.
Autoloading: hogyan találja meg a Composer az osztályokat
A Composer létrehozza a vendor/autoload.php fájlt. Ha egyszer beillesztik, a PHP minden osztályt csak akkor tölt be, amikor szükség van rá. A saját kódhoz az autoload szakaszban kell meghatározni, melyik névtér melyik mappában van. Erre a PSR-4 ajánlott, a PHP-FIG egyik szabványa. Hogyan működik ez pontosan, azt a Névterek és autoloading oldal magyarázza; az összes szabványról áttekintést a PSR-szabványok oldal ad.
<?php
require __DIR__ . '/../vendor/autoload.php';
$log = new Monolog\Logger('app'); // szükség esetén automatikusan betöltődik
Composer éles üzemben: tiszta kiszállítás
A kiszállításhoz bevált egy rögzített sorrend. A legjobb, ha egy build-folyamatban fut, és nem kézzel a szerveren.
- A lock-fájl ellenőrzése: a
composer validatebiztosítja, hogy acomposer.jsonérvényes és acomposer.locknaprakész. - Telepítés fejlesztői csomagok nélkül: a
composer install --no-devkihagyja arequire-devrészt. - Az autoloader optimalizálása: az
--optimize-autoloader(röviden-o) a szabályokat osztálylistává alakítja. A--classmap-authoritativekapcsolóval a PHP az osztályokat kizárólag ebből a listából tölti be. - Biztonsági ellenőrzés: a
composer audit --lockeda lock-fájl verzióit összeveti az ismert biztonsági közleményekkel, és jelzi a felhagyott csomagokat. - A vendor a webgyökéren kívül: csak a belépési szkriptet tartalmazó nyilvános mappának szabad URL-en keresztül elérhetőnek lennie.
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev
A composer outdated ezen kívül megmutatja, mely telepített csomagokhoz van újabb verzió. Ez az alapja a tervezett frissítéseknek a kapkodó egyedi akciók helyett.
Composer, biztonság és PHP2Shell
A Composer és a PHP2Shell két különböző szintet érint. A CVE-2026-109618 és a CVE-2026-109619 rések magában a PHP-értelmezőben vannak. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították őket, és utána az összes PHP-folyamatot újra kell indítani. Semmilyen composer update és semmilyen csomag a vendor-ban ezen nem változtat.
Ennek ellenére a Composer minden incidens utáni ellenőrzéshez hozzátartozik. Aki kártékony kódot visz fel egy szerverre, a vendor fájljait is módosíthatja, a vendor/autoload.php pedig minden kérésnél betöltődik. Egy friss composer install az ellenőrzött lock-fájlból egy üres könyvtárba ezért jó módszer a csomagállomány helyreállítására. Hogyan ellenőrizheti rendszeresen a függőségeket ismert rések szempontjából, azt a composer audit útmutató írja le.
A zöld composer audit semmit sem mond a PHP patch-állapotáról. A PHP-futtatókörnyezetet külön ellenőrizze, például a PHP-javítási szolgáltatásunkkal.
Hogyan segít konkrétan a PHP SOS?
- Minden alkalmazásnál felmérjük a PHP-verziót, a Composer-csomagokat és a lock-állapotot, és közben tisztán elkülönítjük az értelmezőt a programkönyvtáraktól.
- Ellenőrizzük, hogy a
vendorés a lock-fájl összeillik-e, és hogy fejlesztői csomagok vagy módosított fájlok vannak-e az éles környezetben. - Reprodukálható kiszállítást állítunk be
install --no-devparanccsal, optimalizált autoloaderrel és audittal. - Incidens után az ellenőrzött lock-fájlból újra létrehozzuk a csomagállományt, és dokumentáljuk az eredményt.
Gyakori kérdések
Be kell tenni a composer.lock-ot a Git-tárolóba?
Igen. A Composer-dokumentáció kifejezetten ajánlja a composer.lock commitolását. Csak így telepít a fejlesztés, a CI és az éles üzem pontosan ugyanazokat a csomagverziókat.
Mi a különbség a composer install és a composer update között?
Az install azokat a verziókat telepíti, amelyeket a composer.lock rögzít. Az update újra feloldja a függőségeket, megfelelő újabb verziókat hoz, és újraírja a composer.lock-ot. Az éles szerverre csak az install való.
Bezárja a PHP2Shell-rést egy Composer-frissítés?
Nem. A Composer az alkalmazás programkönyvtárait kezeli, nem a PHP-értelmezőt. A PHP2Shellt csak a PHP-futtatókörnyezet javított verzióra való frissítése és az összes PHP-folyamat újraindítása zárja be.
Hol legyen a vendor mappa?
Ideális esetben a nyilvánosan elérhető webkönyvtáron kívül. Sok keretrendszer csak egy public mappát tesz a webgyökérbe, a vendor pedig egy szinttel feljebb van.