Dotaz: php Prepared Statements

[Song]

Zdravim, mohol by mi nasledujuci kod prosimvas niekto prepisat, ako by to vyzeralo pri Prepared Statements? Dakujem.


$connect =mysql_Connect("$serversql","$loginsql","$serverpasssql") or
    die("Could not connect: " . mysql_error());
mysql_query("SET NAMES 'utf8'");
mysql_select_db ("$serversqldb");

$sql = "select nazov,cena from `".$_POST['nazovTabKategorie']."` where id like '".$_SESSION['kosik'][$i]['id']."'";
$result = mysql_query($sql)or die(mysql_error());
while($row = mysql_fetch_array($result)){
echo $row[0];
}

---

---

Odpovědi

[Sinuhet]

mysqli_stmt_prepare, priklad "Procedural style".

[Song]

Podobnych linkov mi na google naslo vela, keby som z nich vysiel nepisem sem. Nie je mi jasne ako dat to set 
utf, nieje mi jasne ako davat tie otazniky a bindovanie premennych, ked tam potrebujem dat tak 4, nie 1 ako je
v tych prikladoch vsade, nie je mi jasne ako potom spracovat vystup. Ak by mi niekto len jednoducho prepisal
ten priklad do prepare statement tvaru aby som pohitil princip, bol by som velmi happy. 

[jos]

a to se snažíš bindovat i from klauzuli? v tom by to mohlo bejt.

[Song]

