Keskustelu: Nettisivujen teko: PHP ja tyhjiä sivuja

Pari vasta-alkajatason kysymystä PHP:n toiminnasta.

a) Mikähän mahtaa olla vikana kun tuolla käyttämälläni palvelimella ei phpinfo() tunnu toimivan lainkaan. Skriptit toimivat muuten, mutta phpinfo() tulostaa pelkkää tyhjää. Ilmeisesti sen käyttö on jotenkin estetty, mutta onko asialle tehtävissä mitään?

b) Mitenkähän saisin edes jonkinlaista palautetta tekemistäni virheistä? Jokainen virhe skriptissä aiheuttaa skriptin totaalisen toimimattomuuden ja tuloksena on aina tyhjä sivu. Sitten ankaran metsästyksen jälkeen syyksi paljastuu yleensä pieni typo jossain mitättömässä kohdassa. Kokeilin seuraavaa, mutta ei auttanut yhtään:

<?php
error_reporting(E_ALL);

c) Minkälaista kehitysympäristöä muuten suosittelisitte PHP:lle? PHP-haasteen tehtäviin tuo picolla editointi suoraan palvelimelle on ollut täysin riittävä, mutta ei sillä tavalla mitään suurempaa viitsisi häksäillä kasaan.

c) Käytän sshfs + geany -yhdistelmää, eli suoraan palvelimelle koodaan minäkin, mutta editori on omalla koneella.

a) Jos asiaa voisi muuttaa kajoamatta palvelimen asetuksiin, mitä hyötyä tällaisesta estosta olisi? Estot ovat estämistä varten. (Mainittu funktio tulostaa paljon yksityiskohtaisia tietoja, joita joku voisi hyödyntää murtautuakseen palvelimelle.)

b) Tarvitset kaksi asetusta: error_reporting ja display_errors. Kattavimmat ilmoitukset saa näin:

<?php
ini_set("display_errors", 1);
ini_set("error_reporting", E_ALL | E_STRICT);

Kun asetukset laitetaan koodissa, ne eivät valitettavasti auta ajettavan tiedoston syntaksivirheisiin, koska syntaksivirheet käsitellään jo ennen koodin ajamista. Tätä varten asetukset pitäisi laittaa PHP:n asetustiedostoon (php.ini), johon tietenkin pääsee käsiksi vain, jos palvelin on oma. Toinen vaihtoehto on laittaa nuo ini_set-rivit yhteen tiedostoon ja niiden jälkeen liittää includella varsinainen kooditiedosto.

<?php
ini_set("display_errors", 1);
ini_set("error_reporting", E_ALL | E_STRICT);
include("oikea.php");

Tällä tavalla oikean koodin syntaksivirheilmoitukset tulevat vasta include-rivillä ja uudet asetukset ovat voimassa.

c) Työhommissa pyöritän täyttä palvelinta omalla koneellani, muuta järkevää vaihtoehtoa ei oikein ole. Kotona kirjoittelen suoraan palvelimella (pienet asiat), kopioin tiedostot manuaalisesti (keskikokoiset asiat) tai käytän sshfs:ää (isot asiat).

Metabolix kirjoitti:

a) Jos asiaa voisi muuttaa kajoamatta palvelimen asetuksiin, mitä hyötyä tällaisesta estosta olisi? Estot ovat estämistä varten. (Mainittu funktio tulostaa paljon yksityiskohtaisia tietoja, joita joku voisi hyödyntää murtautuakseen palvelimelle.)

No tälläistä epäilin itsekin, mutta siksi kysyin kun en tiennyt varmuudella onko kyse estosta vai jostain muusta, enkä sitäkään että kyseinen funktio voisi paljastaa "vaarallista" tietoa. Kiitos varmistuksesta.

Metabolix kirjoitti:

b)

<?php
ini_set("display_errors", 1);
ini_set("error_reporting", E_ALL | E_STRICT);
include("oikea.php");

Tällä tavalla oikean koodin syntaksivirheilmoitukset tulevat vasta include-rivillä ja uudet asetukset ovat voimassa.

Nerokasta. Toimii muuten tosi hienosti, mutta E_STRICTistä tulee tälläistä herjaa:

Notice: Use of undefined constant E_STRICT

Ajattelin tehdä tuosta vähän yleiskäyttöisemmän tällä tavalla:

<?php
$file = $_REQUEST['script'];

if(file_exists($file) && substr($file, -4) == ".php") {
        ini_set("display_errors", 1);
        ini_set("error_reporting", E_ALL | E_STRICT);
        include($file);
}
?>

Jos toteutan sen yllä olevalla tavalla, niin onko siinä teidän nähdäksenne mitään riskiä?

Metabolix kirjoitti:

c) Työhommissa pyöritän täyttä palvelinta omalla koneellani, muuta järkevää vaihtoehtoa ei oikein ole.

PHP-haasteen tehtävät teen jatkossakin varmaan suoraan palvelimelle, mutta kotikoneelle juuri asentelin tämän kokoonpanon:
http://www.netbeans.org/kb/61/php/configure-php-environment-windows.html

