PHP-FIG PSR standartai

Trumpai: PSR (PHP Standards Recommendations) yra PHP-FIG, įsitvirtinusių PHP projektų grupės, standartai. Jie nustato bendras taisykles ir sąsajas, pavyzdžiui, PSR-4 autoloading, PSR-3 žurnalų rašymui, PSR-7 HTTP pranešimams ir PSR-11 konteineriams. Kiekvienas PSR turi būseną: priimtas, projektas, pasenęs arba apleistas. PSR daro kodą keičiamesnį ir lengviau tikrinamą, bet neuždaro spragų PHP interpretatoriuje, tokių kaip PHP2Shell.

Kas yra PHP-FIG ir kas yra PSR?

PHP-FIG reiškia PHP Framework Interop Group. Grupė pati savo tikslą apibūdina kaip PHP tobulinimą bendradarbiavimu ir standartais. Taigi už PSR stovi ne gamintojas, o projektų, norinčių išlaikyti savo programinės įrangos tarpusavio suderinamumą, susitarimas.

Sprendimų priėmėjams nauda apčiuopiama: jei programa laikosi PSR sąsajų, galima, pavyzdžiui, pakeisti žurnalų rašymo biblioteką, nelieskiant viso kodo. Tai mažina priklausomybę nuo atskirų paketų ir paslaugų teikėjų.

PSR kelias: nuo Pre-Draft iki Accepted

PHP-FIG įstatai aprašo nusistovėjusią eigą:

1. Pre-Draft: išsiaiškinama, ar yra pakankamai susidomėjimo. Susidaro darbo grupė, po sėkmingo balsavimo pasiūlymas gauna PSR numerį.
2. Draft: pasiūlymas išplėtojamas, alternatyvos ir pagrindimai patenka į meta dokumentą.
3. Review: bendruomenė išbando specifikaciją su bandomaisiais įgyvendinimais, mažiausiai keturias savaites ir kol atsiranda du nepriklausomi, gyvybingi įgyvendinimai.
4. Accepted: po sėkmingo balsavimo PSR priimamas; darbo grupė paleidžiama.

Be to yra dvi papildomos būsenos. Deprecated reiškia: priimtas, bet nebenerekomenduojamas, dažniausiai todėl, kad jį pakeitė naujesnis standartas. Abandoned reiškia: prie jo daugiau nedirbama.

Visi PSR su būsena

Būsena pagal PHP-FIG apžvalgą šio puslapio rengimo metu:

Svarbiausi PSR praktikai

• PSR-4 (autoloading): susieja klasių pavadinimus su failų keliais ir yra Composer autoloader pagrindas. Išsamiau puslapyje Vardų erdvės ir autoloading.
• PSR-1 ir PER Coding Style: bendros rašybos ir formatavimo taisyklės. Pasak PHP-FIG, PER Coding Style išplečia ir pakeičia PSR-12 ir remiasi PSR-1.
• PSR-3 (žurnalų rašymas): vieninga žurnalų rašymo sąsaja vardų erdvėje Psr\Log su aštuoniais lygiais nuo emergency iki debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): sąsajos užklausoms ir atsakymams, tarpinei programinei įrangai (middleware), gamykloms ir HTTP klientams. Daug PHP karkasų remiasi jomis arba siūlo tiltus.
• PSR-11 (konteineris): bendra sąsaja priklausomybių injekcijos konteineriams.
• PSR-6 ir PSR-16 (talpykla): dvi sąsajos laikinajai saugyklai, viena išsami ir viena paprasta.
• PSR-14 ir PSR-20 (įvykiai, laikrodis): bendros sąsajos įvykiams ir dabartiniam laikui. Pakeičiamas laikrodis daro nuo laiko priklausomą kodą, pavyzdžiui, žetonų galiojimo pabaigą, gerai testuojamą.

Beje, numeriai nieko nesako apie svarbą. Jie suteikiami pradedant juodraščio fazę, todėl pasenę ir apleisti pasiūlymai stovi tarp svarbių, priimtų standartų.

<?php
use Psr\Log\LoggerInterface;

final class Bestellimport
{
    public function __construct(private LoggerInterface $log) {}

    public function importieren(string $datei): void
    {
        try {
            // ... failo apdorojimas ...
        } catch (\Throwable $e) {
            $this->log->error('Import von {datei} fehlgeschlagen', [
                'datei'     => basename($datei),
                'exception' => $e,
            ]);
        }
    }
}

Ką PSR turi bendro su saugumu

Keli standartai tiesiogiai liečia saugumą. PSR-3 nustato, kad išimtys kontekste perduodamos po raktu exception, o vietos žymekliai, pavyzdžiui, {datei}, pakeičiami reikšmėmis iš konteksto. Reikšmės tuo metu neturi būti iš anksto maskuojamos, nes žurnalų rašytojas nežino, kur jos vėliau bus rodomos. Kas žurnalus rodo žiniatinklio sąsajoje, ten turi maskuoti. Daugiau straipsnyje Saugus protokolavimas.

PSR-7 aprašo HTTP pranešimus kaip nekeičiamus objektus ir su UploadedFileInterface::moveTo() siūlo vieningą būdą išsaugoti įkeltus failus. Specifikacija reikalauja, kad po to originalus failas būtų pašalintas. Failo tipo ir paskirties vietos patikra lieka programos užduotis.

Pastebėtina, kad PSR-9 (Security Advisories) ir PSR-10 (Security Reporting Process) buvo apleisti. Taigi bendro saugumo pranešimų standarto nėra; kiekvienas projektas tai reglamentuoja pats. Kaip su spragomis elgiasi pats PHP projektas, aprašo puslapis Kaip PHP projektas tvarko saugumo spragas.

Nuo PHP2Shell standartai nepadeda: spragos CVE-2026-109618 ir CVE-2026-109619 slypi interpretatoriuje. Privaloma atnaujinti iki PHP 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 ir paleisti iš naujo visus PHP procesus.

Kaip PHP SOS padeda konkrečiai?

• Tikriname, kaip jūsų programa rašo žurnalus, ir užtikriname, kad išimtys patektų į žurnalą, bet ne prieigos duomenys ar sesijų identifikatoriai.
• Vertiname, kaip įgyvendintas įkėlimų ir HTTP apdorojimas, net jei jis vyksta per PSR-7 bibliotekas.
• Nuosavus sprendimus tiriame pagal saugumo audito ir skverbties testo paslaugą.
• Įdiegiame PHP atnaujinimus, paleidžiame iš naujo visus darbinius procesus (worker) ir dokumentuojame būseną.

Dažni klausimai

Šaltiniai

• PHP-FIG: PSR apžvalga
• PHP-FIG: PSR darbo eiga
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface