Hirdetés
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sziku69: Szólánc.
- Brogyi: CTEK akkumulátor töltő és másolatai
- droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
- laskr99: DFI és DFI Lanparty gyűjteményem
- Magga: PLEX: multimédia az egész lakásban
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
válasz
cidalain
#17795
üzenetére
illetve az egyszerű algoritmushoz legalább az kell, hogy
- a kis képek egyformák legyenek (pixelre)
- a kis képek egyformák egy sorban és oszlopban legyenek (szintén pixelre)
- a háttér színe ismert fix legyen
így egy scan-nel megállapítható a képek mérete és elhelyezkédésepersze rádobált, nem elforgatott téglalap alakú képeknél, ahol a kép nem olvad bele a háttérbe (kép határ legalább a szélén eltér a háttértól) egysével, soronként szkennelve kiszedhetők a képek. Persze nem egy gyors megoldás.
-
válasz
Sk8erPeter
#17740
üzenetére
Egyébként nem biztos, hogy érdemes úgy keresni, hogy valaki ne csak komoly fejlesztő, hanem egyben jó rendszergazda is legyen...
Ja keresünk webfejlesztőt, aki majd üzemelteti a rendszereinket, feejlesztések közötti idejében recepciós (mert ugye az üzemeltetés csak mellékes foglalkozás, ha valami baj van), a munkaidő után pedig biztonsági őr.
mod: Ja nem is (2) - informatikust keresünk.
-
válasz
MineFox54
#17725
üzenetére
' (quote) - string
` (back quote) - field specifiertav előtt van, utána nincs
UPDATE reg SET `tav'='$tav', 'gender'='$gender', 'birthday'='$birthday', 'name'='$name', 'email'='$email', 'varos'='$varos', 'utca'='$utca', 'focinev'='$focinev', 'telefonszam'='$telefon', 'szamla'='$szamla', 'egyesulet'='$egyesulet' WHERE email='$email'
minegyik elé és utána kellene, vagy sehova se, ha nem használt foglalt nevet mezőnévhez
UPDATE reg SET `tav`='$tav', `gender`='$gender', `birthday`='$birthday', `name`='$name', `email`='$email', `varos`='$varos', `utca`='$utca', `focinev`='$focinev', `telefonszam`='$telefon', `szamla`='$szamla', `egyesulet`='$egyesulet' WHERE `email`='$email'BTW az angol és magyar mezőnevek keverése nagyon tré
Ja és remélem ellenőrzöd az inputokat! -
válasz
Peter Kiss
#17547
üzenetére
A hash titkosítás, egyirányú.
-
válasz
MineFox54
#17348
üzenetére
Arra viszont számíts, hogy nem szükségszerűen lesznek ezek az ID-k szép egymás utánban (hosszabb használkat után). Rekordok törlése után ugyanis az adott ID-t többet már nem osztja ki a rendszer - nem rendezi újra a táblát, hogy törlés után is szép sorban legyenek az ID-k.
-
-
Szvsz attól, hogy hogy tárolod a session-t kliens oldalon (cookie / url / hidden form field) még ugyanúgy el tud tűnni a session a szerver oldali tárolóból. Valószínűleg szerver oldalon maximalizálva van a nyitott session-ök száma, ha ezt eléri, akkor a legrégebbieket a rendszer akkor is törli, ha te hosszább lejárati időt definiáltál. Esetleg az lehet megoldás, ha nem szerver default session menedzsmentjét használod, hanem te kezeled a session-t adatbázisba.
-
#17200 - PeachMan
Illetve akkor kellhet, ha túloldalon HTML-be lesz beillesztve (persistent XSS-t elkerülendő) - de akkor nem sima escape kell, hanem html encode. -
válasz
supercow
#17073
üzenetére
Jó az oldal, amit linkeltél (bár több, mint két éves a cikk) - de továbbra is kitartok amellett, hogy a böngésző a leggyengébb szem a védelmi láncban. Amennyiben böngésző dekódol az egyetlen helyben tárolt kulccsal - itt az egyetlen probléma maga a böngésző - egyszerűen nincs lehetőség megfelelően "elzárni" a kulcsot, amit a kliens oldali kód használ.
Kicsit végiggondolva, akövetkezők használhatók a kulcs átadására (szerver és kliens oldal között):
1. Cookie, form fields, header fields - mindegyikkel az a gond, hogy bármelyik JS elérheti, amelyik be tud töltődni az oldal scope-ja alatt...
2. Javascript (non-global) hardcoded privát változó/konstans - ezzel az a gond, hogy cache-elődik a gépre és utólag kibányászható...
3. XHTTP Request http-only cookie-val, válasz (master password, titkosított jelszó adatbázis) privát változókba tárolva - ez talán legkevésbé kockázatos megoldás, így nem kell hardcode-olni a master hash-t és a jelszó adatbázist. az alábbi triviális támadási módok vannak ellene:
- Másik JS is tud egy XHTTP kérést küldeni és neki is elküldi a szerver a master hash-t/ jelszó adatbázist. Illetve másik JS is el tudja érni a privát változóink publikus interfészét, tudja hívogatni a metódusokat...
Digitálisan aláírt JS kikényszerítésével lehet esetleg védekezni ezek ellen.
- Böngésző JS debuggerén keresztül hozzá lehet férni a változókhoz (egyes beépülő modulok ezt is tudják kontrollálni) -
válasz
supercow
#17071
üzenetére
Én "böngészó alapon" semmilyen jelszó manager eszközt nem készítenék. De ez lehet, hogy csak a saját hülyeségem.
Adatbázisban tárolva amúgy:
1. Adatbázisból user egyedi (user regisztrációkor random generált) salt lekérése
2. user login (master) jelszóból és lekért saltból egyedi jelszó készítése
3. a tárolt jelszó (be/ki) titkosítása az egyedi jelszóvalMásik megoldás lehet a PKI (publikus/privát kulcsok) használata titkosításra, ehhez kell valamiféle PKI infrastruktúra.
-
válasz
PumpkinSeed
#16928
üzenetére
Tekintve, hogy vannak bonyolultabb dolgok is a login/reg rész megírásánál is érdemesebb lenne nem innen onnan összeollózott kódokból megcsinálni hanem magadtól írni egyet. - én inkább azt ajánlanám - amennyiben nem csak játszásiból kell, hanem publikálni is fogja (neadjisten pénzt is fizetnek érte) -, hogy ahelyett hogy maga megírná, inkább használjon egy működő login modult erre a célra.
-
válasz
honda 1993
#16926
üzenetére
-
válasz
honda 1993
#16922
üzenetére
reflected XSS hibák tömkelege
-
válasz
honda 1993
#16911
üzenetére
Azt első működő tesztverzió az utolsó verzió