Tak mam tasky den googlenia za sebou, najludskejsi pristup mi prisiel 
u pdo, kedze to ma pomenovatelne parametre a pre simpleminded prehladnejsie 
bindovanie, i ked si nie som isty suportom do buducna.
Spociatku som tvojmu postu vobec nechapal, ale teraz, ked som nagooglil, 
ze nieje mozne nazov tabulky alebo stlpca takto osetrovat, bol som dost 
sklamany, kedze ma to vracia spat k mysql_real_escape_string, a is_numeric
pre dane hodnoty prenasane v post, az som sa zamyslel ci ma vobec ten prepare
statement pristup pre mna neaky vyznam, kedze som chcel jednotne,ucinne,kompatibilne a 
jednoduche riesenie proti sql injection :( .

[Šangala]

Struktura se neventiluje a je pevně daná, tudíž i struktura dotazu je pevně daná, někde uložená a mění se jen 'data', takže je to přesně to co zabraňuje sql injection.
Pro běžné aplikace je dost neobvyklé skládat dotaz s proměnnými pro název tabulky či sloupce, a pokud je to nutné, tak to stejně neventilujete přes venek, ale máte na to své fce či třídu a rozhodně nepustíte z pole jako GET hodnotu do dotazu jako název tabulky či sloupce.

[Messa]

Říká ti něco SQL injection?

[Šangala]

Příloha:

• example.php (2804 bytů)

Pravděpodobně máte nevhodně navržený DB model a s ošetřením si také moc hlavu nelámete.
Podle 'kosik' si tipuji, že vlastní e-shop, no pokud někdo bude chtít, tak Vám tam nadělá psí kusy viz SQL injection.
Ale přemýšlíte správným směrem Prepared Statements řeší část problémů, jenže vy si přiděláváte další tím, že název tabulky kdesi v postu nesete.
Obecně je to pro tuto aplikaci dost nevhodné (ne-li zásadně špatně :(), název tabulky je věc struktury a tu je zbytečné vynášet někam ven. Takto to vypadá, že pro každou kategorii zboží máte zvlášť tabulku, zvažte raději možnost mít jednu tabulku zbozi a druhou kategorie což bude číselník a obě tabulky přes cizí klíč provážete.

Ale k věci.
Přikládám soubor, kde na začátku máte v komentáři 2 SQL dotazy na vytvoření tabulky a v bloku ---- setting ---- si opravte informace pro připojení a soubor normálně spusťte třeba i z terminálu php -f example.php a pak se podívejte jak je to udělané (je to upravené z vašeho zadání).
Na začátku je nějaké před-ošetření(k úpravě),
pak jsem lehce upravil Váš kód
a na závěr je to pomocí toho, co jste žádal.
PS: pro vložení názvu tabulky nelze použít funkcionalitu 'Prepared Statements' :(, a ani to není třeba.

[Song]

Z tejto problematiky mam vcelku migreny.

Co sa tyka klasickych premennych prenasanych POST na generovanie sql
1.a :  mysql_real_escape_string pre string, a is_numeric pre ciselne nodnoty
1.b : prepare statements (mysqli,pdo a ine..) 
(Šangala: dik moc za ten prepis do prepared, ak by bolo viac ? bindovalo by sa
 to predpokladam tak nejak: $stmt -> bind_param("ss", $user, $pass); ?)

A teraz k tomu zakliatemu predavaniu nazvov tabuliek/stlpcov.

Zacnime tym, ze sa to klasicky osetri mysql_real_escape_string, nasledne pouziju 
function getValidNameOfTable($tableName), function getValidId($id) , kde sa zisti
ci taka tabulka naozaj i existuje v db a ci v nej existuje polozka s danym id, cim 
sa vihne pripadnym eror hlaskam. 

Ostava tu ale ako ma neprijemne poucili, ze utocnik zmeni hodnotu nazvu tabulky v 
hidden form inpute, na nazov neakej inej, ktora skutocne existuje v danej databaze, 
a necha tym padom vykonat nasledny kod na inej tabulke ako by sa malo.

 zvažte raději možnost mít jednu tabulku zbozi a druhou 
kategorie což bude číselník a obě tabulky přes cizí klíč provážete 


Presne takto to mam.

Vzhladom na konkretnu situaciu, v get je id kategorie- co je cudzi kluc ktorym ziskam 
nazov tabulky, a nasledne na stranke vypisem produkty, v tvare formularov pre kazdy 
jeden, s hidden inputmy realneho nazvu ziskanej tabulky, a id produktu.

Urcite je na hlavu posielat takto nazvy tabuliek, ale na probleme nic nezmeni ani 
posielanie neakeho cudzieho kluca, utocnik si namiesto ziskania peknych nazvov 
tabuliek, ziska tie forgein key hodnoty (ci uz neake hash hodnoty alebo cisla) a 
bude zaskodnicky podsuvat tie, co da rovnaky vysledok, ze moj php kod bude mat 
snahu vykonat nieco na inej tabulke ako ma.

Kamarat mi poradil, ze riesenie vidi v zavedeni skupin tabuliek, nad ktorymi ma pravo 
operovat (dany php subor alebo uzivatel, a to implementovanim asi najednoduchsie do 
medzitabulky tabuliek pridelit kazdej tab hodnotu neakeho bezpecnostneho stupna/pripadne druhu), 
a kontrolovat to napr v getValidNameOfTable($tableName)

V pripade podsunutia keyid inej tabulky, ktora by bola v poli akceptovatelnych,by 
prinajhorsom viedlo, ze do kosika prida neaky plne iny produkt z inej kategorie, 
resp komplikovany psosob, ako si objednat nieco ine.


Celkovo ale taketo riesenie predavania tab names mi teraz (ano sebakritika :)) pride 
dost strasny.


Pro běžné aplikace je dost neobvyklé skládat dotaz s proměnnými pro název tabulky či 
sloupce, a pokud je to nutné.

Je to nutne, priklady tu spomenute su len stipkou, neakym sposobom prenasat nazvy 
tabuliek jednoducho musim, s tym sa neda hnut.


 tak to stejně neventilujete přes venek, ale máte na to své fce či třídu a rozhodně 
nepustíte z pole jako GET hodnotu do dotazu jako název tabulky či sloupce. 

Prooosim velmi pekne o neaky priklad takejto funkcie triedy, alebo hocakeho ineho sposobu
 ako prenasat nazov tabulky z jednej stranky na druhu, po potvrdeni formulara, bez 
toho aby to utocnik mohol menit na co chce :(


Jednou glob tabulkou by sa to riesit dalo, ale takejto mega ultra gigantickej tab som 
sa chcel vsemozne vyhnut.

[Song]

 


zvažte raději možnost mít jednu tabulku zbozi a druhou 
kategorie což bude číselník a obě tabulky přes cizí klíč provážete 


Presne takto to mam.




Horucava mi posobi na mozog, a pisem nezmysli, nemam to tak, mam sice tabulku "tabuliek" s cudzimi klucmi, ale zbozi je potom kazde v svoje tab.

[Šangala]

Příloha:

• pdf_schema.pdf (233726 bytů)

Nedávej celý příspěvek do tagu <pre></pre> - blbě se to ¡čte!…

Ad. 1.a,1.b atd.
zjednodušeně ano, to je ten základ (ještě je tam pro 32bit celá čísla fce IntVal())
Ano: $stmt->bind_param("ss", $user, $pass);.
Pro bind více vstupních parametrů to může vypadat takto:
$stmt->bind_param('sid', $string, $integer, $realnumber);

Ad. getValidNameOfTable() a getValidId()
Tím jsem chtěl naznačit že je třeba ověřit vstupní paramtery a zvláště 'getValidNameOfTable()' aby tam někdo nevložil jiný sql dotaz.
Praktický příklad:
pokud Vám tam pozměním post a pošlu v $_POST['nazovTabKategorie'] třeba toto:
grosse_catastrofe` UNION SELECT `nazov`,`cena` FROM `grosse_catastrofe.
Tak vznikne toto:
SELECT `nazov`,`cena` FROM `grosse_catastrofe` UNION SELECT `nazov`,`cena` FROM `grosse_catastrofe` WHERE text_id = '0fc3d100fa1b5c80179e1ccad8fd9497'
A to je ještě dobré, bo to nic nezničí jen vybere všechny záznamy z tabulky grosse_catastrofe
Fcí getValidId() bych jen ošetřil jestli je to například číslo daného tvaru a rozsahu atd. pokud je to text, tak je to i zbytečné, pokud se escapuje. Ošetření existence takového id (či hashe) už záleží na Vás jestli je to potřebné pro správný chod aplikace.
Aplikace by měla hlásit error jen pokud k němu opravdu dojde, otázkou je jestli je error i nesprávná vstupní hodnota…

Ad. zbozi a kategorie a tabulky
Asi není třeba se rozepisovat i s ohledem na následující Váš příspěvek.
Jen snad posílání HODNOTY cizího klíče je v pořádku, je to HODNOTA, která se váže k záznamu, to že „někdo“ mění hodnoty je v pořádku a je to už na Vás si zabezpečit, aby si nečetl kde nemá, ale aby se mohl měnit název tabulky tudíž položku STRUKTURY, je prostě divné…
A cizí klíč do tabulky-číselníku nemá nic společného s rojem tabulek pro tutéž věc či-li zboží. V tomto ohledu je tabulka třída a záznamy její instance, a proč vytvářet různé třídy pro stejné instance.

Ad „Kamarat mi poradil“
To je otázka řízení přístupu, a s diskutovanou podstatou struktury to má pramálo společné.

Ad. „Prooosim velmi pekne o neaky priklad takejto funkcie triedy“
Nepochopení - pro Váš způsob datového modelu nemám pochopení - sorry :(.
Myslel jsem tím například. máme různé tabulky-číselníky, které obsahují sloupce id,name,description a pro základní operace si napíšeme univerzální dotazy, kde si třeba název tabulky dáme jako svoji proměnou a před-generujeme si dotaz.
např. SELECT `%mytable%id_pk` AS id,`name` FROM `%mytable%` WHERE `%mytable%id_pk` = ? Pak jen předem TOU fcí či třídou vyměníme %mytable% za název konkrétní tabulky a a stačí nám jedna třída, funkce, či abstraktní předek k manipulaci s jednou skupinou tabulek, včetně i jednotného administračního ksichtu. Je to samozřejmě jen usnadnění a název tabulky neneseme ven, ale pevně ho někde před-nastavíme.
Z formuláře lze měnit jen požadavek na data, ne strukturu, a pokud mají mít data rozdílný přístup, tak vyřešit další app. logikou, či nástroji MySQL.

Ad. „Jednou glob tabulkou…“
Nevím co znamená „mega ultra gigantickej tab“ jestli z velkým množstvím řádků tak vězte, že pro tento typ databází je obvykle ideální úzká a dlouhá, nejlépe s pevnou šířkou tabulka.

Neměla by ta struktura vypadat nějak takto viz příloha.

[blondak]

tuhle jsem řešil dynamické SQL v stored procedurách, chtěl jsem použít prepared statements (PS) nad "dynamickým názvem tabulky", ale jednoduše to nešlo, takže neznám úplne pěsně PDO, ale pokud to "překládá" na PREPARE pro mysql, tak to ani přes PS nepůjde. nicméně by to šlo udělat napůl nějak takto

$sth = $dbh->prepare('select nazov,cena from `'.$_POST['nazovTabKategorie'].'` where id like ?');
$sth->execute(array($_SESSION['kosik'][$i]['id']));
$red = $sth->fetchAll();

ale pozor na SQL injection u toho $_POST['nazovTabKategorie']

[jos]

stačí si tu magickou formulku "prepared statement" přeložit

v principu de o to, že si databáze vyrobí prováděcí plán pro ten dotaz (a čertvícoještě) a ten je pak parametrizovanej přibindovanejma parametrama

tudíž je nesmysl chtít po databázi, aby si připravila prováděcí plán dotazu kde chybí from klauzule

btw ještě mi vrtá hlavou, proč vůbec Song použil "where id like ...", to je taky děsná kravina, patří tam rovnítko

[blondak]

Nad tím like jsem se také pozastavil, ale proti gustu ..., jinak prepared statement lze použít pro dynamické SQL, občas to používám ve stored procedurách

SET @sql_command := CONCAT('SELECT * FROM ',neco,.....);
PREPARE stmt_command FROM @sql_command;
EXECUTE stmt_command;
DEALLOCATE stmt_command;

[jos]

a to tam ten dotaz nejde pustit rovnou?

možná se pletu, ale prepared statements se hodí v situacích, kdy chci stejnej dotaz provést víckrát s různejma parametrama, pak to v db ušetří trochu času

pokud si připravim statement a použiju ho jen jednou, tak sem akorát napsal dva zbytečný řádky kódu

[Šangala]

Ale třeba pokud to děláte vždy, nebo není něco (mezivrstva), která to hlídá, máte duši v péří, že máte escapovane string-y apod. a, že jste na něco nezapomněl. :)

[blondak]

bohužel, pokud se mění název tabulky, tak nee.

[Šangala]

Jasně, na to je si třeba vždy dát pozor.
Skládané dotazy jsou bohužel někdy nevyhnutelné, eliminovat je a dávat si na ně obzvlášť pozor.
PS: Neobhajuji 'Prepared Statements' vždy a všude, ale pokud nemám mezivrstvu, která mi zajistí, že vše je escapované, zauvozovkované a ošetřené, tak to může být právě ta náhrada mezivrstvy i pro jednoduché jednou použité dotazy.

[jos]

já myslel spíš něco přímočarýho jako:

EXECUTE CONCAT('SELECT * FROM ',neco,.....)

v tom zkonkatenovaným stringu už se mi asi název tabulky nezmění

[Song]

Re: Šangala

Cize, ak som spravne pochopil. Posielat nazvy tabuliek cez post je uplne zle. Vsade de tak mam, prepisat a preposielat len forgein key a skript si nazov tabulky(klasicky osetrenym dotazom) zisti z medzitabulky tabuliek sam, takto potom netreba ziskany nazov tabulky validovat a na vsetko postacuje prepared statement(osetrit len co sa pristupovych prav tyka v pripade zamenenia fk).

pro Váš způsob datového modelu nemám pochopení - sorry :(.

Neni problem, kritika je na mieste :) .

Ono tie tabulky niesu uplne rovnake, administrator webshopu si vytvara kategorie produktou sam, cim si vytvara i dane tabulky, pre kazdu jednu bud vybera z mnoziny predefinovanych alebo vytvara vlastne definicie/atributy , pricom kazdy jeden atribut prida danej kategorii/tabulke svoj stlpec, cize niektore tabulky sa mozu zhodovat uplne, niektore viac menej, a niektore mozu byt uplne ine, co sa stlpcov tyka .

[Messa]

Přílohy:

• test.sql.gz (8615 bytů)
• pdf_schema.pdf (251359 bytů)
• sqlqueries.txt (2220 bytů)

Podle mně je „zle“, že uživatel tvoří strukturu :(.
Klasická záležitost, zboží se liší některými volitelnými parametry, ale to lze řešit lehce přes nepovinné parametry.
Přikládám tady:

• SQL dotaz (export z PHP admin-a) databáze `test` s tabulkami InnoDB.
• pdf dokument ze strukturou
• soubor z sql dotazy

Pokud si tu DB stvoříte (obsahuje malá data) a zkusíte si ty SQL dotazy a zamyslíte se, tak by jste měl pochopit jak to myslím s těmi volitelnými parametry.
Lze to dále rozvíjet (zvláště 'enum').
Tabulka r_categorytemplateitem, může být chápána spíše jako seznam parametrů kategorie a na základě ní lze hezky i generovat hledací dialogy pro kategorii zadávací dialogy apod. Tabulka categorytemplate se může jevit jako zbytečná a může dojít k její vypuštění a r_categorytemplateitem provázat přímo s c_category. Přijde na to jestli volitelné parametry mají být povinné či ne atd. K jednotkám je vhodné ještě doplnit 'htmlunits' bo zápis 'm²' v html vypadá třeba jako 'm²' a to se blbě transformuje.
Pokud jsem takové věci řešil, tak ještě přibyl roj dalších tabulek, jako tabulka (tvrdý číselník - běžně nemodifikovatelný) zvlášť na skupiny jednotky a jednotky (délková míra: cm,0.01; dm,0.1; m,1;) atd., takže pak osoba co definuje kategorie vše vybírá.

Myšlenku Vám nenutím, protože pokud se neztotožníte s principem, budeme v budoucnu sprostě nadávat, je to náročnější na základní SQL dotazy a základní kameny aplikace, ale výhoda se dostaví při vytváření ksichtů, pro administraci či search dialogů apod. bo se to pak slušně generuje a například pro zadání zboží je jen jedna PHP stránka a je putna co to je za typ zboží a kolik má parametrů jakých typů atd.

[Song]

Šangala : Dik za podrobne a obsiahle odpovede, malo kde na forach sa najdu ludia co si daju tolko prace s radami, a dik i vsetkym ostatnym zucastnenym, mozte oznacit topik ako solved :_)

[Šangala]

Rádo se stalo, drze označím jako řešení můj předchozí příspěvek s ukázkou požadovaného kódu :)

[Song]

takže neznám úplne pěsně PDO, ale pokud to "překládá" na PREPARE pro mysql

Takto nejak :

/*** prepare the SQL statement ***/ $stmt = $dbh->prepare("SELECT * FROM animals WHERE animal_id = :animal_id AND animal_name = :animal_name");

/*** bind the paramaters ***/ $stmt->bindParam(':animal_id', $animal_id, PDO::PARAM_INT); $stmt->bindParam(':animal_name', $animal_name, PDO::PARAM_STR, 5);

/*** execute the prepared statement ***/ $stmt->execute();

J validovat table/column name nevie ziaden, ale to asi len pre nase dobro xD .