Standardi PSR skupine PHP-FIG

Na kratko: PSR-ji (PHP Standards Recommendations) so standardi skupine PHP-FIG, združenja uveljavljenih projektov PHP. Določajo skupna pravila in vmesnike, na primer PSR-4 za samodejno nalaganje, PSR-3 za loggerje, PSR-7 za sporočila HTTP in PSR-11 za vsebnike. Vsak PSR ima stanje: sprejet, osnutek, zastarel ali opuščen. PSR-ji naredijo kodo bolj zamenljivo in lažje preverljivo, ne zapirajo pa vrzeli v interpreterju PHP, kot je PHP2Shell.

Kaj sta PHP-FIG in PSR-ji?

PHP-FIG pomeni PHP Framework Interop Group. Skupina sama svoj cilj opisuje kot napredek PHP s sodelovanjem in standardi. Za PSR torej ne stoji noben proizvajalec, temveč uskladitev med projekti, ki želijo svojo programsko opremo ohranjati medsebojno združljivo.

Za odločevalce je korist oprijemljiva: če se aplikacija drži vmesnikov PSR, je mogoče na primer zamenjati knjižnico za beleženje, ne da bi se dotaknili vse kode. To zmanjša odvisnost od posameznih paketov in izvajalcev.

Pot PSR: od Pre-Draft do Accepted

Statut PHP-FIG opisuje fiksen potek:

1. Pre-Draft: razjasni se, ali je dovolj zanimanja. Oblikuje se delovna skupina, po uspešnem glasovanju predlog dobi številko PSR.
2. Draft: predlog se izdela, alternative in utemeljitve gredo v metadokument.
3. Review: skupnost specifikacijo preizkuša s poskusnimi implementacijami, najmanj štiri tedne in dokler ni na voljo dveh neodvisnih, uporabnih izvedb.
4. Accepted: po uspešnem glasovanju je PSR sprejet; delovna skupina se razpusti.

Poleg tega obstajata še dve stanji. Deprecated pomeni: sprejet, a ni več priporočen, večinoma ker ga nadomešča novejši standard. Abandoned pomeni: delo na njem se ne nadaljuje.

Vsi PSR-ji s stanjem

Stanje po pregledu PHP-FIG v času nastanka te strani:

Najpomembnejši PSR-ji za prakso

• PSR-4 (samodejno nalaganje): imena razredov preslika v poti datotek in je osnova nalagalnika Composer. Podrobnosti na strani Imenski prostori in samodejno nalaganje.
• PSR-1 in PER Coding Style: skupna pravila za zapis in oblikovanje. PER Coding Style po navedbah PHP-FIG razširja in nadomešča PSR-12 ter predpostavlja PSR-1.
• PSR-3 (Logger): enoten vmesnik loggerja v imenskem prostoru Psr\Log z osmimi stopnjami od emergency do debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): vmesniki za zahteve in odgovore, vmesno programje (middleware), tovarne in odjemalce HTTP. Številna ogrodja PHP temeljijo nanje ali ponujajo mostove.
• PSR-11 (vsebnik): skupni vmesnik za vsebnike vbrizgavanja odvisnosti (dependency injection).
• PSR-6 in PSR-16 (predpomnilnik): dva vmesnika za vmesni pomnilnik, obsežen in preprost.
• PSR-14 in PSR-20 (dogodki, ura): skupna vmesnika za dogodke in za trenutni čas. Zamenljiva ura naredi kodo, odvisno od časa, na primer potek veljavnosti žetonov, dobro preizkusljivo.

Številke sicer ne povedo ničesar o pomenu. Dodelijo se ob vstopu v fazo osnutka, zato med pomembnimi, sprejetimi standardi stojijo zastareli in opuščeni predlogi.

<?php
use Psr\Log\LoggerInterface;

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

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

Kaj imajo PSR-ji opraviti z varnostjo

Več standardov se neposredno dotika varnosti. PSR-3 določa, da se izjeme v kontekstu posredujejo pod ključem exception in da se označbe mest, kot je {datei}, nadomestijo iz konteksta. Vrednosti pri tem ne smejo biti vnaprej maskirane, ker logger ne ve, kje se bodo pozneje prikazale. Kdor dnevnike prikazuje v spletnem vmesniku, mora maskirati tam. Več o tem v prispevku Varno beleženje.

PSR-7 opisuje sporočila HTTP kot nespremenljive objekte in z UploadedFileInterface::moveTo() ponuja enoten način za shranjevanje naloženih datotek. Specifikacija zahteva, da je izvirna datoteka potem odstranjena. Preverjanje tipa datoteke in ciljnega mesta ostaja naloga aplikacije.

Omembe vredno je, da sta bila PSR-9 (Security Advisories) in PSR-10 (Security Reporting Process) opuščena. Skupnega standarda za varnostna sporočila tako ni; vsak projekt to ureja sam. Kako z vrzelmi ravna sam projekt PHP, opisuje stran Kako projekt PHP obravnava varnostne vrzeli.

Proti PHP2Shell standardi ne pomagajo: ranljivosti CVE-2026-109618 in CVE-2026-109619 ležita v interpreterju. Obvezna sta posodobitev na PHP 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 in ponovni zagon vseh procesov PHP.

Kako PHP SOS pomaga konkretno?

• Preverimo, kako vaša aplikacija beleži, in poskrbimo, da izjeme pristanejo v dnevniku, dostopni podatki ali identifikatorji sej pa ne.
• Ocenimo, kako sta izvedena obdelava nalaganja in HTTP, tudi če poteka prek knjižnic PSR-7.
• Lastne razvoje preiščemo v okviru varnostnega pregleda in penetracijskega testa.
• Namestimo posodobitve PHP, znova zaženemo vse workerje in dokumentiramo stanje.

Pogosta vprašanja

Viri

• PHP-FIG: pregled PSR
• PHP-FIG: potek dela PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: vmesnik PSR-3 Logger
• PHP-FIG: vmesnik PSR-7 za sporočila HTTP