-
válasz
honda 1993
#16907
üzenetére
Ráadásul az egyiket bejelentkezes-nek, a másikat registration-nek hívják...

-
válasz
Sk8erPeter
#16793
üzenetére
Nincs helyi webszerver, csak egy HTA fájl a kliensgépen.
-
válasz
Sk8erPeter
#16771
üzenetére
Nem szükségszerűen biztosítható az internetkapcsolat a gépen.
-
válasz
tothjozsi96
#16479
üzenetére
Valamint ha olyan dolgot szeretnél csinálni, ahol fontos az "egyedi" azonosítás, ott célszerű a session-t nem csak a session tickethez, hanem egyéb más tulajdonsághoz közni (pl ip cím), különben a cookie megszerzésével a belépő felhasználó más álltal megszemélyesíthető.
Kilépéskor a session változót invalidálni kell és mind kliens, mind szerver oldalon kötelezően le kell járani adott idejű inaktivitás után.Ja és akkor még szó sem esett a https-ről...
felhasználó id és md5 password tök fölösleges és veszélyes is - főleg ha nem secure cookie-ről van szó
-
válasz
Sk8erPeter
#15928
üzenetére
Igen viszont a mysqli_stmt_fetch nem array-be pakol, hanem a
táblamezőneveknek megfelelő változókba (ami szerintem legalább akkora probléma, mint az összefűzött sql string).
Prepared-nél pedig nem találtam fetch_assoc-ot, ami az elvárható lenne. Persze ott van mysqli_stmt_bind_result, de hogy még azzal is sz@rakodni kelljen - főleg nagy számú mező esetén - na erre írtam, hogy nem akrtam előröl megírni az egészet - persze így is hamut szórok a fejemre (meg átkokat a php fejlesztőire, hogy miért nem lehet konzekvensen fejleszteni). -
válasz
Sk8erPeter
#15918
üzenetére
Tudom, főtt is miatta a fejem

