ugrás a tartalomhoz

Tökéletesítés, de meddig?

Max Logan · 2009. Jún. 25. (Cs), 20.17
A minap azon gondolkodtam, hogy egy alkalmazást milyen szintig érdemes/kell bombabiztossá tenni.

Az OK, hogy szűrjük a bemenetet és ott bombabiztossá (próbáljuk) tenni a rendszert. De mi van egy olyan esettel, amikor pl. egy zárt webalkalmazás/publikus honlnap egy form SELECT elemét adatbázisból tölti fel, majd ebbe a form-ba egy adatbázisban tárolt adathalmazt tölt vissza. Itt be kell állítani a SELECT elem selected tulajdonságát (de ez van a checkbox-szal is, és a radio gombokkal is). Ami elég necces, ha valaki beletúrt az adatbáziba, azaz manuálisan írt át valamit.

A dolog saját fejlesztésű és használatú rendszernél nem jelentkezik, mert vagy nem túrunk az adatbázisba, vagy tudjuk, hogy mit csinálunk. De ha egy másnak készített rendszernél ilyen eset bekövetkezik, akkor mi van.

Persze ez nem rendeltetésszerű használat, ezért talán itt jön a license szerződések "nem rendeltetésszerű használatból eredő károkék nem vállalunk felelősséget" című része.

Ki mit gondol a dologról? Feladata-e egy rendszer tervezőjének, kivitelezőjének az ilyen jellegű hibákat levédeni (annak fényében, hogy akár különösen nagy -- akár anyagi -- kár is keletkezhet a jelenségből)?
 
1

Ne bonyolítsd...

ganyecz · 2009. Jún. 26. (P), 00.40
A minap azon gondolkodtam

elég necces, ha valaki beletúrt az adatbáziba, azaz manuálisan írt át valamit

Ilyenkor jön az, hogy minden ilyesféle, a felhasználó által módosítható adatnak megállapítasz egy alapértelmezett értéket, és amennyiben:
  1. nincs megadva más érték
  2. a megadott érték nem szerepel a választható értékek között
  3. piros hó hullik

akkor az alapértelmezett értékkel dolgozol. Illetve több időd lesz másra, mint hogy agyonbonyolítod az ellenőrzést... :)
2

adatbázisban szerintem alap

rrd · 2009. Jún. 26. (P), 13.08
adatbázisban szerintem alap dolog default value-kat adni, illetve ahol lehet foreig key-ekkel védeni a kapcsolódó adatokat. ahol lehet érdemes valamiféle védelmet építeni a véletlenszerűen elkövetett sql consolból, phpmyadminból elkövethető hibák kezelésére
3

Akkor pontosítanék

Max Logan · 2009. Jún. 26. (P), 13.16
Van egy tábla, amiben van kulcs és érték, ez a két oszlop van összesen. Van mondjuk 12 rekord a táblában.

Ezzel a táblával töltök fel egy SELECT elemet egy form-ban.

Ha valaki elbarmolja a táblában a key-t (pl. kommandózik a phpMyAdmin segítségével), akkor nem lehet minden esetben visszaállítani a form SELECT elemének SELECTED tulajdonságát. Így hiába töltöm vissza a form-ba az adatokat egy másik táblából, ha nem lesz jó a JOIN, mert nem egyeznek a kulcs mezők, ergó a SELECTED a SELECT első elemére áll.
4

További pontosítás kellene.

rrd · 2009. Jún. 27. (Szo), 09.55
További pontosítás kellene. Ha join-ról beszélsz akkor nem egy tábla van gondolom hanem kettő.

Ha jól értem akkor valami olyasmit szeretnél, hoy van egy selected pl a megyék nevével és attól függően, hogy mit választok ki egy másik selectben megjelennek a városok nevei. Ilyenkor a a városok táblában lesz egy megye_id oszlopod ami beazonosítja a kapcsolatot. Ha erre foreign key constraintot adsz meg akkor nem lehet elbarmolni a kapcsolatot phpmyadminnal se. Illetve el lehet de azért meg kell vele dolgozni :)

Ha nem jó felé tapogatóztam akkor írd meg a konkrét problémát.
5

Konkrét probléma

Max Logan · 2009. Jún. 27. (Szo), 10.22
Van egy form, mely segítségével egy autó adatait lehet rögzíteni. Az autó adatai között van pl. a kivitele. Ez egy SELECT, melynek van 12 OPTION eleme. Az option elemek az adatbázisban vannak tárolva a fent említett módon (külön tábla, kulcs és érték (szöveg) mező).

Módosításnál megjelenik a form, lekérdezem az adatbázisból az előbbi táblát, majd a kapott adatokkal feltöltöm a SELECT mezőt. Lekérdezem az autó adatlapját, majd ahol kell beállítom a SELECT-ek SELECTED tulajdonságát.

Hülyeséget írtam, mert nem itt van JOIN. Itt az a probléma, ha valaki elbarmolja a kivitelre vonatkozó információk táblájában a kulcsokat, akkor az autó adatlapjának megjelenítésénél és módosításánál nem jelenik meg, vagy hibásan jelenik meg az autó egyik adata.
6

Az más. Hülyeség ellen nincs

rrd · 2009. Jún. 27. (Szo), 10.25
Az más. Hülyeség ellen nincs orvosság. Fontos fájlokat tehetsz írásvédetté, de aki hozzáfér az le tudja törölni. Na ez is ilyen.
7

Admin felület?

Ustak · 2009. Jún. 27. (Szo), 15.19
Mondjuk valami WysWyg editor szerű dologgal és egyéb inputokkal egy adminfelületet ha csinálnál nekik? Én így szoktam, mond azt hogy ha szerkeszteni akarják az adatbázist akkor az ennyivel drágább, és használják csak azt az adminfelületet, másért nem vállalsz felelősséget.
8

A kérdés elméleti

Max Logan · 2009. Jún. 27. (Szo), 16.18
A kérdés eléméleti jellegű. Azaz én átadok egy rendszert a megrendelőnek, amibe ha hátulról beletúrnak, akkor az ő részükről akár adatvesztés is bekövetkezhet, valamint a rendszer hibásan kezd működni.

A kérdésemre rrd megadta a választ, az ilyen hátulról mellbe "támadásokat" nem lehet kivédeni. Ez már a megrendelő felelőssége.

Természetesen, ha szerkeszthetővé akarom tenni az ilyen adatokat, akkor vagy adok admin felületet, vagy magam végzem el a módosításokat, ez nem téma.