Az observer minta 2. rész

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.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter


A bejegyzés kategóriája:Tervezési minták and tagged . Vedd fel a kedvencek közé: link. Szólj hozzá vagy hagyj egy trackback-et:Trackback URL.

Szólj hozzá

Hozzászólás küldéséhez Be kell jelentkezni