De hirtelen nem találtam procedurális példát, csak class alapút, és nem volt kedvem az egészet átírni osztály típusúra...
Agony: Mi lenne ha megnéznéd a példámat és megpróbálbád megérteni? Pontosan azt csinálja, amit szeretnél.
-
Pl.
$timestamp = strtotime('09:00');
echo "<table border='1'>
<tr>
<th>Sorrend</th>
<th>Indulás ideje</th>
<th>Lovas neve</th>
<th>Ló neve</th>
<th>Edző neve</th>
<th>Egyesület neve</th>
<th>Nevezés ideje</th>
<th>Versenyszám</th>
</tr>";
$counter = 1;
mysqli_set_charset($con, "utf8");
$result_vsz = mysqli_query($con,"SELECT versenyszam FROM nevezesek WHERE verseny=1 GROUP BY versenyszam);
while($row_vsz = mysqli_fetch_array($result_vsz)) {
$result = mysqli_query($con,"SELECT * FROM nevezesek WHERE verseny=1 AND versenyszam = '".$row_vsz['versenyszam']."'");
while($row = mysqli_fetch_array($result)) {
echo "<tr>";
echo "<td>" . $counter . "</td>";
echo "<td>" . date('H:i', $timestamp) . "</td>";
echo "<td>" . $row['lovas'] . "</td>";
echo "<td>" . $row['lo'] . "</td>";
echo "<td>" . $row['edzo'] . "</td>";
echo "<td>" . $row['egyesulet'] . "</td>";
echo "<td>" . $row['nevezes'] . "</td>";
echo "<td>" . $row['versenyszam'] . "</td>";
echo "</tr>";
$counter++;
$timestamp += 120; //2 perc
}
$timestamp += 1800; //30 perc
}
echo "</table>"; -
válasz
TomyLeeBoy
#15790
üzenetére
php-nál (lokális könyvtárak elérésére) ne használj http alapú fájlelérést. php hozzáfér a fájlrendszerhez, nem kell neki ilyesmi csicsa (amúgy sem úgy éred el böngészőből) - hacsak nem magán a szerveren nyitod meg az oldalt böngészőben, akkor nem a szerver lokális könyvtárára, hanem a saját géped c: és d: meghajtóira fog mutatni a link...
-
válasz
TomyLeeBoy
#15788
üzenetére
PHP miért mint weboldalt akarná megnyitni egy lokális fájlt? Vagy valamit én nézek félre?
-
válasz
csabyka666
#14789
üzenetére
Táblákat összekapcsolni adatbázis szinten FOREIGN KEY Constraint-el tudsz.
Lekérdezés szinten pedig JOIN-nal tudsz összekapcsolni táblákat.A MySQL semmit nem old meg helyetted. Mind a táblákat, mind a lekérdezéseket neked kell elkészíteni.
-
válasz
PumpkinSeed
#14601
üzenetére
Vagy miért nem a beolvasás során vizsgálod meg a karaktert? úgy nem kellene eltárolnod egy bazinagy tömbben...
-
válasz
Peter Kiss
#14552
üzenetére
Ja és kifelejtetted a rossz SQL kérés logikát: rossz jelszóval is beenged, mivel csak a felhasználónevet ellenőrzi. Ja és még ott van az SQL injection is.

-
válasz
Peter Kiss
#13447
üzenetére
Csak, hogy a topicból idézzek

-
válasz
Speeedfire
#13396
üzenetére
Feltételezem, mivel a yii lekezeli már a kivételt, így semmivel nem tudod elkapni (kivéve a belehackelsz a framework-be).
-
válasz
Lacces
#13371
üzenetére
A level++ lefele azért nem változik, mert miután átadta az értékét, utána növekszik egyel; így az egyel lejjebb levő szint is ugyanazt az értéket kapja meg. (Persze, ha jól feltételezem a level++ működését ebben az esetben - ha nem, akkor ugyanúgy működik, mint a ++level; amit azért kicsit kétlek).
++ működése általában
1)
a = 0;
b = a++; // b = 0; a = 1
c = a; // c = 12)
a = 0;
b = ++a; // b = 1; a = 1
c = a; // c = 1Counter - számláló - ahogy lerajzoltam rájöttem, hogy nem is igazi számláló, hiszen több elem kaphat ugyanolyan értéket. A probléma abban van, hogy a ++ megváltoztatja a változó értékét, és az azonos ágon levő leágazások nem ugyanazt az értéket kapják, hanem mind eggyel nagyobbat.
Branch - ág (ha fa struktúrában képzeljük el a felépített listát, akkor egy ág az, amiről bármi leágazik, és levél az, amiből már nem jön ki semmi) - a fenti ben már aszsem leírtam, hogy gondoltam... -
válasz
Vision
#13366
üzenetére
Itt az eredmény (fejből, így hibázhat) a három változatra:
szintek l++ ++l l+1
+--a 1 1 1
| +--aa 1 2 2
| | +--aaa 1 3 3
| |
| +--ab 2 3 2
|
+--b 2 2 1
| +--ba 2 3 2
| | +--baa 2 4 3
| | +--bab 2 4 3
| | +--bac 2 4 3
| |
| +--bb 3 4 2
| | +--bba 3 5 3
| |
| +--bc 4 5 2
|
+--c 3 3 1
+--ca 3 4 2
+--cb 3 4 2 -
válasz
Peter Kiss
#13363
üzenetére
Jade

