Web MySQL.com byl hacknut

Kvalita LAMP aplikaci podle toho co nam sem lidi nosi je velmi velmi mala.

1. SQL injekce - velmi bezne, semtam nejake addslashes pripadne mysql_escape_strin­g. Spis ale vyjimka nez pravidlo.

2. Parametrizovany prepared statement jsem nikde nevidel

3. Nepouzivaji transakce

4. Neosetruji chybove stavy s vyjimkou mysql_connect. Ostatne k cemu osetrovat chyby kdyz pri chybe nemuzeme udelat rollback

5. Zamykani nevedou vubec

6. Referencni integrita obcas pouzita je

7. Pouziti sablon se uz docela rozmohlo. Doba echo "<h1>"; uz skoncila

8. Cela aplikace je hrozne zprasena, pouziti objektu minimalni. Vse se rve do globalnich promennych.

9. Prace se zadava jako LAMP aplikace, protoze je na to ultralevna pracovni sila. Bezne se najme tak 3x vic levnych lidi {cinani, indove, rozvojove zeme} nez je potreba a doufa se ze to alespon nekteri z nich uspesne dokonci. Ovsem stejne jako vsude tak i zde plati dostanete to za co jste si zaplatili. Pocita se ovsem s tim ze zakaznik spatnou aplikaci od dobre nepozna a tak je mu to jedno.
--
Prekvapilo mne ze crackli tohle - "grankulla".

Zase jeden chytrák, nebo trol? Já používám LAMP i .net, dobře i špatně napsané aplikace se dá narazit u .netu i lampu, nezáleží na aplikaci ale na programátorech.

Lamp levnější proto že je méně náročnější na systémové prostředky a není potřeba kupovat licence na widle. A z mého pohledu se rychleji vyvíjí v PHP s nějakým slušným frameworkem než v .net.

Chtěl jsem napsat "... nezáleží na PLATFORMĚ ale ...". ppiiiiiiiippp letní čas.

lamp je nenarocny na systemove zdroje jenom u lowend webu, kterych je vetsina. U high trafik tam jasne vede java se Spring MVC. Jednak je potreba vyrazne mene CPU a pokud soucasny pocet pripojenych uzivatelu se pocita na stovky tak to vyjde levneji i pametove nez php do apache.

Mam zalozeny tenhle odkaz

http://grails.1312388.n4.nabble.com/Symfony-2-0-vs-Grails-benchmark-td3094892.html

Grails == SpringMVC + Hibernate + Groovy.

Grails framework bych vylozene doporucil zacatecnikum. Ma hezky integrovany maven2, ivy2, tomcat6, hibernate a je pro to mnoho pluginu coz skriptari oceni. Osobne se mi libi integrace springcache kde pomoci @Anotaci staci oznacit ktere metody chceme cachovat a po kterych chceme cache smazat a mame vystarano.

Ja vim ze mate radi nette, ale to umi toho velmi velmi malo ve srovnani s opravdovym frameworkem jako Springy nebo Railsy. Grailsy muzeme pro jednoduchost povazovat za user friendly nadstavbu pro Springy kde mate porad moznost volat springy primo, kdyz potrebujete neco co grailsy specielne nezpristupnuji.

1) Pokud nějaký SQL jazyk umožňuje víc než jen "namísto X dosaďte hodnotu", tak existuje možnost injekcí. To, že je spousta lidí zapomene ošetřit je problém programátorů, nikoliv jazyka/platformy.

3) Transakce MySQL umí (byť je otázka, na jaké úrovni oproti třeba ORACLE).

4) Tohle opět záleží na programátorovi, možnosti k tomu rozhodně jsou.

8) Opět záleží na programátorovi, doporučuji se podívat třeba na Nette framework.

9) Pokud někdo chce osekat náklady, tak si najme indy na cokoliv. Pokud někdo chce kvalitní aplikaci, zaplatí renomovaným vývojářům.

Mě to přijde jako typický začátek flame "který jazyk je lepší" - neexistují lepší či horší jazyky. Existují jen jazyky, které jsou pro danou úlohu vhodnější, či které mají rychlou křivku učení, ale to nedělá žádný jazyk lepším oproti jinému.

Transakce innodb nemusi nutne zpomalovat, pokud pristupuje do tabulky vice uzivatelu soucasne tak zamykani zaznamu je lepsi nez zamykani cele tabulky jako to dela myisam. Je tedy pravda ze na zamykani zaznamu se nepotrebuji transakce. FoxPro taky umelo zamykat zaznamy a nemelo transakce. To co zpomaluje pri transakcich je flush logfilu na disk po zapisu do tabulky a checkpointy. MySQL u flush logfile podvadi (volitelne dela ho jen 1x za sekundu), coz zvedne vykon ale zase ne tak moc, protoze to flushovani logu je v mysql spatne udelane. PGSQL, ORA ci DB2 ho maji vyrazne s mensi rezii.

MySQL umi MVCC v innodb engine coz je vyborne pro pristup vice uzivatelu soucasne. Jako obvykle funcionalita je trochu zabugovana. Nevim zda mysql dela lock eskalaci, oracle ne protoze nezamyka radky v pameti ale na disku po blocich / radkach.

