Toisessa keskustelussa tuli esille ajatus kirjoittaa opaskokonaisuus MySQL:n käytöstä PHP:ssä, tietokannan suunnittelusta ja SQL-kyselyistä. Tämä ajatus on todella hyvä, joten ruvetaanpa suunnittelemaan kirjoitustyötä tarkemmin.
1. Mitä aiheesta on kirjoitettu aiemmin suomeksi Internetissä? Entä mitä hyviä oppaita on olemassa englanniksi?
2. Mikä olisi oppaiden lähestymistapa? Mielessäni on kaksi vaihtoehtoa: oppaissa esitellään yleisesti asioita pienin esimerkein (kuten Ohjelmointiputkan PHP-oppaissa) tai oppaat rakentuvat jonkin suuremman projektin ympärille (esim. toteutetaan verkkokauppa).
3. Mitä asioita oppaat käsittelisivät ja miten?
Tässä on joitakin ehdotuksia:
Tietokannan suunnittelu: Tietokannan rakenne ja taulujen järkevä suunnittelu.
SQL-kyselyt: SELECT, INSERT, UPDATE ja DELETE. Myös monimutkaisempia esimerkkejä.
Tietokannan hallinta: Taulujen luonti ja muutokset. Pitäisikö opettaa SQL-kyselyjä vai jonkin hallintasovelluksen (kuten phpMyAdmin) käyttöä?
PHP ja MySQL: Tietokantaan yhdistys, kyselyn tekeminen ja tulosten käsittely. Pitäisikö opettaa eri tapoja (perinteiset tavat, PDO) vai yksi tapa?
Lisätietoa: indeksit, transaktiot, viite-eheys, muuta?
Toivon kommentteja kaikilta asiasta kiinnostuneilta. Kirjoittajien lisäksi projektissa tarvitaan palautteen antajia.
Minusta olisi loogisinta kirjoittaa opas esimerkiksi juuri verkkokaupan ympärille, jolloin oppaan viimeisen osan valmistuttua olisi valmis sovellus. Tällöin myös esimerkit olisivat mahdollisesti vähemmän teennäisiä.
Onko kamalan hankala lukea opasta, jossa olisi kaksi vaihtoehtoista merkintätapaa kyselyiden tekemiseen? Tarkoitan lähinnä perinteistä käsin tehtyä kyselyä, jonka jälkeen tulisi PDO versio samasta kyselystä.
Kuten tuossa toisessa viestiketjussa mainitsin, niin itsellä on jonkunlainen runko jo kirjoitettuna/mietittynä. Muutama pointti siitä:
- Siinä oletetaan, että lukija osaa tietokantojen perusteet
- Siinä ei ollut tarkoitus käsitellä tietokannan käyttöä PHP:llä (kuuluu "tietokantojen perusteisiin")
Oppaan nimi on "Enemmän irti MySQL-tietokannasta" ja aloin porttaamaan sitä tänään op:n opasformaattiin. Runko on kutakuinkin seuraava:
1. Tietokannan suunnittelu (valmis)
2. Indeksointi (aloitettu, hyvällä mallilla)
3. Viite-eheys (ei aloitettu)
4. Liipaisut (triggers) ja Tallennetut proseduurit (stored procedures) (ei aloitettu)
5. Näkymä-taulut (ei aloitettu)
6. Transaktio (ei aloitettu, eikä allekirjoittaneelle edes kovin tuttu asia :))
Minusta tuossa opassarjassa on tarpeeksi asiaa itsessään ja kaikki osat liittyvät nimenomaan tietokantaan, ei asiakaskieleen. En haluaisi sekoittaa PHP:tä siihen (voihan asiakaskieli olla joku muukin). Pitäisikö tehdä erikseen PHP+MySQL-opas, jossa käsiteltäisiin perus-asioita?
Edit: vaihdoin juuri oppaan nimen, ei ollut ehkä ihan loppuun asti mietitty, eikä ole vieläkään.
Mikään ei tietenkään estä tekemästä kahta opasta aiheesta. Toinen voisi keskittyä tietokannan rakenteeseen ja toinen kannan käyttämiseen asiakasohjelmalla. Antin perusoppaassahan on yhden sivun verran asiaa kannan käytöstä, joten sen jatkoksi voisi tehdä tuota asiakasohjelmaopasta?
Teuro kirjoitti:
Minusta olisi loogisinta kirjoittaa opas esimerkiksi juuri verkkokaupan ympärille - - esimerkit olisivat mahdollisesti vähemmän teennäisiä.
Toisaalta kaikkia olennaisia SQL-kyselyjä voi olla hankalaa esitellä luontevasti valitussa esimerkkitapauksessa.
Teuro kirjoitti:
Onko kamalan hankala lukea opasta, jossa olisi kaksi vaihtoehtoista merkintätapaa kyselyiden tekemiseen?
Minusta olisi parasta valita mahdollisen vaihtoehtojen esittelyn jälkeen yksi merkintätapa, jota oppaiden kaikki esimerkit noudattavat.
ajv kirjoitti:
Pitäisikö tehdä erikseen PHP+MySQL-opas, jossa käsiteltäisiin perus-asioita?
Tämä kuulostaa järkevältä ratkaisulta. PHP-asiat ja tavalliset SQL-kyselyt kuuluisivat siis selkeästi perusoppaisiin. Lisäksi niissä voisi kertoa hieman tietokannan suunnittelusta (miten tietoa säilytetään tauluissa) sekä mainita lyhyesti indeksit, transaktiot yms., joista saa lisätietoa ajv:n oppaista.
Perusoppaissa asiaa on minusta järkevää käsitellä nimenomaan PHP:n ja MySQL:n näkökulmasta, koska se yhdistelmä on yleensä nettiohjelmointia harrastavan käytössä ja opittuja taitoja on myöhemmin helppoa soveltaa muualla.
Verkkokauppa saattaa esimerkkinä olla kuitenkin sen verran laaja, että suurin osa kyselyistä tullee kuitenkin aika luontevasti esiteltyä. Ihan pienellä miettimisellä en saa päähäni mitään kyselyä, joka jäisi pois. Mikäli joku aivan oleellinen kysely jäisi pois, voinee sen korvata teennäisellä esimerkillä?
Itse voisin ehdottaa näin vähemmän mysql:een perehtyneenä erityisesti tietokannan rakenteeseen painottuvaa opasta ja esimerkkejä momimutkaisistakin kyselyistä isommissa tietokannoissa. Ei ehkä kannata lähteä liikkeelle niistä yksinkertaisimmista esimerkeistä enään, kun ne löytyy helposti netistä suomeksikin?
ajv:n rakenne näyttää fiksulta ja luontevalta. Suunnittelu se noista varmaankin tärkein on, sitä kun tarvitaan käytännössä jokaisessa projektissa (triggereitä, proseduureja yms. hienouksia sen sijaan harva jaksaa pienempiin projekteihin tunkemaan, itse en ainakaan).
Suunnittelusta helposti saisikin oman oppaan aiheen. Eri objektien tunnistaminen ja jakaminen taulurakenteeseen, yhteydet ja niiden toteutus (yksi yhteen, yksi moneen, moni moneen), normaalimuodot... Näitä varmaankin on aika vaikea ymmärrettävästi selittää ilman elävää esimerkkiä kuvien kera (vaikka MySQL Workbenchillä tehdä kaaviot tietokannasta).
Jos taas PHP+MySQL opasta joku alkaa tekemään, lienee fiksuinta todellakin käyttää jotain tietokantarajapintaa (kuten PDO).
JTS kirjoitti:
Jos taas PHP+MySQL opasta joku alkaa tekemään, lienee fiksuinta todellakin käyttää jotain tietokantarajapintaa (kuten PDO).
Toisaalta PDO:n kanssa tehtäessä olisi eduksi tietää mitä "pinnan alla" tapahtuu, koska se auttaa hahmottamaan kokonaisuutta. Esimerkiksi parametrien sidonta kyselyyn ei välttämättä ole kaikille aivan triviaalia, joskaan sen toteuttaminen PHP:n omilla funktioilla ei ole aivan kamalan hankalaakaan.
Vähintäänkin oppaan alussa (tai loppussa) olisi hyvä käydä läpi PDO:n toiminta periaatteen tasolla esimerkkien avulla.
Projekti edistyy:
Antti Laaksonen kirjoitti:
Pitäisikö opettaa SQL-kyselyjä vai jonkin hallintasovelluksen (kuten phpMyAdmin) käyttöä?
Sekä että: oppaisiin tulee kaksi liitettä tietokannan hallinnasta, joista toinen käsittelee MySQL:n komentorivityökalua ja toinen phpMyAdmin-sovellusta.
Antti Laaksonen kirjoitti:
Pitäisikö opettaa eri tapoja (perinteiset tavat, PDO) vai yksi tapa?
PDO riittää: perinteisistä tavoista saa tietoa PHP-oppaasta.
Vielä yksi kysymys: pitäisikö opettaa tallentamaan ajanhetket INT-muodossa PHP:n aikaleimana vai MySQL:n DATETIME-muodossa?
Tässä on opassarjan nykyinen suunnitelma, josta saa mielellään antaa palautetta:
Osa 1:
- sanastoa (tietokanta, taulu, kenttä, rivi, kysely)
- esimerkkitaulu (CREATE TABLE)
- tietotyypit INT, TEXT, DATETIME (?)
- kyselytyypit INSERT, SELECT, UPDATE, DELETE
- liite 1: komentorivityökalu
- liite 2: phpMyAdmin
Osa 2:
- kyselyt PHP:n kautta (PDO)
Osa 3:
- SELECT: haettavat kentät
- SELECT: ehdot (WHERE)
- SELECT: järjestely (ORDER BY)
- UPDATE + DELETE: ehdot
Osa 4:
- SELECT: DISTINCT
- SELECT: LIMIT
- SELECT: COUNT, SUM, AVG, MAX, MIN
- SELECT: GROUP BY, HAVING
Osa 5:
- lukujen laskutoimitukset (+, -, *, /)
- merkkijonojen yhdistys (CONCAT)
- funktiot (esimerkkejä)
Osa 6:
- taulujen suunnittelu
- kyselyt monesta taulusta
Osa 7:
- johdatusta: transaktiot, indeksit, viite-eheys
Itse suosittelisin tuo phpMyAdminin tilalle SqlYog-ohjelmistoa. Mielestäni helpompi/laajempi. Tästäkin olemassa freeware versio, mutta kaupallinen versio tuo mukanaan paljon extraa.
Vasta_alkaja kirjoitti:
Itse suosittelisin tuo phpMyAdminin tilalle SqlYog-ohjelmistoa. Mielestäni helpompi/laajempi. Tästäkin olemassa freeware versio, mutta kaupallinen versio tuo mukanaan paljon extraa.
PhpMyAdmin sattuu vaan olemaan huomattavasti käytetympi. En ole nimittäin toistaiseksi törmännyt mm. palvelun tarjoajaan, joka tätä SqlYoug-ohjelmistoa tukee, joten SqlYog:n käytön opettamisesta ei mielestäni olisi kauheasti iloa lukijalle. En kuitenkaan täysin teilaa ajatustä myös kyseisen ohjelmiston opettamisesta.
Antti Laaksonen kirjoitti:
Projekti edistyy:
Vielä yksi kysymys: pitäisikö opettaa tallentamaan ajanhetket INT-muodossa PHP:n aikaleimana vai MySQL:n DATETIME-muodossa?
Mielestäni kiva vaihtoehto on opettaa kaikki käyttämään tuota PHP:n aikaleimaan signed int-kenttään, niin saadaan ainakin todistettua, ettei Y2K bugeista opittu liikaa ja aikaiseksi paljon tulevia sovelluksia, jotka kosahtaa 2038 :D
Tosin eipä datetimenkaan käyttö ongelmaa poista automaattisesti - ainahan sieltä kannasta voi hakea sitä datetime -arvoa tyylillä unixtimestamp(kenttä)
Kerta tarkoitus tehdä esimerkillistä koodia ni eikö olisi järkevintä käyttää sql:n (tai mysql:n) natiiveja tietotyyppejä, kuten DATETIME. Tällä tavalla voi myös kätevästi tehdä aika-rajaukset (ehkä, taitaa onnistua myös intillä, mutta purkaltahan koko härpäke tuntuu)
Antti Laaksonen kirjoitti:
Vielä yksi kysymys: pitäisikö opettaa tallentamaan ajanhetket INT-muodossa PHP:n aikaleimana vai MySQL:n DATETIME-muodossa?
DateTimenä toki. Onnistuu sitten haut ja ryhmittelyt vaikka vuoden tai kuukauden mukaan helposti. Hauistakin tulee mielestäni selkeämpiä/luettavampia.
Komppaan kaikkia aikaisempia aikaleimatietotyyppien puolesta puhuvia, samoin argumentein.
Vasta_alkaja kirjoitti:
Itse suosittelisin tuo phpMyAdminin tilalle SqlYog-ohjelmistoa.
Tosiaan phpMyAdmin on yleensä valmiina käytössä huokeissa webhotelleissa, minkä vuoksi sitä käsitellään myös oppaissa.
Grez kirjoitti:
- -
ZcMander kirjoitti:
- -
JTS kirjoitti:
- -
tsuriga kirjoitti:
- -
Missä kaikki INT-tyypin puolustajat ovat? Mutta perustelunne ovat vakuuttavia.
Mä voin heti puolustaa int-tyyppiä. Se on oikein hyvä erilaisten määrien tallentamiseen ja soveltuu myös Id:ksi jos ollaan riittävän varmoja ettei yksilöitäviä koskaan tule yli kahta miljardia.
Grez kirjoitti:
Mä voin heti puolustaa int-tyyppiä. Se on oikein hyvä erilaisten määrien tallentamiseen.
Määrinä voi tietysti olla myös dsimaalilukuja, jolloin semanttisesti oikea tyyppi on tietysti liukuluku.
Antin tekemä rajaus oppaan eri osista kuulostaa oikein mukavalle. Osiakin tulee ihan mukavasti ja jokaiselle oppaan osalle piisaa tuota sisältöäkin ihan mukavasti.
Voisiko putkassa olla muuten erillinen opasalue, johon voisi kirjoitella oppaaseen tulevia osia ns. lennossa? Vähän siis wikityylinen rakenne, mutta "valmistumisen" jälkeen opas olisi lukossa muutoksilta. Siis ainoastaan ylläpito voisi korjailla mahdollisia typoja yms.
Joo, ajattelin lähinnä kappalemääriä. Mutta toki liukulukukin voi olla joskus hyödyllinen. Liukulukua useammin kuitenkin tulee käytettyä decimal/numeric tietotyyppiä, koska määrän tms. tietokantaan tallennettavan arvon mittaustarkkuus on yleensä tiedossa.
Teuro kirjoitti:
Voisiko putkassa olla muuten erillinen opasalue, johon voisi kirjoitella oppaaseen tulevia osia ns. lennossa?
Ohjelmointiputkassahan on erillinen oppaankirjoitusjärjestelmä, mutta koska laatu pyritään pitämään korkealla, oppaita ei voi kirjoittaa kuka tahansa. Oikeudet voi pyytää Antilta, jos jokin opas on mielessä.
Tässä on opassarjan alustava versio julkisesti arvioitavaksi:
Osa 1 - Johdanto
Osa 2 - PHP ja PDO
Osa 3 - Hakukyselyt I
Osa 4 - Hakukyselyt II
Osa 5 - Hakukyselyt III
Osa 6 - Lisäys, muutos ja poisto
Osa 7 - Tietotyypit
Osa 8 - Tietokannan suunnittelu
Osa 9 - Monta taulua
Osa 10 - Lisätietoa
Ensimmäisessä osassa mainitut liitteet puuttuvat vielä. Myös SQL-kyselyiden muotoilu on väliaikainen – miten ne kannattaisi rivittää?
Palautetta voi lähettää minulle sähköpostitse tai tähän keskusteluun. Olen kiitollinen kaikesta palautteesta oppaiden sisällöstä ja kieliasusta.
Vaikuttaa hyvältä oppaalta. Tälläistä olen tänne kaivannutkin :)
Antti Laaksonen kirjoitti:
Myös SQL-kyselyiden muotoilu on väliaikainen – miten ne kannattaisi rivittää?
Lyhyet kyselyt pitäisin yhdellä rivillä, pitkät voi rivittää ennen sanoja, jotka aloittavat uuden osuuden kyselyssä (FROM, WHERE, ORDER jne.) ja joskus myös jälkeen. Äärimmillään jokaisen asian voi laittaa omalle rivilleen, mutta ainakin rivit kannattaa katkoa loogisiksi kokonaisuuksiksi.
SELECT henkilo.nimi AS nimi, elain.nimi AS lemmikki FROM henkilo LEFT JOIN elain ON elain.henkilo_id = henkilo.id
Mahtavalta oppaalta vaikuttaa, vaikka vasta kaksi ensimmäistä osaa olen vilkaissut läpi. Yksi juttu lukemisen kannalta haittasi vähän, kun niitä ei ole linkitetty toisiinsa (1, 2, 3 jne.) Mutta, hyvä on :)
Minusta on ainakin mukava lukea pitkiä kyselyitä, jotka on rivitetty metabolixin esimerkin mukaisesti. Opas on taattua Antin käsialaa, jota on helppo lukea siitä kiitos.
PHP ja MYSQL opas 5 kirjoitti:
Seuraava kysely muuttaa markkahintaiset tuotteet eurohintaisiksi ja pyöristää hinnat kahden desimaalin tarkkuudelle:
SELECT nimi, hinta AS markka, ROUND(hinta / 5.94573, 2) AS euro FROM tuotteet;
5.94573 ei pidä paikkaansa nykyään, se on lähempänä viittä kuin tuota. Eli noin 5.0 ;)
Kyllä se ihan pitää paikkansa edelleen. Se on sitten toinen juttu minkä vuoden rahassa hinnat on.
Metabolix kirjoitti:
Lyhyet kyselyt pitäisin yhdellä rivillä, pitkät voi rivittää ennen sanoja, jotka aloittavat uuden osuuden kyselyssä (FROM, WHERE, ORDER jne.) ja joskus myös jälkeen.
Päädyin tekemään niin, että suurin osa kyselyistä on yhdellä rivillä, mutta pitkissä kyselyissä jokainen osuus on eri rivillä. Lisäksi muutamassa kohdassa myös kenttien määrittelyt ja rivien hakuehdot ovat omilla riveillään.
MIB kirjoitti:
Yksi juttu lukemisen kannalta haittasi vähän, kun niitä ei ole linkitetty toisiinsa (1, 2, 3 jne.)
Tämä johtuu siitä, että oppaita ei ole vielä julkaistu. Kun oppaat julkaistaan, opassarjan luettelo ilmestyy näkyviin.
MIB kirjoitti:
5.94573 ei pidä paikkaansa nykyään, se on lähempänä viittä kuin tuota.
Kurssi on kyllä oikein, mutta en ole tyytyväinen esimerkkiin. Jos joku tietää paremman esimerkin, jossa voi käyttää samaa taulua ja ROUND-funktiota (tai muuta matemaattista funktiota), voi ehdottaa.
Antti Laaksonen kirjoitti:
Kurssi on kyllä oikein, mutta en ole tyytyväinen esimerkkiin. Jos joku tietää paremman esimerkin, jossa voi käyttää samaa taulua ja ROUND-funktiota (tai muuta matemaattista funktiota), voi ehdottaa.
Miten olisi
<?php $kysely = " SELECT AVERAGE(hinta) AS keskiArvo, COUNT(hinta) AS maara FROM varasto WHERE kategoria = 1 GROUP BY kategoria ORDER BY keskiArvo DESC"; ?>
Teuro kirjoitti:
Miten olisi...
Tuo ei nyt käytä samaa taulua.
Metabolix kirjoitti:
Teuro kirjoitti:
Miten olisi...
Tuo ei nyt käytä samaa taulua.
Antilla ei tainnut olla tuota kategoriakenttää tosiaan tuossa taulussaan, joskin se on sinne helppo lisätä. Jättämällä kategoriakentän ja tuon ryhmittelyn pois saisi varaston keskiarvon tosin laskettua / kpl. Painotetulla ekskiarvolla tosin saisi vielä parempaa jälkeä, jolloin saisi koko varaston keskiarvon laskettua.
Noitten die-funkkareiden tilalle kannattaa laittaa vaikka joku virheviestin määritys, mallia:
<?php
try {
$yhteys = new PDO("mysql:host=localhost;dbname=testit", "antti", "abc");
} catch (PDOException $e) {
$error = 'Yhteys tietokantaan epäonnistui';
}
?>Käyttäjille ei tule tulostaa kannan virheviestejä suoraan, ja sivun suorituksen kesketyksen sijasta käyttäjälle kannattaa tarjota selkokielinen virhesivu.
Lisäksi esimerkkeihin kannattaisi lisätä XSS-estot, monet tulostavat iloisesti käyttäjien syöttämää HTML:ää.
tsuriga kirjoitti:
Käyttäjille ei tule tulostaa kannan virheviestejä suoraan, ja sivun suorituksen kesketyksen sijasta käyttäjälle kannattaa tarjota selkokielinen virhesivu.
Totta, mutta nämä eivät ole oppaan keskeisiä asioita, ja parempi on olla edes die kuin ei mitään – suuri osa foorumilla esitellyistä virheistä olisi silläkin välttynyt. Voisihan tuolta aina heitellä poikkeuksia tai käyttää trigger_error-funktiota, mutta näidenkin käyttö oppaassa vaatisi jonkinlaista lisämateriaalia.
Tosi hyvältä näytti. Tuskinpa noita asioita enää tuon selkeämmin voi esittää.
Tässä läjä pieniä sekalaisia huomioita:
01:
"Tietokannan tarkoitus"
- ehkä tähän jo konkreettinen sanallinen esimerkki siitä, minkälaisia
hakuja tietokannasta voi tehdä?
"Esimerkkitaulu"
- puhut retiisistä, mutta taulussa on peruna.
Typo:
- Taulun luonti: "mahdolliset muut määritys."
02:
"Yhdistys ja kysely" ja "Kyselyn parametrit"
- Miksi PDO:n konstruoinnin ympärillä try-catch, joka ei tee mitään oleellista?
- Ehkä kannattaisi sanoa, että kaikille vaiheille (valmistelulle, kysymysmerkeille) on syynsä, joista kerrotaan lisää [jossain], eikä niissä pidä yrittää oikoa.
"Virheen etsiminen"
- Eikö poikkeuksien teksti näy ilma try-catchaamistakin?
Vai olikohan tämä taas jostain typerästä PHP:n asetuksesta kiinni?
"Esimerkki"
- Linkkaatko siis oikeasti toimivaan esimerkkiin, jonka sisältöä kuka tahansa voi muuttaa? Epäilyttävää, vaikka tuo näyttääkin resetoivan itsensä jollain ajastimella.
- XSS, kuten täällä jo mainittiin. Siitä voisi mielestäni ainakin mainita jo tässä.
- Skriptien lopusta voisi jättää "?>" pois varsinkin header()in jälkeen.
Auttaa välttämään copy/paste -ongelmia, ja antaa jollekin ehkä
pienen "ahaa näinkin saa tehdä" -elämyksen.
05:
"Merkkijonojen käsittely"
- Itse en muista concattia ja lengthiä lukuunottamatta koskaan tarvinneeni näitä.
07:
- "kentän arvon täytyy olla yksilöivä" - saisiko selkeämmäksi? pitäisikö? vai pitäisiköhän tästä kertoa vähän enemmänkin? käyttäjänimitaulu esim.?
10:
- Ehkä pitäisi varoittaa, että tyhmä tyhmä tyhmä MySQL ei sano mitään, kun
transaktiota yrittää vahingossa käyttää MyISAM -taulun kanssa (tai muuten vain jollain niistä kymmenistä tavoista, jotka manuali kieltää. grrr).
- Transaktioiden ja viite-eheyden oleellisuutta näkisin henk. koht. mielelläni korostettavan enemmän.
Metabolix kirjoitti:
Voisihan tuolta aina heitellä poikkeuksia tai käyttää trigger_error-funktiota, mutta näidenkin käyttö oppaassa vaatisi jonkinlaista lisämateriaalia.
PDO::__construct heittää jo sen virheen, ei sitä tarvitse heittää uudelleen catch-lauseessa. Kuten yllä sanotaankin, try-catch lause on sinänsä turha. Ilman sitä koodi tulostaa kannan virheilmoituksen älykkäästi vain kehitysympäristössä (ts. silloin, kun display_errors = On). XSS:ltä suojaa esim. htmlentities-funktio.
tsuriga kirjoitti:
PDO::__constructheittää jo sen virheen, ei sitä tarvitse heittää uudelleen catch-lauseessa. Kuten yllä sanotaankin, try-catch lause on sinänsä turha.
Niinpä tosiaan heittääkin. Taitaisi olla parasta poistaa virheenkäsittely oppaan koodeista kokonaan.
Virheenkäsittely:
Oppaassa mainitaan try-catch-käsittely, koska joissakin (monissa?) webhotelleissa virheilmoitukset eivät tule näkyviin muuten ja monelle MySQL:n opettelijalle webhotelli on kehitysympäristö. Oppaan esimerkkien täytyy olla itsenäisiä, yksinkertaisia ja toimivia.
XSS:
Olette oikeassa ja harkitsen vielä asiaa. Ongelmana on, että aihe ei liity varsinaisesti tietokantaan ja sen käsittely mutkistaisi esimerkkejä.
map_ kirjoitti:
Linkkaatko siis oikeasti toimivaan esimerkkiin, jonka sisältöä kuka tahansa voi muuttaa?
Tällä hetkellä taulu nollautuu aina, kun joku painaa oppaassa olevaa linkkiä.
Kiitos muistakin kommenteistasi, otan ne huomioon oppaan viimeistelyssä.
Hmm...
<?php ini_set('display_errors', 1); // Varmistetaan, että virheet näkyvät, vaikka ne olisivat palvelimen asetuksissa laitettu näkymättömiksi. // ...
vs.
<?php
try {
// ...
} catch (PDOException $e) {
die("VIRHE: " . $e->getMessage());
}Osaako joku sanoa, toimiiko ini_set('display_errors', 1) aina ja kaikkialla?
Olisikohan XSS:stä ja SQL-injektioista sitten viisasta kirjoittaa oma "tietoturva"-kappaleensa (jonka yli ihmiset tosin voivat onnellisesti hypätä)?
ini_set voi olla valitettavasti estetty serverillä.
Virheet saa näkyviin laittamalla htaccessiin:
<IfModule mod_php.c> php_flag display_errors 1 </IfModule>
Ainakin MBnetissä toimii.
Sama ongelma, jos httpd.confiin on määritelty php_admin_value display_errors 0. Tämä lienee kuitenkin harvinaisempaa MBnetin esimerkistä päätellen. Liekö tähän mielekästä ratkaisua ollenkaan? Varmin tapa saada virheviesti näkymään on tosiaan virheviestin tulostaminen. Toteutettiinpa se sitten die-komentorakenteella tai echolla, menetelmän suora siirtäminen tuotantosivulle voi johtaa rikkinäiseen sivunkuvaukseen (sulkemattomat tagit, tulostus ennen bodya...) ja käyttäjille liian diagnostisiin virheilmoituksiin sekä tätä kautta tietoturvariskeihin. Yksi tapa olisi tietysti kirjoittaa virheviesti manuaalisesti web-rootin ulkopuolelle, mutta alkaa tuntua jo turhalta purkalta.
Kiitos oppaista, allekirjoittanutkin pänttää.
map_ kirjoitti:
Olisikohan XSS:stä ja SQL-injektioista sitten viisasta kirjoittaa oma "tietoturva"-kappaleensa (jonka yli ihmiset tosin voivat onnellisesti hypätä)?
Minunkin mielestä tuollainen erillinen alue XSS ja SQL-injektio alue olisi hyvä oppaaseen. Ainakin itse sellaista kaipaisin.
Nyt sain liitteet valmiiksi ja julkaisin opassarjan.
Jos joku kirjoittaa hyvän koodivinkin SQL-injektiosta ja XSS-aukoista, laitan oppaaseen linkin siihen.
Aihe on jo aika vanha, joten et voi enää vastata siihen.