Hozzászólások
-
SzerzőBejegyzés
-
Gentoo-t mindennaposan, a Debian-t (Woody forever!) meg mikor hol (rossz kijelzőjű laptop, régi P1-es gép, vmware stb), játékszerként…
nem lehet, hogy beállítottál valami unoffical rsync mirror-t, ami egy ideje nem frissül?
hmm… a Gentoo portage-je szerint a 2.4-r4 a legfrisebb stabil glibc x86-os architektúrán…
Gentoo alatt vannak eszközök (pl gentoolkit) a csomagkezelőjéhez. Ezek közül az equery az egyik leghasznosabb, amivel el lehet ezt végezni. `equery d csomagneve`. Igaz, csak kilistázza, és utána kézzel kell beírni, hogy mit szedsz le, de hasznos dolog. (illetve biztos van hozzá valami kis „egysoros”, ami automatikusan elvégzi helyetted)
nálam semmi sem segfaultol, csak nagyon ritkán az amaroK, esetleg a kopete… de szerintem semmi köze nincsen hozzá. A no-ntpl flaget meg nem használom ^^
Code:diamond ~ # emerge -pv sys-libs/glibcThese are the packages that would be merged, in order:
Calculating dependencies… done!
[ebuild R ] sys-libs/glibc-2.4-r4 USE=”nls nptl nptlonly profile -build -glibc-compat20 -glibc-omitfp -hardened (-multilib) (-selinux)” 15,711 kBNekem az nptlonly flaggel régóta jól megy a gentoo…
Nálam egy 4.5 éves Maxtor 40GB van, tökéletesen működik, és egy 160GB Samsung, ami 1-1.5 év körül van. A Samsungra sok a garancia, és nagyon halk, ráadásul nem túl melegedős fajta.
Wait wrote:Rosszul mondtam… a sessionnek UID-et tartalmaznia kell 🙂Így ha nem létezik az $_SESSION[UID], akkor nem tudsz semmit sem csinálni, mert csak a beléptető szkript hozza létre, így csak akkor létezhet, ha az ember be van jelentkezve, viszont ha te átírod a cookie-dat, és megpróbálsz bemenni…
nem, ez nem jó 🙂
Valahogy az IP-t kéne folyamatosan tárolni, ha a felhasználó IP-je nem egyezik az adatbázisban belépésnél frissült IP-vel, akkor törli a session-t. Így már jó? 🙂
A SID-et eltárolja automatikusan a php egy cookie-ban, így azzal neked nem kell foglalkoznod.
A $_SESSION egy nagyon hasznos tömb, mivel olyan, mintha egy $HOME könyvtár lenne, csak itt változókat tárolsz fájlok helyett. A multilogin kikerülésére ezt használd ki. (ha nem érthető, akkor még segítek, de nem akarom leírni az én megoldásomat, hanem inkább gondolkozásra akarlak bírni).Más: több oldalon jelenik meg, hogy az MD5 nem jó, mivel pl egy 20 karakteres jelszónak tuti van olyan párja, ami jóval kevesebb karakter, de ugyanaz a hash-e. A php másik digest algoritmusa a sha1, ami jobb, de az sem tökéletes. Ezért én javasolom a kettő együttes alkalmazását.
Wait wrote:Adott egy lap (mondhatnánk portálnak is), ahol vannak felhasználók. Azt kell kiviteleznem, hogy senki se tudjon belemászni a másik accountjába, és többen se tudjanak egy accountról bejelentkezni egy időben.A következő megoldás jutott eszembe: kiküldök egy cookie-t, benne egy UID, ezzel az UID-del azonosítok egy sessiont, aminek igazából mindegy az értéke, a lényeg, hogy létezzen. De amikor belépsz, egy adat frissül az egyik táblában, 1-es értéket vesz fel. Itt jön bele az, hogy ne tudjanak többen belépni egyszerre: ha az azonosító, amikor belépsz, alapvetően már 1, akkor törli a sessiont és visszaállítja az azonosítót 0-ára. Így tudnám azt megoldani, hogy többen ne tudjanak belépni. Bár ez a módszer kidobja az eredeti bejelentkezettet, de pl. a beragadások ellen eléggé jól véd 🙂
Szerintetek mennyire jó módszer?
Jó, akkor én meg regelek, belépek, a cookie-ban átírom az UID-et, és hoppá, admin vagyok ^^
A megoldás (ha esetleg valakinek hiányozna):
Code:emerge -uO1av libpq libpqxx postgresql && etc-update -
SzerzőBejegyzés