par sql injection

[labaiss]

:D

 

un tagad mans iesācēja jautājums&rezumējums:

 

PDO vs MySQLi

Šīs abas lietas dara vienu un to pašu, bet MySQli paredzēts tieši tikai MySQl DB, bet PDO var lietot arī ar Citām DB.

Bet PDO lietot īsti nav jēgas, jo mainās kvērija specifika un ja mainīsim DB, tad tā pat nāksies, iespējams, mainīt kvēriju - un tad galā sanāk, ka lietot PDO īsti jēgas nav.

 

To es sapratu!

Labojiet, ja kļūdos! :)

Edited December 23, 2010 by labaiss

[mefisto]

Vispār ir viena fīča ko PDO dara tādi, kas nav uz mysqli : fetch_object()

Uz mysqli tas atgriež tikai stdClass, bet PDO implementācijā tu vari nodot savas veidotās klases nosaukumu kā parametru.

 

Un es nezinu kā citi, bet es tomēr labak izmantoju elastīgāko risinājumu, kurš ļauj man neuztraukties , vai mans wrapperis strādās ar citam DB vai nē.

[codez]

http://php.net/manual/en/mysqli-result.fetch-object.php

 

object mysqli_result::fetch_object ([ string $class_name [, array $params ]] )

 

...

 

class_name

 

The name of the class to instantiate, set the properties of and return. If not specified, a stdClass object is returned.

 

Edited December 23, 2010 by codez

[mefisto]

Hmm ... sapisos meistarībā.

[codez]

Par PDO vs MySQL manas domas: PDO ir veerts lietot, ja izmanto arii kaadu ORM + piemeeram Active Record un pats manuaali nekaadus specifiskus kveerijus nedrukaa. Tad kveeriji, visticamaak, buus deriigi ne-tikai prieksh, piemeeram, MySQL un paarsleegties uz citu DB buus viegli

Manuprāt tieši ORM ir tā vieta, kur parasti tiek izmantoti RDBMS specifiski kveriji, jo, lai ORM efektīvi un pareizi strādātu, tai pašā Mysql ir vajadzīgs izmantot Row Locking-u, kura sintakse ir RDBMS specifiska.

 

Piemēram,

 

$u=User('id=5'); //SELECT, kurš jāizpilda ar FOR UPDATE beigās, lai nolokotu rowu un līdz rowa updeitam, nekas netiku izmainīts
echo $u['username'];
$u['points']+=10;
$u->save(); //UPDATE

[mefisto]

ar query'a veidošanu iekš ORM'iem parasti nodarbojas atsevišķa klase/es, kurai nav nekā kopīga ar DB pieslēguma veidošanu.

[codez]

Nu jā, bet mēs atgriežamies pie tā paša jautājuma, kāda jēga izmantot konekcijas abstrakciju, ja tālāk aplikācijā kveriji tik un tā būs specifiski kādai konkrētai RDBMS un tātad visa aplikācija būs specifiska kādai RDBMS un konekciju abstrakcija izrādīsies vienkārši lieks abstrakcijas slānis aplikācijā.

[mefisto]

Pirmkārt, neaizmirsti ka šitāda izvēle ir tikai attiecībā uz MySQLi.

 

Tad vēl ir tāds sīkums, kā projekti kuros vajag strādāt ar vairāk kā vienu DB.

Lielākā daļak koderu lietot wrapperus priekš DB konekcijām, un tad rodas situācija,

ka tu nevari izmantot vienu un to pašu wrapperi diviem piespēgumiem.

( un jā , ja tavs wrapperis var nodrošināt tikai vienu connectionu , tad you are doing it wrong® )

[codez]

Ja pameklētu, tad citām RDBMS (ne tikai mysql) arī varētu atrast specifisku kveriju sintaksi, tādā veidā aplikācija būtu RDBMS specifiska un konekcijas abstrakcija lieka.

 

Manuprāt, labāks risinājums tik un tā ir, ja wraperis ir RDBMS specifisks, tas viņu padara ļoti vienkāršu un ātrdarbīgu. Un, ja gadījumā būs aplikācija, kurai vajadzēs strādāt ar 2 dažādām RDBMS, tad var izmantot 2 dāžādus wraperus, katrai RDBMS savu.

Bet galvenokārt, šādi projekti (ar vairākam RDBMS) ir ļoti specifiski un salīdzinoši reti sastopami un neatiecas uz diskusijas būtību.

Edited December 23, 2010 by codez

[mefisto]

Tad tieši kā tu izveido prepared statement šajos gadījumos ?

http://php.net/manual/en/book.ifx.php

http://www.php.net/manual/en/book.pgsql.php

http://www.php.net/manual/en/book.mssql.php

[codez]

Priekš kam ir vajadzīgs prepeared statement, ja var vienkārši uzrakstīt kveriju un parametrus nodot kā, piemēram, masīvu

 

Ar ko prepared statement labāks par šo (vienkāršu db wrapera query funkciju, kuru ar sprintf un mysql_query, mssql_query, utt. var izveidot dažās rindiņās)?

 

$res=$somedb->query('SELECT * FROM articles WHERE authorid=%id$s and tagid=%tagid$s',
      array(
       'id'=>$someauthorid,
       'tagid'=>$sometagid
    ));

[mefisto]

LOL

 

Varbūt palasi, kas ir prepared statement. Tas nav nekāds str_replace().

[briedis]

Es izmantoju tādu php orm layerīti - RebBean

Tur līdzi padod parametrus kvērijam, nav jāsatraucas par eskeipošanu:

$entries = R::getAll("users", "1 AND user_id = ?, user_mail = ?", array($user_id, $user_mail));

Edited December 23, 2010 by briedis

[codez]

Es zinu, kas ir prepeared statement un nekur neapgalvoju, ka tas ir str_replace().

Tas, ko es jautāju, ir - Kāds reāls labums ir no prepeared statement?

Prepeared statement nedod nekādu abstrakcijas vienkāršojumu un parasti statement ir daudz ātrdarbīgāki.

[mefisto]

Nē, tu nezini, kas ir prepared statements (turpmak: PS), jo tad tu tādas stulbības nerakstītu.

 

Tā ir metoda ar ko iekš SQL ir iespējams atdalīt pieprasījumu loģiku no datiem.

Kad tu php pusē izveido PS, tas tiek aizūtīts serverim , un pēc tam sūtīti tiek tikai dati.

 

Pirmkār tas dabīgā veidā veic aizsardzību pret SQL injekcijām.

Un PS darboja tik pat ātri vai ātrāk kā parasti query'i.