Navic mysql projde ACID testem u TPC-C, PostgreSQL 8.3 jim neprojde takze transakce jsou spravne implementovany. Problem je s vykonem a zabugovanosti. On ten innodb engine neni nejak specialne optimalizovany pro vykon u dlouhych transakci ma taky problemy, ale feature list ma standardni.

U PostgreSQL je úroveň SERIALIZABLE implementována příliš optimisticky - SELECT neblokuje UPDATE. Lépe se to chová při dlouhých transakcích. MySQL při SERIALIZABLE zamyká celé tabulky, což je podle novějšího chápání správně, ale je to pomalé. V 9.1 je úroveň SERIALIZABLE překopaná - bude to odpovídat tomu, co dělají ostatní databáze - což bude jednodušší pro Oraclisty, Hibernate a hlavně to projde ACID testem. Zase na druhou stranu, SERIALIZABLE bude náročnější - je to něco za něco. Problém je v různém chápání úrovně SERIALIZABLE ACID testu (zamykání a neexistence fantomů) a PostgreSQL (neexistence fantomů) - pg byl optimalizován pro slabší hw, přičemž v určitých několika málo situacích programátor musel explicitně zamykat. Od 9.1 si to o dost víc, ale programátoři nebudou muset řešit explicitní zamykání.

Tak aspoň v něčem jsme lepší než v USA :)

už jsem viděl pár perfektně napsaných aplikací i řadu slušně napsaných. I když to nebyl LAMP ale LAPP. Je to o programátorech, zaměstnavatelech a i o zákazních. SQL injection je tak hloupá chyba a lze se bránit s absolutní účinností, jen o tom programátoři neví :(. Na kurzech o SQL injection 1/3 programátorů netuší o co go.

Není to jen o LAMP. To, co jsem zažil a viděl, a i sám dělal, když jsem ještě dělal ve VB nebo v ASP byl děs. Částečně omluvou bylo, že to bylo před rokem 2000 a že nikdo nic o SQL injection nevěděl.

Na vas jsem si vzpomel. Delali jsme toto:

Migrace z 800 Oracle instanci na neco co je zadarmo.

10 uzivatelu na instanci, asi <1 GB dat na instanci. Velmi mala zatez. Jedna se o pobocku neceho kde uzaviraji smlouvy a pisi si je do databaze. Database musela podporovat inkrementalni backupy. Pres web to nechteli, boji se co by delali kdyby jim nesel net.

Zvazovalo se:
Oracle XE
PGSQL 8.3
DB2 Express C

Oracle se vyradil protoze na nej nedavaji security fixy a je omezen na 4GB dat, PGSQL se vyradil protoze zakaznik nema duvery k supportu EDB {jeste o nem neslysel zadne reference}. tak to vyhrala DB2 ke ktery si uzavreli specializovanou servisni smlouvu s IBM.

Vzpomel jsem si na vas. Kdybyjste si udelal firmu prodavajici PGSQL support (a pomoc s migraci) a poradne se zviditelnil a udelal si jmeno, coz neni tezke ja jsem to dokazal uplne od nuly, tak mi nerikejte ze byste zakazky nemel. Prezentovat umite, aktivni pristup k zivotu mate a organizacni schopnosti by se take nasly. Sice neumite myslet jako obchodnik, ale to ja neumel taky.

Ja bych vam klidne prihodil tyhle maniky a obcas se mi tu nejaka prace v PGSQL mihne - obvykle je to export/import dat a migrace. Vetsinou ORA->PG. Jsou to dobry prachy. Ja jim uctuju $3k/rok support po 2 roky. To byjste klidne moh pro mne delat, vetsina problemu co maji je stejne HW razu nebo zavirovanych widli.

Pokud se po PGSQL nechce OLAP tak ma vykon dostatecny. V OLAPu navic narazi na dementni JDBC driver, pravda MySQL ma jeste horsi JDBC driver. Jako backend pro hibernate je to dobry, jako backend pro BIRT ne, jsou tam nejak podivne delany cursory.

Tak, když nevěří supportu EDB, tak jak by mohli věřit mně? :)

Firmu mám http://www.pgsql.cz/index.php/Slu%C5%BEby nicméně support 24x7 nenabízím - to je na jednu fyzickou osobu moc. Teď jsem dva roky dělal na baráku, dva roky makal abych to nějak poplatil, a teď bych si docela rád dal dva tři měsíce dovolenou - když to bude v létě možné. Mám před sebou ještě jeden větší projekt, a ještě nemám hotový postgraduál (a na katedře už na vytahují obočí), takže se nijak do ničeho nehrnu. Beru věci, které se dají zvládnout do týdne, případně dvou tří týdnů, nebo školení. Napřed musím pohnout s postgraduálem, a pak uvidím. Možnosti tu jsou - v republice je to tak tak na uživení, ale lze se přidat k několika menším firmám, které se pg věnují a pokrývají větší prostor. Teď to ovšem neřeším, musím dodělat, to co mám - a pak se uvidí. Kontakt na mne je na http://www.pgsql.cz/index.php/Pavel_St%C4%9Bhule.

Nejdříve php.net a teď mysql.com? Kdo bude dál? apache.org?