En vielä pahemmin testannut, mutta vaikuttaa ainakin parannukselta mustavalkoiseen picoon nähden. :)

Käyttämälläsi serverillä on siis käytössä vielä vanha PHP4, pyydä päivittämään / päivitä itse uusimpaan vitosversioon. Jos pääset käsiksi php.ini-tiedostoon niin nuo display_errors ja error_reporting kannattaa määritellä siellä. $_REQUEST on siinä mielessä hankala taulukko, että se sisältää muuttujia niin useasta eri lähteestä. Usein sitä käytetään aivan turhaan vaan sekottamaan pakkaa, koska harvoin tarvitaan saada syötteitä vaihtoehtoisesti lähteistä POST/GET/COOKIE. Voi olla ärsyttävä debugattava.

Ota E_STRICT pois, jos se palvelimen PHP-versiosta puuttuu. Sillä saisi ilmoituksia kaikenlaisista asioista, jotka ovat väärin mutta jotka PHP ystävällisesti kuitenkin ymmärtää. Useinhan sanotaan, että tuotannossa ei saisi näyttää virheilmoituksia tai varoituksia, mutta minusta parempi motto on, että tuotantokoodista ei saa edes tulla niitä. (Koodaan aina PHP:tä noilla tiukimmilla asetuksilla, ja vastaavasti C-kääntäjälle annan yleensä liput -std=c99 -Wall -pedantic. Näillä välttää typeriä pikkuvirheitä.)

Koodisi on aika riskialtis, käyttäjähän saa tuolla ajettua kaikenlaisia PHP-tiedostoja palvelimelta. Kannattaa vähintäänkin tarkistaa, ettei polku sisällä esimerkiksi ylähakemistoja (/../) tai URLin osia (http://) tai muuta vekkulia. Helpointa on varmaankin hajottaa polku explodella /-merkeistä ja tarkistaa jokainen osa erikseen. Ei saisi olla osia "", "." ja "..", ja lisäksi kieltäisin osista kaikki varman sarjan "A-Za-z0-9_-." ulkopuoliset merkit.

Unohtui mainita (vaikka kaipa sen saattoi arvata), että omassa käytössäni on Linux ja kehitysympäristövinkit tulevat sen mukaan. Jotkin Windows-editoritkin hallitsevat tiedostonsiirron ssh:n yli, ja jos projekti vaatii jotain vain palvelimella olevaa ominaisuutta, tällainen editori säästää vaivaa.

tsuriga kirjoitti:

pyydä päivittämään / päivitä itse uusimpaan vitosversioon

Ainahan voin kysyä onko päivityksiä luvassa, mutta en liikoja laskisi sen varaan. Taidan tyytyä ajamaan tuon ilman E_STRICTiä.

Metabolix kirjoitti:

Koodisi on aika riskialtis, käyttäjähän saa tuolla ajettua kaikenlaisia PHP-tiedostoja palvelimelta.

Ensimmäinen ajatus oli, että mitäs se haittaa, mutta hetken miettimisen jälkeen tajusin pointin. Sillähän saisi tosiaan kaikenlaista hauskaa ja vähemmän hauskaa aikaan. Lisäänpä tosiaan tarkistuksen, että skriptin on oltava samassa kansiossa. Sen pitäisi riittää, kunhan sinne ei pistä mitään upload-skriptiä. :)

Kiitoksia vastanneille.

Suosittelen vaihtamaan palveluntarjoajaa, jos eivät suostu päivittämään, mikäli mahdollista. PHP4:n virallinen tuki on jo loppunut, ja PHP5 sisältää huiman kasan parannuksia mm. olio-ohjelmoinnin saralla.

Metabolix kirjoitti:

Useinhan sanotaan, että tuotannossa ei saisi näyttää virheilmoituksia tai varoituksia, mutta minusta parempi motto on, että tuotantokoodista ei saa edes tulla niitä.

Eiväthän nämä ole toisensa poissulkevia. Toki on hyvä tavoitella täydellisyyttä, mutta ei tuotantoserverillä silti pidä laskea sen varaan, että oma ohjelma olisi virheetön.

tsuriga kirjoitti:

Eiväthän nämä ole toisensa poissulkevia. Toki on hyvä tavoitella täydellisyyttä, mutta ei tuotantoserverillä silti pidä laskea sen varaan, että oma ohjelma olisi virheetön.

Monella vain tuntuu olevan tapana jo kehitysvaiheessa testata skriptinsä tuotantoasetuksilla, jolloin kaikki E_STRICT- ja E_NOTICE-tason ilmoitukset jäävät pois, joskus jopa E_WARNING-tasoiset. Toisin sanoen ei edes tavoitella täydellisyyttä, vaan tavoitellaan skriptiä, joka enimmäkseen toimii suunnilleen oikein.

Tuotantopalvelimella saa olla aivan yhtä ankara error_reporting-asetus kuin kehityspalvelimellakin, mutta virheet tulostetaan ulos menevän virran sijasta tiedostoon. Lokitiedoston formaattia ja kokoa voidaan kontrolloida PHP:n lokiasetusten sekä erillisten ohjelmien avustuksella.

Perishable Press - Advanced PHP Error Handling