Az observer minta 2. rész

Bejegyzés dátuma:
2010-12-15
Az Observer minta az SPL felhasználásával
 
Az előző részben szereplő példa túl elméleti volt és csak a könnyebb érthetőség miatt választottam. Ezen kívül nézzünk meg egy konkrétabb példát, aminek több haszna is van. A programozónak az egyik legfontosabb célja, hogy a kialakított program moduljai, komponensei között minimális legyen a kapcsolat. Az egyik résznek a módosítása ne befolyásolja a másik program rész működését. Ha mégis szükség van módosításokra, akkor könnyen beazonosíthatónak és kijavíthatónak kell lennie az egyes részeknek úgy, hogy a lehető legkisebbre csökkentsük a hibalehetőségeket. Idegen szóval tudomásom szerint ezt nevezik a programozásban ortogonolitásnak. Ez csupán elméleti kérdés, hiszen egy rendszerben a részek összefüggésben vannak egymással de törekednünk kell a lehető legkisebb és minimálisabb részek kapcsolatára vagy másképp fogalmazva feleslegesen ne bonyolítsuk a dolgokat.

Tételezzük fel, hogy van egy valamilyen rendszerünk és azt akarjuk, hogy a felhasználók hozzáférjenek, be tudjanak lépni. Valójában nem azt akarjuk, hogy belépjen, hanem adott tartalmakat szeretnénk mások elől teljesen elrejteni, illetve szabályozni, hogy ki férjen hozzá. A sikertelen belépéseket pedig meg szeretnénk jegyezni és az állapotukat jelezni szeretnénk.  Ha lejárt az adott hozzáférés azt is tudatni szeretnénk. A sikertelen belépéseket logfájlban(ip, dátum, felhasznáói név) gyűjtjük vagy küldünk róla email értesítést. A megvalósításhoz az Observer mintát, a PHP5 -öt, a Standard PHP Library-t, a MySql adatbázist  és a DooPhp keretrendszert, a diagramok elkészítéséhez pedig a GNU/Linux rendszer alatt elérhető Dia programot fogom felhasználni. Az adatbázis szerkezet megjelenítéséhez és az adatmodell elkészítéséhez és a tábla kialakításához pedig a MySQLWorkbenchet.

A példa megvalósításához kapcsolódó kérdések:

1. Mikor sikeres és sikertelen egy belépés?

Sikeres, ha a felhasználó a regisztráció során a megadott felhasználói neve és jelszava megfelel a helyi jelszó házirend követelményeinek. A helyi jelszó házirend kialakítása mindenhol eltérő. Erre vonatkozó ajánlás persze létezik. Például:

- legyen legalább 8 karakter hosszú

- tartalmazzon legalább 1 kisbetűt - tartalmazzon legalább 1 nagybetűt - tartalmazzon legalább 1 számot - legyen a jelszónak lejárata

A jelszó tárolása kódolt formában történik az adatbázisban. A regisztráció megvalósítása a példámban nem szerepel, feltételezem, hogy ez már működik.

 

2. Mikor jár le egy hozzáférés?

A jelszó jelen példámban a létrehozástól számítva 30 nap múlva lejár. Erre a következő belépés során figyelmeztetést is küldünk. A belépést ilyenkor engedélyezzük de csak 1x, legközelebb már nem tud belépni, mert lejárt az adott jelszó. Ilyenkor lehetőség van a módosításra. Amennyiben 3 -nál több sikertelen belépési kísérletet kezdeményeztek, kitiltjuk az adott felhasználót 4 órára és erről értesítést küldünk neki email -ben.

3. A belépéssel kapcsolatos biztonsági kérdések

Nem tartozik a minta megvalósításához és a példám jelenleg csak egy illusztráció, nem teljes értékű de mégis kitérek a biztonsági kérdésre, mert fontos figyelembe vennünk. Mindenképp tanácsos a https megvalósítása, mert így az adatok egy védett csatornán utaznak. Egy SSL illetve TLS kapcsolatról van szó a HTTP protokoll-t felhasználva, ami a 80-as port helyett a 443-as portot használja. Ahhoz, hogy a webszerverünk ilyen kéréseket fogadni tudjon egy tanusítványt (nyilvános kulcs) kell megvásárolnunk egy adott időszakra, amit egy hatóságnak igazolnia kell. Ezt a feladatot magyaroszágon a netlock végzi. Ez a session azonosító ellopása(Session id Hijacking) ellen is kellő védelmet nyújt. A session azonosító kitalálása ellen pedig a keretrendszerben megvalósított session kezelés véd. Ugyancsak a keretrendszerben található megvalósítás véd az SQL injection és XSS jellegű támadásokkal szemben is. A brute force jellegű támadásokat a session id megfelelő kezelésével, illetve a jelszó próbálgatások kitiltásával lehet elérni. Célszerű lenne a bejelentkező formban egy rejtett mezőben egy véletlenszerű hash értéket generálni, amivel megbizonyosodhatunk arról, hogy a kérés onnan érkezett. A másik jellemző támadás a session fixation, amikor a már sikeresen belépett session azonosítót használja fel a támadó és lép be a felhasználó nevében. A sikeres belépés után tehát egy új munkamenet azonosítót kell generálnunk. A biztonságot növelhetjük, ha lehetőséget adunk a felhasználónak a kilépésre, illetve automatikusan legyen kiléptetve x idő elteltével, ami a session információk teljes törlésével is jár. Természetesen a session információk lejárata előtt erről informáljuk a felhasználót és megkérjük, hogy újból azonosítsa magát, közben pedig az éppen aktuálisan végzett munkáját lementjük a munkamenet változóba, és azonosítás után pedig visszatöltjük. A biztonságot tovább növelhetjük, ha hálózati szinten csak az adott ip címről engedjük a gépeket belépni. A konkrét megvalósítás az adott feladat mértékétől és az elvárt biztonsági szinttől függ.

A következő részben azonosítom az osztályokat és meghatározom a feladatkörüket, felhasználva az UML osztály és szekvenciadiagramot.