"Hackertámadás is lehetett az ügyfélkapu üzemzavara"

Nalam mar az is, h par nappal ezen esemenyek elott egy oreg bacsit akart meglincselni meg egy 30 fos etnikailag nem vitathato hovatartozasu csoport, mert rajuk mert dorrenteni h ne lopjak a fat a kertjebol. De ez mar tenyleg off-topic.

---
pontscho / fresh!mindworkz

Bár az eszkimózás nem áll távol tőlem, nem erre akart utalni a poén. Annak ellenére, hogy magam is hordozok eszkimójegyeket, sajnos számtalan ilyen esetnek részint elszenvedője, részint tanúja voltam és leszek is a jövőben. S mivel félúton vagyok az eszkimó és a nem eszkimó között így szívem szerint lennék inkább jegesmedve.

Már csak azért, mert a jegesmaci szintén szereti a hekket.

Bear in mind ;)

Akkor ne nézd meg ezt. ;)

Hát, ha valahol csak akkor tudják, hogy az ügyfél "mit láthat vajon ha belép" ha a user/pass-ával belépnek, akkor az már régen rossz :D

--
trey @ gépház

*Szerintem* időnként súlyos tesztelésnek kellene alávetni, és javítani, ahol kell, hiszen egy ilyen nagy rendszert másképpen nem lehetne fejleszteni... Ha pro-aktívan nem is, hát reaktívan mindenképpen.

--
deejayy DOT hu

Nem vagyok a fejlesztő csapat tagja, viszont tapasztalatból meg tudom mondani, hogy az ilyen fajta hibajelenségek miből kereked(het)nek.

Ugyebár amikor a fejlesztő egy modult leprogramoz, akkor ő legfeljebb modul szinten tudja azt letesztelni. (jUnit) . Akkor mondható hogy a programozó rendben letesztelte a kódját, ha a modul azt csinálja, amit a programozó elképzelt, és a hibalehetőségek is mind le vannak kezelve. Persze ez nem elég. A modult le kell tesztelni alkalmazás szinten is. Fel kell tölteni egy tesztrendszerbe, és ki kell próbálni csak azt a modult alkalmazás szinten. Ehhez össze kell állítani egy olyan teszteseteket, amelyek teljeskörűen letesztelik a modult. Vannak code coveration programok, amelyeket hozzá kell fordítani a tesztelendő modulhoz, ez pontosan megmondja, hogy pl. az egyes függvények melyik ága lett letesztelve, és melyik nem. Ez sosem lesz teljes körű, de sok hiba csak ekkor derül ki. Mivel a rendszer más rendszerekkel is kapcsolatban van, ezért a modult úgy is le kell tesztelni, hogy a tesztrendszert további elemekkel kell kiegészíteni. Ez megint problémás, de jópár hiba csak itt bukik ki. Aztán persze kell még egy teszt. Itt már a release kódot kell feltölteni egy éles előtti rendszerbe, amelyen le kell futtatni egy teljeskörű felhasználói szintű tesztet. Ennek az a célja, hogy ha a hibajavítás valamit elrontott a rendszerben, akkor azok kibukjanak. Ha ezt az utolsó lépést elhagyják, megtörténhet egy ilyen baj.

A másik dolog a verziókezelés. Mivel több lépcsős a tesztelés, ezért akár többször is szükséges új build-et csinálni. Ha ilyenkor simán a main branch legfrissebb változatát fordítják újra, akkor az ugyebár változhat, mert mások is fejlesztenek. A legegyszerűbb ilyenkor megmondani a fejlesztőknek, hogy kódzárás van, senki se tegyen be új verziót. Ilyenkor biztos lesz olyan, hogy valaki mégis beteszi, akkor az ilyen baj megtörténhet. A megoldás egyébként erre a felcímkézés. Ilyenkor a több lépéses teszt során végig nyilvánvaló, hogy melyik verzió van tesztelve, ha valaki hibázik, akkor az az utolsó tesztnél mindenképp kibukik.

Külföldről azért beszéltem, mert ott megfelelő hozzáállással és szakértelemmel állnak hozzá a fejlesztés menetének felépítéséhez, és nem egy emberre bízzák, hogy csinálja úgy, ahogy jónak látja. A problémákat szintén globális módon kezelik, és nem vetítik azt vissza a fejlesztőknek. Magyarországon sajnos az ad-hoc megoldások a jellemzőek. Vagyis a fejlesztő egy személyben majd megoldja úgy ahogy akarja.
Az önálló munkavégzés szintén baj szerintem. Külföldön én nem láttam olyan, hogy a programozó úgy dolgozik, hogy fenn van a fején a füllhallgató egész nap. Aki így dolgozik, az csak a saját kódrészét fogja látni. Külföldön sokkal nagyobb figyelmet fordítanak arra, hogy a közös interfészeket a fejlesztők közösen beszéljék meg, és lehetőleg a kódolás befejeztével nézzék át egymás kódrészeit. Magyarországon ilyet, hogy programozó más kódját olvassa, szintén nem hallottam.
A programozók életútja (gyakornok->junior->senior->vezetőprogramozó->projektvezető) Magyarországon túl nagy szerepet kap, ez szintén a mi kultúránkból adódik. Ez olyan dolgokat fog eredményezni, hogy a junior nem szólhat be a seniornak, az pedig szintén nem a vezetőprogramozónak, ha esetleg valamit nem lát jól a másik munkájában. Külföldön egy fejlesztési csapatban sokkal egyenrangúbbak az emberek. Amikor van egy projekt, akkor egyszer az egyik, máskor a másik lesz annak a projektnek a vezetője. Így mindenki egyformán fog tapasztalatot szerezni.

persze a képlet biztosan nem ilyen egyszerű. Kishazánkban egy cég úgy fejleszt, ahogy azt tőle megkövetelik.

XD

A brekking nyúzból úgyis megtudjuk.

Talán tudnod kéne, hogy Csaba eddig mennyit és milyen mélységben foglalkozott az ügyfélkapuval és annak a biztonsági dolgaival, de úgy látom, halovány sejtésed sincs róla...

nem kotekszik, adatol, es kiszamoljuk :-)

ugy is fogalmazhatok, hogy a mernoki tervezessel szemben mukodekepesebbnek tartom az evolucios kivalasztodast.

-hú, Béla... emlékszel tavaly mi vót az a bág ami miatt elvesztettük a juzerek összes adatát és a főnök is mérges lett tőle?
-ja, valami rémlik
-üjjünk le ebéd után és nézzük má meg, holnapután indul a rencer, és szopó lenne ha idén is összekeverednének az idegen kulcsok

...vagy csak én nem értem mire gondolsz evolúciós kiválasztódás alatt egy biztonság- és bizalomkritikus rendszer esetén?

Az evolúciós kiválasztódás tényleg tök jól működik több milliós variációs példányszám és többmillió rendelkezésre álló év alatt. Azt hiszem az ügyfélkapunál nem állnak rendelkezésre a szükséges források :-)

Redhack :)