PHP-FIG PSR standarti

Īsi: PSR (PHP Standards Recommendations) ir PHP-FIG standarti, kuras biedri ir iedibināti PHP projekti. Tie nosaka kopīgus noteikumus un saskarnes, piemēram, PSR-4 autoloading, PSR-3 reģistrētājiem (logger), PSR-7 HTTP ziņojumiem un PSR-11 konteineriem. Katram PSR ir statuss: pieņemts, melnraksts, novecojis vai pamests. PSR padara kodu viegāk nomaināmu un pārbaudāmu, bet neaizver ievainojamības PHP interpretatorā, piemēram, PHP2Shell.

Kas ir PHP-FIG un kas ir PSR?

PHP-FIG ir PHP Framework Interop Group. Grupa savu mērķi pati apraksta kā PHP virzīšanu uz priekšu ar sadarbību un standartiem. Aiz PSR tātad nestāv ražotājs, bet projektu vienošanās, kas vēlas saglabāt savu programmatūru savstarpēji saderīgu.

Lēmumu pieņēmējiem ieguvums ir taustāms: ja lietojumprogramma ievēro PSR saskarnes, reģistrēšanas bibliotēku var nomainīt, neskarot visu kodu. Tas mazina atkarību no atsevišķām pakotnēm un pakalpojumu sniedzējiem.

PSR ceļš: no Pre-Draft līdz Accepted

PHP-FIG statūti apraksta noteiktu norisi:

1. Pre-Draft: tiek noskaidrots, vai ir pietiekama interese. Izveidojas darba grupa, pēc veiksmīgas balsošanas priekšlikums saņem PSR numuru.
2. Draft: priekšlikumu izstrādā, alternatīvas un pamatojumi nonāk meta dokumentā.
3. Review: kopiena testē specifikāciju ar izmēģinājuma implementācijām vismaz četras nedēļas un līdz ir pieejamas divas neatkarīgas, dzīvotspējīgas ievirzes.
4. Accepted: pēc veiksmīgas balsošanas PSR ir pieņemts; darba grupa izkūst.

Bez tam ir vēl divi stāvokļi. Deprecated nozīmē: pieņemts, bet vairs nav ieteicams, parasti tāpēc, ka to aizstāj jaunāks standarts. Abandoned nozīmē: pie tā vairs nestrādā.

Visi PSR ar statusu

Stāvoklis saskaņā ar PHP-FIG pārskatu šīs lapas sagatavošanas brīdī:

Svarīgākie PSR praksei

• PSR-4 (autoloading): attēlo klašu nosaukumus faila ceļos un ir Composer autoloader pamats. Detaļas lapā Nosaukumvietas un autoloading.
• PSR-1 un PER Coding Style: kopīgi noteikumi rakstībai un formatēšanai. PER Coding Style saskaņā ar PHP-FIG papildina un aizstāj PSR-12 un paredz PSR-1.
• PSR-3 (logger): vienota reģistrētāja saskarne nosaukumvietā Psr\Log ar astoņiem līmeņiem no emergency līdz debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): saskarnes pieprasījumiem un atbildēm, starpprogrammatūrai (middleware), rūpnīcām un HTTP klientiem. Daudzi PHP ietvari uz tām balstās vai piedāvā tiltus.
• PSR-11 (konteiners): kopīga saskarne Dependency Injection konteineriem.
• PSR-6 un PSR-16 (kešatmiņa): divas saskarnes starpatmiņai, plašāka un vienkārša.
• PSR-14 un PSR-20 (notikumi, pulkstenis): kopīgas saskarnes notikumiem un pašreizējam laikam. Nomaināms pulkstenis laikatkarīgu kodu, piemēram, tokenu derīguma beigšanos, padara labi testējamu.

Numuri, starp citu, neko nesaka par nozīmīgumu. Tos piešķir, ieejot melnraksta fāzē, tāpēc novecojuši un pamesti priekšlikumi atrodas starp svarīgiem, pieņemtiem standartiem.

<?php
use Psr\Log\LoggerInterface;

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

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

Kāda ir PSR saistība ar drošību

Vairāki standarti drošību skar tieši. PSR-3 nosaka, ka izņēmumi tiek nodoti zem atslēgas exception kontekstā un ka vietturi, piemēram, {datei}, tiek aizstāti no konteksta. Vērtības tajā pašā laikā nedrīkst maskēt iepriekš, jo reģistrētājs nezina, kur tās vēlāk tiks rādītas. Kas žurnālus rāda tīmekļa saskarnē, tam maskēšana jāveic tur. Vairāk rakstā Droša reģistrēšana.

PSR-7 apraksta HTTP ziņojumus kā nemaināmus objektus un ar UploadedFileInterface::moveTo() piedāvā vienotu veidu, kā saglabāt augšupielādētos failus. Specifikācija pieprasa, ka pēc tam oriģinālais fails ir noņemts. Faila tipa un mērķa vietas pārbaude paliek lietojumprogrammas uzdevums.

Ievērības cienīgi, ka PSR-9 (Security Advisories) un PSR-10 (Security Reporting Process) ir pamesti. Vienota standarta drošības ziņojumiem tātad nav; katrs projekts to nosaka pats. Kā ar ievainojamībām rīkojas pats PHP projekts, apraksta lapa Kā PHP projekts apstrādā drošības ievainojamības.

Pret PHP2Shell standarti nepalīdz: ievainojamības CVE-2026-109618 un CVE-2026-109619 atrodas interpretatorā. Obligāts ir atjauninājums uz PHP 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 un visu PHP procesu pārstartēšana.

Kā PHP SOS palīdz konkrēti?

• Mēs pārbaudām, kā jūsu lietojumprogramma reģistrē notikumus, un nodrošinām, ka izņēmumi nonāk žurnālā, bet pieejas dati vai sesiju identifikatori ne.
• Mēs izvērtējam, kā īstenota augšupielāžu un HTTP apstrāde, arī tad, ja tā notiek caur PSR-7 bibliotēkām.
• Mēs izpētām pašrakstītos risinājumus drošības audita un penetrācijas testa ietvaros.
• Mēs ieviešam PHP atjauninājumus, pārstartējam visus darbprocesus un dokumentējam stāvokli.

Biežāk uzdotie jautājumi

Avoti

• PHP-FIG: PSR pārskats
• PHP-FIG: PSR darbplūsma
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface