Ma már nem írom ki minden előadásnál, hogy "címszavakban". ;)
Bèr Kessels, Roy Scholten: Enable the Community to improve usability (link) - Erik Stielstra: Contrib module Usability (link)
A szintek, melyeken egy átlagos fejlesztés végigmegy (sorrendben): felhasználói szükségletek, az oldal céljai; funkcionális specifikáció, tartalmi szükségletek; interakció tervezése, információs architektúra; felhasználói felület, navigációs felület; vizuális tervezés. A nyílt forrásból nem következik a használhatóság; a legismertebb nyílt forrású programok "klasszikus" fejlesztési modell szerint kezdték életüket (pl. Firefox, OO.o). A demokratikus fejlesztési modellben nem igazán lehet kierőszakolni a konzisztens felhasználói felületet, meg egy csomó más dolgot. Közelítsük meg a dolgot másképp: a usability expert (hogyan mondják ezt magyarul?) ne törődjön a felhasználókkal, mikor felhasználóbarát programokat szeretne, inkább törődjön a fejlesztőkkel - vagy másszóval: tegyük könnyűvé a felhasználóbarát programok készítését a fejlesztőik számára, főleg a saját területükön. A (nagyobb) linux disztribúciókról példát lehetne venni a felhasználhatóság terén. Készüljenek újrahasznosítható widgetek (megint egy szó, aminek nem tudok normális magyar megfelelőjét), mint pl. naptár.
A másik srác egyből a közepébe csapott: a felhasználóbarátságra ellenpélda a focipálya, melynek közepén egy fa áll - a legtöbb Drupal modul ilyen: van bennük egy marék ilyen jellegű hiba. A jó modul már a projekt oldalán felsorakoztatja a leglényegesebb információkat (reklám és áttekintés), aztán a README.txt (telepítési információk), a súgó (telepítés utáni elsősegély) és a kézikönyv lap (részletes leírás) következik. Projekt oldal legyen rövid (gondolj a drupalmodes.com áttekintőjére): reklám: mit, miért, mikor; stb. A telepítés sikerességéről küldj üzenetet, benne a linkkel, hogyan tovább. Ez általában az üzenetekre is vonatkozik: legyen benne infó arról, hogyan tovább. Az űrlapokon használd a legegyszerűbb módszert: engedélyezve/letiltva legördülő helyett legyen egy jelölőnégyzet. Használj rövid címkéket - az emberek nem olvasnak. A legfontosabb dolgok legyenek az űrlap tetején. A leírásnál ne ismételd a címkét, inkább a következményekről szólj. Használd a megszokott dolgokat (legyen konzisztens a felhasználói felület), valamint a kereket - ahelyett, hogy újra feltalálnád.
SherrinBull, Erich Beyrent: Hack-Proof Your Drupal App - Key Habits of Secure Drupal Coding (link)
Biztonság? Kit érdekel? Azt mindenképpen, akinek már törték fel valamijét. A betörések 75%-a nem a hálózati, hanem az applikációs rétegben érkezik - s ennek 15%-a kódolási hibák miatt. Iskolapélda: greenopolis; modulok, témák, flash és flex, stb. 92 modult használ (ohmy), ebből 20 saját fejlesztésű speciális cucc; saját sminket használ, rengeteg template-tel; flex widgeteket, melyek a services modultól kapják az adatokat; flasht az USA térképével; stb. Külsős céget bíztak meg az applikációs réteg auditálásával, akik 120 sérülékenységet leltek: XSS, CSRF, SQL inj, session fixation - ezek 90%-a a sminkben volt. Ezért a sminket aljától a tetejéig átnézték újra; az összes felhasználóktól érkező adatot felülvizsgálták ugyanúgy, mint a kimenő adatokat; stb.
Íme néhány behatolási módszer. #1: sebezhető template: egyszerű JS beszúrásával akár a teljes megjelenített oldal lecserélhető valami másra. #2: mime-type sniffing: más típusú adatot küldünk ki, mint amiről beszélünk (image/jpeg helyett akár JS-t). #3: CSRF: rávenni a böngészőt, hogy az egyik oldalba töltsön be másikból származó, akár rosszindulatú kódot - ami aztán az eredeti oldal adataihoz is hozzá tud majd férni.
Hogyan lehet védekezni? Ellenőrizz minden kimenő adatot (check_plain, check_markup, filter_xss, filter_xss_admin); védd az adatbázisod; stb. Kimenetnél használj echo check_plain($node->field);-ot echo $node->field helyett. Bejövő adatnál használd a Form API-t - ez önmagában meg kéne védjen a CSRF-től. Sose feltételezd, hogy az AJAX-os űrlapodról érkező adatok a te JS kódodtól jönnek - mindig ellenőrizd. Biztosan szívni fogsz, ha az eredményeket úgy teszed ki, ahogy vannak; ha módosítod a $_GET változót; ha paraméterezett lekérdezéseket használsz; ha módosítod a core modulokat vagy kismacskát ölsz.
Vannak elérhető segédanyagok: d.o-n; a Pro Drupal Development könyvben; az update és coder modulokban; interaktív debuggerekben (mint pl. Zend, XDebug). Űrlapról érkező adatokat mindig a hook_form_submit()ban tárolj, sose korábban, különben kiteszed magad a CSRF-nek.
A session fixation ellen tartsd titokban a session tokent - azaz mindig generáld újra, mikor egy felhasználót azonosítasz. (Ha jól értem - ez még új egy kicsit nekem.)
Ebéd, szünet
A dizájnos előadást kihagytam, bár az erre az időszakra tervezett alvás-pótlást is: végre sikerült dumálni egy jót Bálinttal.
Lenz Grimmer: MySQL Backup and Security - Best practices (link)
Az előadó volt az, aki vagy hat éven keresztül a MySQL binárisokat gyártotta; ő rakta bele SuSE-ba a MySQL-t; stb.
Biztonsági megfontolások és megoldások. Telepítés után első dolgod legyen a root jelszavának megváltoztatása; az anonymous törlése (vagy jelszavazása); a test adatbázis törlése - bár mindezt megcsinálja a mysql_secure_installation is (Unixon). Hozzáférés-ellenőrzés lépései: van-e egyezés a user táblában a username, host és password mezőre; a user, db, tables_priv és column_privs táblák ellenőrzése (bár az előadó sincs tisztában a pontos részletekkel, az viszont biztos, hogy akár azt is meg lehet adni, hogy melyik felhasználó melyik adatbázis melyik táblájának melyik mezőjéhez hogyan férjen hozzá). További biztonsági lépések: bind-address csak egy IP-re (pl. 127.0.0.1-re); skip-networking, hogy csak a helyi socketen keresztül lehessen elérni (a my.cfg fájlban); csak megadott gépekről lehessen elérni (pl. iptables segítségével); a mysql.user táblát csak a root felhasználó érhesse el; tanuld meg a SHOW GRANTS, SET PASSWORD és GRANT/REVOKE használatát; használd a phpMyAdmint vagy a MySQL Administratort a felhasználók kezelésére; ne szerkeszd magad a mysql.user táblát; a PROCESS/SUPER/FILE jogokat csökkentsd a minimális szintre; a jelszavakat ne plain-textben tárold (használd az MD5(), SHA1() függvényeket, vagy bármi más egyirányú hash-függvényt); tiltsd le a LOAD DATA LOCAL használatát a my.cfg-ben; a mysqld sose fusson rootként; paranoiások cseréljék le a 0. felhasználó nevét (root) valami másra Unixon; töröld/pucold ki a ~/.mysql_history fájlt felhasználók/jelszavak módosítása után. MySQL5-től kezdődően használhatsz view-kat arra, hogy bizonyos felhasználók csak a megadott információkhoz (táblákhoz, mezőkhöz, stb.) férjenek hozzá. A tárolt eljárások használatával akár a felhasználói/programozói hibák egy részét is ki tudod szűrni. Az operációs rendszer szintjén rejtsd el az adatbázis- és naplófájlokat mindenki elől, aki elől csak lehet - legjobb az éles adatbázis-szerverekre shell hozzáférést sem adni. Linuxon használhatsz iptables-t a szerver tűzfalazására; chroot jail-t; SELinuxot, AppArmort, Xent (lol), xVM-et, Solaris zónákat (linuxon? lol), UML-t, VMware-t, VirtualBoxot. Titkosítsd a kommunikációt: használj OpenSSL-t, SSH tunnelt, OpenVPN-t, Cipe-ot (?); titkosítsd az adatfájlok könyvtárát: cryptoloop, stb.
Biztonsági mentések: mikor van rájuk szükség; mit kell elmenteni; mikor kell ezeket végrehajtani; hol tárolod az eredményt; hogyan hajtod végre a biztonsági mentést? Szükség van rá: hardver halálakor; felhasználói/programozói hibakor (pl. "véletlen" DROP TABLE után, vagy ha a tábla-fájlokat valami szerkesztővel módosítod, pl. duplaklikk után - lol). El kell menteni az adatbázis-fájlokat (logikai vagy fizikai módszerrel) és a naplófájlokat (inkrementális backuphoz és/vagy egy konkrét állapot visszaállításához). Célszerű rendszeresen menteni olyankor, amikor nincs nagy terhelés az adatbázison; a kevéssé változó adatokat lehet ritkábban menteni. A biztonsági mentéseket lehet ugyanazon a gépen tárolni, bár ez butaság: illik legalább másik fájlrendszerre tenni - a legjobb megoldás azonban a több helyre való tükrözés. Alapértelmezés szerint az adatbázis-, napló- és állapotfájlok mind az adatkönyvtárban vannak; alapértelmezés bele van fordítva a binárisba, de meg lehet változtatni --datadir=/foo/bar/baz módon. A bináris napló minden SQL parancsot tartalmaz, ami módosítja az adatbázist, valamint ezekről további információkat (pl. futásidőt); hatékony bináris formában tárolódik; mysqlbinlog segítségével dekódolható; a --log-bin[=fájlnév] módon kapcsolható be; tranzakciókkal kompatibilis. Haszna: replikációhoz, helyreállításhoz; sose törölj bináris naplót, amire még szüksége lehet egy replikának (ugyanis a MySQL replikációja aszinkron). A mysqldump használható egyedi táblák vagy akár teljes adatbázisok mentésére; pipe-okon keresztül akár másik MySQL szerver adatokkal való feltöltésére. A visszaállítás mindig az utolsó teljes mentés és a bináris napló felhasználásával történik; a teljes mentést a mysql parancs, a bináris naplót a <code>mysqlbinlog foo-bin.000 | mysql parancs állítja vissza. A tábla fájlok mentését nevezzük fizikai mentésnek; a MyISAM adatbázisok nyugodtan másolhatók a FLUSH TABLES WITH READ LOCK; parancs után; a mysqlhotcopy Perl szkript egyszerűsíti ezt; mindez drága művelet lehet, ha a mentés sokáig tart - néha egyszerűbb/célszerűbb replikációval megoldani a mentést. Az InnoDB tábláknál az egyedüli biztonságos megoldás a szerver leállítása a mentés idejére. OSS eszközök a mentéshez: cp; tar; cpio; gzip; zip (OMG), rsync; unison; LVM snapshotok (a legjobb, bár nagy IO-t eredményez); DRDB ("RAID1 a hálózaton keresztül"); elosztott fájlrendszerek (OpenAFS, GFS, Lustre, iFolder).
Jeff Miccolis: Spaces and Context Modules, Tools for Site Building (link)
A context modul főbb jellemzői: az információkat az oldal betöltésekor adja át; a php-t az adatbázison kívül tartja; Drupal egységeknél nagyobbakban lehet gondolkodni; stb. (Kicsit késve érkeztem, az előzőt elhúzta a srác - nem teljesen tiszta, hogy mit kellene ezeknek jelenteni - talán lemaradtam néhány kezdő slide-ról?) A valódi munka a hook_nodeapi() és hook_form_alter() függvényekben történik; biztosítanak egy "nyomtatási" kontextust; az egyes kontextusokat rétegekre választja (csoport/tulajdonság/megjelenítés/...). A demóból kb. annyi derül ki, hogy ez az egész egy alternatív módja a blokkok és társaik megjelenítésére/beállítására.
A spaces modul több, mint megjelenítés: események, munkamódszer, stb. Míg az OG a tartalmakat és a felhasználókat kapcsolja össze egy "csoporttá", addig a spaces a tartalom típusokat csoportfüggően veszi át (?). A demóban olyan dolgokat tudott megoldani vele a srác, mint pl. egy menü bejegyzés más-más címkével való ellátása az elérési úttól, felhasználói csoporttól, stb. függően (pl. a bejelentkezett felhasználó "My blog" címkét lásson a "Blog" helyett).
Összességében eléggé követhetetlennek tűnt, a srác sokszor csak motyogott, de legalább folyton hadart... :S
Borkóstoló
A Vylyan - ejtsd: Villány ;) - Pincészet tavalyi boraiból kóstolhattunk egy-egy fehéret, rosét és vöröset. Ciki, hogy a nevekre nem emlékszem, de az tény, hogy igen finomak voltak. A tulajdonos megbízottja próbált beszédet mondani a borászatról, a pincészetükről, de hiába kezdte azzal, hogy neki is programozó végzettsége van, kb. 10 perc után már nem sok vizet zavart, mindenki beszélgetett újra.
A borkóstoló után elhúztuk a csíkot, lévén ma nem lenne rossz végre egy kicsit korábban lefeküdni.
Alább néhány kép.