Csupán csak két hszt kellett volna visszaolvasnom, hogy hogyan generálódik a struktúra
mondjuk ott el van b*va a kód, mert a rekurzív hívásnál nem jó a $level++, hanem $level+1 kell helyette. Azért nem találta a szintet, mert hülyeség volt a változóban

$feladat['sub'] = isset($feladat['sub']) ? $feladat['sub'] : GenerateArray($arr, $feladat['id'],$level++);
-
válasz
Lacces
#13360
üzenetére
Bevezetsz még egy változót, pl $depth. Amúgy az UL helye szerintem a for cikluson kívül volna:
function GenerateNavHTML($nav, $depth = 0)
{
$html = '<ul>';
foreach($nav as $f)
{
$html .= '<li>';
$html .= '<a href="' . $f['feladat_kod'] . '">' . $f['rovid_nev'] . '</a>';
$html .= GenerateNavHTML($f['sub'], $depth + 1);
$html .= '</li>';
}
$html .= '</ul>';
return $html;
}Itt ugyan a $depth változó nincs felhasználva, de azt csinálhatsz vele amit akarsz.
-
válasz
Tele von Zsinór
#12275
üzenetére
nem - úgy értettem, hogy nem statikus, hanem úgy hogy felhasználónként változó. Láttam én már olyan kódot - ami ahhoz hasonlított, amit itt valaki alant bemutatott:
pwhash = md5("valamirandomsalt".$_POST["pass"]);
Sőt olyat is láttam, hogy ugyan volt egy salt mező az adatbázis user_auth táblájában, de mind az összes rekord ugyanaz volt
De ilyenkor ugye - mivel a salt determinisztikus - simán lehet rá szivárványtáblát írni.Igazából nem is neked írom, mivel neked tiszta, hogy felhasználónként más érték legyen - de szerintem másnak nem szükségszerűen az: csak annyi a lényeg, hogy legyen salt...
-
válasz
Tele von Zsinór
#12273
üzenetére
Igen, viszont tegyük hozzá, hogy a salt is csak akkor hatékony, ha nem statikus.
-
válasz
CSorBA
#12065
üzenetére
Ez nem PHP hanem inkább javascript (azaz igazából egyik sem).
Az FQL egy HTTP GET alapú kérés, ami egy JSON formátumó stringet köp ki válaszként. Ezt elküldeni bármilyen nyelven el tudod és feldolgozni is bárhogy fel tudod.Amúgy a behivatkozott script nem működne, mivel az object_id numerikus típusú, te meg stringgel akarod megfeleltetni...
-
válasz
Sk8erPeter
#11787
üzenetére
Gondolom csak az avatarjaink miatt kevertél össze minket

-
Amit a felhasználó írhat be, az el is lesz írva... Láttam én már nagy adatbázisokat (neveket, címeket) a felhasználók (vagy akár az operátorok) által felvíve - rémálom volt. Hát ha még mezőnév is általuk definiálható, akkor kész az idegbaj. Persze nem most, majd pár száz/ezer rekord múlva

-
válasz
Peter Kiss
#11500
üzenetére
+1 a paraméterezett lekérdezésre (hátha jobban rögzül)

-
--- bad place ---
-
$object_array = array();
while ($row = $query->fetch($result_set)) {
$object_array[] = self::instantiate($row);
}
return $object_array;Ez nem az alábbinak kellene legyen?
$object_array = array();
while ($row = $result_set->fetch(PDO::FETCH_OBJ)) {
$object_array[] = $row;
}
return $object_array; -
válasz
Tele von Zsinór
#10545
üzenetére
A "salt".time() nem túl jó, inkább valami kriptografikailag megfelelő random kell: [link]
Új hozzászólás Aktív témák
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Apple iPhone 16 Pro - rutinvizsga
- Milyen billentyűzetet vegyek?
- Semmibe veszi a KRESZ-t a Tesla Mad Max módja
- A ZTE sem maradt adós csúcstelefonnal
- Eljött a vég kezdete? | Sora 2 – beszéljünk róla
- Tőzsde és gazdaság
- TCL LCD és LED TV-k
- PlayStation 5
- 5.1, 7.1 és gamer fejhallgatók
- További aktív témák...
- Vadonatúj, bontatlan iPhone 17 256GB kék KÁRTYAFÜGGETLEN! 1 év Apple garancia!
- (Használt/Used) Huawei Mate 20 Pro - 128 GB - Midnight Blue (Unlocked/Kártyafüggetlen)
- Gigabyte B450M S2H + Ryzen 5 1400 + MSI GTX 1650 Super 4GB
- "Szinte Új" iPad Pro 12.9 (3. gen) + Apple Pencil 2 + Smart Folio tok
- ASUS TUF Gaming VG34VQL3A 34" Ívelt Gamer Monitor
- Ipad Air M2 11" // Wifi+Cellular // Számla+Garancia //
- Gamer PC-Számítógép! Csere-Beszámítás! R5 3600 / GTX 1080 8GB / 32GB DDR4 / 512 SSD!
- BESZÁMÍTÁS! Asrock B450M R5 5500 16GB DDR4 512GB SSD GTX 1080 8GB Zalman T4 PLUS ADATA 600W
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő





Örülök, hogy nem csak én pofázom ilyenekről...


