sslug-teknik team mailing list archive

[Troels Arvin <troels@xxxxxxxx>]

On Tue, 06 Jan 2004 13:24:49 +0100, Michael Schmidt wrote:

> Umidelbart ville jeg placere en sådan kontrol helt ude hos klienten,
> men så skal jeg først sikre mig at den kan forstå JavaScript (og hvad
> gør jeg hvis den ikke kan?).

JavaScript-kontrol kan opfattes som en usability-fremmende foranstaltning,
men er efter min mening aldrig noget, der kan stå alene. Pas i øvrigt på
ikke at overgøre det: Hvis client-side fejldetektion kræver tonsvis af
kode, så er det nok bedre at holde de ikke-trivielle fejlkontroller på
server-siden.

> Alternativt placeres kontrollen i php-laget, da der så også er
> mulighed for at se på samhørighedder mellem data, men alt dette vil jo
> ske på webserveren og hvor meget belaster den slags (i praksis næppe
> mere end 5-10 samtidige forbindelser men i teorien lang flere)

Nogle simple kontroller af input burde ikke belaste meget. Huske at
benytte "hurtige" funktioner (såsom strlen(), empty(), stristr(),
intval()), hvis de er tilstrækkelige - i modsætning til hele tiden at
benytte regular expressions (som kan være noget mere krævende at få
afviklet).

Det, der kan belaste, er ikke mht. performance, men mængden af kode til
fejlhåndtering: Hvis du opbygger en hob af PHP-kode til fejlhåndtering,
er der risiko for, at fejlhåndteringskoden i sig selv introducerer
problemer.

I PHP-laget er det førstepriorietet, at du sørger for at undgå
SQL-injection problemer og cross-site scripting huller. Hvis du ikke ved,
hvad de to begreber dækker over, så stands straks op og sørg for, at du
bliver bekendt med det.

Mht. NOT NULL-constraints, så kunne den slags ideelt set udelukkende
implementeres i databasen (således at man kun i ét af lagene håndterer
denne problematik), og PHP kunne da undersøge evt. fejlbeskeder fra
DBMSet og agere hensigtsmæssigt hvis den fx. ser, at en NOT
NULL-constraint er overtrådt. - Men i praksis gør man det desværre ofte
også i PHP, fordi databasers fejlmeddelelser er vanskelige at tolke mht.
hvad der præcist gik galt.

Jeg synes, at man må gøre det som følger:

1. Sørg for at få defineret dine databasetabeller stramt, således
   at du i videst mulige omfang kan få dit DBMS til at forhindre ugyldige
   tilstande:
   Det er oftest mere effektivt at sikre sig mod ugyldige tilstande i et
   deklarativt sprog som SQL's datadefinitions-udtryk, end at sidde og
   kode det eksplicit i PHP eller lign. Vælg bl.a. DBMS ud fra hvor
   stærkt det er på dette punkt (hint: MySQLs standard-overholdelse er
   ualmindelig dårlig på dette felt). Når man får DBMSet til at sikre
   mod ugyldige tilstande gør det også, at man bliver mindre afhængig
   af én bestemt frontend.

2. Sørg for, at din PHP-kode ikke indeholder SQL-injection og
   cross-site scripting problemer. Sørg dernæst for, at fejl fra
   databasen fanges og som _mininum_, at normal sideafvikling stopper i
   tilfælde heraf; overvej her at benytte PHP's fejlhåndteringsfeatures
   til at slippe for at skulle udøve eksplicit fejlhåndtering ved alle
   SQL-kald. Husk at udsende en HTTP status 500 eller lign. fejlstatus
   i tilfælde af fejl, således at fejl-sider ikke caches (det ser så
   grimt og pinligt ud, når en proxy viser en cache'et fejl-side).

3. Du skulle helst også have tid til at kæle lidt for fejlhåndtering
   overfor publikum: Folk skulle helst have at vide hvor i en formular, de
   har tastet galt, osv. - i stedet for blot at få en "noget gik
   galt"-side. Dette sker i PHP, og evt. også i client-side scripts.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark