- Fujifilm X
- Hobby elektronika
- AI-ra, játékra, mindenre kiváló lehet a Gigabyte új PC-je
- HiFi műszaki szemmel - sztereó hangrendszerek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- OLED TV topic
- 3D nyomtatás
- Milyen notebookot vegyek?
- Kormányok / autós szimulátorok topikja
- Milyen cserélhető objektíves gépet?
Új hozzászólás Aktív témák
-
#16600
tothjozsi96
addikt
Peter Kiss
#16599
tothjozsi96
addikt
válasz
Peter Kiss
#16599
üzenetére
Értem, de én úgy értem a header-t jelen esetben hogy van egy saját függvényem amit meghívok minden php elején és abban van a <html><head> satöbbi rész
Most már okés, beírtam abba a php-ba amit mindenhol meghívok és így már jó!
thx!
-
#16599
Peter Kiss
őstag
tothjozsi96
#16598
Peter Kiss
őstag
válasz
tothjozsi96
#16598
üzenetére
Ez nem header, hanem egy HTML meta tag: <meta charset="utf-8">
Ha a feldolgozás előtt (még mielőtt bármi történne az alkalmazásban) meghívod ezt, akkor nem lesz gond:
header('Content-Type: text/html; charset=utf-8');Ezzel tényleg HTTP header-t küldesz ki.
-
#16598
tothjozsi96
addikt
tothjozsi96
addikt
Egy kérdésem lenne.
Az a lényeg hogy a hiba üzeneteket csak die()-al szeretném megoldani, nem szeretnék olyant hogy behívja a header-t is meg minden egyebet, csak a die simán ...Na most, az a baj hogyha nem látja az oldal a header-ben lévő <meta charset="utf-8">-at akkor pedig már karakter hibás lesz.
A php fájlokat UTF-8 BOM nélküliben írom, nem tudom hogy tudnám megoldani.
De a header-t nem szeretném megjeleníteni (tehát fejléc, kinézet, stb.). -
#16596
DNReNTi
őstag
tothjozsi96
#16594
DNReNTi
őstag
válasz
tothjozsi96
#16594
üzenetére
Mint ahogy már előttem Zedz leírta, minden mezőt ellenőrizni kell szerver oldalon.
"Szerintem ez így célszerűbb, mert ha valaki inject-el, akkor itt már elbukik, vélemény?"
Mán úgy érted SQL Injection? Prepared Statements?(#16593) CSorBA
Remélem.
Olyan jól fogalmaz. -
#16595
Zedz
addikt
tothjozsi96
#16594
Zedz
addikt
válasz
tothjozsi96
#16594
üzenetére
Minden beviteli mezőt védj le. Lehetőleg kliens oldalon is, a szerver szerintem kötelező.
-
#16594
tothjozsi96
addikt
tothjozsi96
addikt
Ti szoktátok vizsgálni a POST-ból származó adatokat akkor is hogyha egy felhasználó belép, vagy csak akkor hogyha regisztrál?
Elgondolkodtam rajta, lehet hogy jobb szűrni az engedélyezett karaktereket, például csak angol abc és 0-9-ig számok lehetnek benne.
Szerintem ez így célszerűbb, mert ha valaki inject-el, akkor itt már elbukik, vélemény?
-
#16593
CSorBA
őstag
PumpkinSeed
#16592
CSorBA
őstag
válasz
PumpkinSeed
#16592
üzenetére
Vagy egy minimum 5000 szavas esszét fogalmaz épp
-
#16590
DNReNTi
őstag
Peter Kiss
#16584
DNReNTi
őstag
válasz
Peter Kiss
#16584
üzenetére
Kábé ezt szerettem volna írni
-
#16589
honda 1993
senior tag
Zedz
#16588
-
#16588
Zedz
addikt
honda 1993
#16583
Zedz
addikt
válasz
honda 1993
#16583
üzenetére
Úgy néz ki a dolog, hogy gondolom fent van egy XAMPP a gépeden. Feltehetőleg indítottál rajta egy Apache webszervert és egy MySQL adatbázist. Nekünk most a második a fontos. Amit megtaláltál phpmyadmin kezelőfelületet, az grafikusan segít elérni a MySQL adatbázist. Kapaszkodj meg, akár a windows command ablakban is el tudnád érni a MySQL adatbázisod!
Localhoston alapból root a felhasználónév, és nincs jelszó. De például ha bérelsz majd webszervert, akkor ott le fogják írni, hogy milyen módon tudod elérni a saját phpmyadminod, ahol pl. tudsz új adatbázist létrehozni az oldalad mögé.
-
#16587
tothjozsi96
addikt
honda 1993
#16586
tothjozsi96
addikt
válasz
honda 1993
#16586
üzenetére
Figyeljéé má, és akkor mi az SQL???
-
#16586
honda 1993
senior tag
Peter Kiss
#16584
honda 1993
senior tag
válasz
Peter Kiss
#16584
üzenetére
Koszi koszi
cubix ahha, hat akkor nekem valami kimaradt, mert sehol nem adtam meg egyetlen jelszot sem. ( de vegul is mindegy, mert mukodik minden) koszi
-
#16585
cubix
tag
honda 1993
#16583
cubix
tag
válasz
honda 1993
#16583
üzenetére
NIncs, mert a phpmyadmint mikor telepíted meg kell adod az admin jelszavát.
-
#16584
Peter Kiss
őstag
honda 1993
#16583
Peter Kiss
őstag
válasz
honda 1993
#16583
üzenetére
Jesus f.ck.ng Christ. Amolyan Matthew McConaughey hanglejtéssel.
-
#16583
honda 1993
senior tag
honda 1993
senior tag
Jolvanna.
Egy dolgot meg hadd kerdezzek meg.
Most tanulmanyozom a phpmyadmin oldalat ( localhost/phpmyadmin) parancsal ertem el.
es furcsallom hogy nem kell regisztralni, ( hozzateszem nincs is "regisztracio") menupont.
Szoval regisztracio nelkul is letre lehet hozni az adatbazist, es ahogy elnezem minden mast is meg lehet csinalni.Tehat a kerdesem hogy van -e valami hivatalos oldaluk, ahova erdemes regisztralni a biztonsag kedveert.
-
#16582
Zedz
addikt
honda 1993
#16581
Zedz
addikt
válasz
honda 1993
#16581
üzenetére
Úgy fejlődnél a legtöbbet, ha a folyamatos feladás helyett inkább keresnéd a megoldást, próbálgatnád, és ha sikerül megcsinálni egy adott feladatot, akkor megérteni, hogy miért is működött a kód. Ha végképp elakadsz, akkor persze segítenek az itteniek, de a MySQL-es húzás például erős volt.
-
#16581
honda 1993
senior tag
PumpkinSeed
#16580
honda 1993
senior tag
válasz
PumpkinSeed
#16580
üzenetére
Abban amit mondasz, van valami igazsag.
-
#16580
PumpkinSeed
addikt
honda 1993
#16577
PumpkinSeed
addikt
válasz
honda 1993
#16577
üzenetére
Nekem csak annyi kérdésem lenne, hogy a böngésződben nincs olyan modul beépítve (gyárilag minden böngészőben van), hogy egy hatalmas piros hullámos vonallal aláhúzza úgy kb az egész mondatod?
Szerintem amúgy nem fektetsz elég időt a problémák kiküszöbölésére (én is itt tanultam meg). Ajánlatos egy pár órát végig szenvedni, hogy te találd meg a hibáidat, és ne egyből segítségért szaladni. Ilyenkor olyan dolgokat is megtanulhatsz amikre nem is számítanál. PHP manapság aligha létezik MySQL nélkül szóval ajánlatos nekifeküdni annak is és egy olyan könyvből/blogról/stb. tanulni ezt ami együtt tanítja őket.
(#16579) DNReNTi
Szerintem elég rossz megoldás lenne ez mert tfh. van 100.000 felhasználom. Ameddig a .txt állományban tárolt felhasználónév jelszó és mindezek egymás alatt a Ctrl+F-el kereshető ezzel szemben a te módszered.... Szerencséd, hogy odaírtad..... -
-
#16578
DS39
nagyúr
honda 1993
#16577
DS39
nagyúr
válasz
honda 1993
#16577
üzenetére
hát ott van/lesz tárolva. viszont előtte lokálisan kell megcsinálni, a wampserverben pl., majd azt csak be kell importálni a webtárhely adatbázis-kezelőjébe.
-
#16577
honda 1993
senior tag
Sk8erPeter
#16574
honda 1993
senior tag
válasz
Sk8erPeter
#16574
üzenetére
Na igen, sorry a hibakert es azert is hogy hulyen fogalmaztam meg a kerdesemet.
De nem aludtam mar meglehetosen regen, es elegge faradt vagyok.DS39 igen en is gondoltam, csak en ugy kepzeltem el hogy ez is a weblap tarhelyen van tÁrolva.
DNReNTi szinten koszi.
-
#16576
DS39
nagyúr
honda 1993
#16573
DS39
nagyúr
válasz
honda 1993
#16573
üzenetére
de mivel nem vagy képben? ha logikusan végiggondolod a folyamatot, nem írsz ilyet. mondom ezt programozási ismereteket figyelmen kívül hagyva, ugyanis tök mindegy milyen nyelven írod php, java, asp.net, a login részt, ha nincs adatbázis ahonnan lekérdezd a felhasználók adatait egy bejelentkezéshez, akkor mit ellenőrzöl ha beírja, az e-mail címét, és egy jelszót?
egy átlag user is tudja, gondolja, hogy ha facebookra regisztrál, az vhol tárolva van, és ha bejelentkezik, és kiírja hogy elírta a jelszót, akkor azt vhogy, vhonnan ellenőrzi a rendszer.egyébként én egy regisztrációs folyamattal kezdeném, mert amíg ez nincs csak előre "gyártott" felhasználók tudnak bejelentkezni az oldaladra.
-
#16575
DNReNTi
őstag
honda 1993
#16571
DNReNTi
őstag
válasz
honda 1993
#16571
üzenetére
"szugseg lehet Mysql-re is"
Igen, ez elképzelhető. Annyival kiegészíteném, hogy nem lehet, hanem 100%, hogy szükséged lesz valamilyen adatbázisra (pl mysql). Egyébként igen, megírod, feltöltöd, megy. Ennyi.
Szerk: lemaradtam megin'.
(#16574) Sk8erPeter
-
#16574
Sk8erPeter
nagyúr
honda 1993
#16571
Sk8erPeter
nagyúr
válasz
honda 1993
#16571
üzenetére
"szugsegem lesz -e meg masra", "megirom az ehez szugseges kodot", "szugseg lehet Mysql-re is, (en pedig azt sem tudom hogy az pontosan mi is lehet)"
Ne szívassál már, először még jóindulatúan azt hittem, csak elgépelés volt a "szugseg" (még leírni is nehézkes ezt a szart, szóval elgépelés kilőve), akkor megpróbálom a fejedbe verni, szóval így a helyes: SZÜKSÉG. K-val, érted?! NEM G-vel!! Az "ehhez" pedig KÉT DARAB H! Hogy akarod megtanulni a PHP nyelvet, ha még a saját anyanyelvedet sem ismered?
Az meg már a szinte kommentálhatatlan kategória, hogy fogalmad sincs, mi az a MySQL. Mégis mi a lóf@szra való a Google?
Asszem tényleg abba kéne hagyni a topic követését, mert ez már szánalmas, hogy hol tartunk. De még egy rohadt kérdést sem képesek mostanában megfogalmazni értelmesen az emberek, hogy mégis mi a frászt akarnak tudni. Most már bennem is eltört valami. -
#16572
DS39
nagyúr
honda 1993
#16571
DS39
nagyúr
válasz
honda 1993
#16571
üzenetére
1. szükség
2. adatbázis nélkül sokra mész egy login folyamatnál..
-
#16571
honda 1993
senior tag
honda 1993
senior tag
Hali.
Ujra itt vagyok XD.
Egy ideje tanulgatom a php nyelvet is, es lassan majd szeretnek hozzafogni a login megirasahoz.
Az lenne a kerdesem hogy egy mukodokepes login kod megirasahoz szugsegem lesz -e meg masra is, vagy tenyleg "csak" annyibol all hogy megirom az ehez szugseges kodot, es az oldalammal egyutt feltoltom a web tarhelyre?
Pl en hallottam valahol olyat is hogy szugseg lehet Mysql-re is, (en pedig azt sem tudom hogy az pontosan mi is lehet).
Szoval sajnos egy kicsit ossze vagyok zavarodva, es azt szeretnem megtudni hogy ha kesz van a weboldalam, es a logint is sikerul majd megirnom php segitsegevel, akkor az egeszet csak siman fel kell toltenem, vagy lesz- e meg valami mas dolgom is mielott utjara engedem.
-
martonx
veterán
Nem, a legjobb ha az ember inkább nem is olvassa a PHP topikot (hiszen a való életben valóban találkozik ilyen esetekkel
ne higgyétek, hogy egy rakás PHP programozó, aki ugyan nem ír ide, egy pindurit is magasabb szinten van az itt kérdezőktől ), és csak akkor jön ide olvasni, amikor privátban megkapja az aktuális új gyöngyszemet -
#16569
fordfairlane
veterán
PumpkinSeed
#16567
fordfairlane
veterán
válasz
PumpkinSeed
#16567
üzenetére
Pedig én ezt jól bírom, de most valami eltört bennem.
-
#16568
Sk8erPeter
nagyúr
PumpkinSeed
#16567
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16567
üzenetére
Mostanában kb. hasonló szinten tartunk a topicban ezekkel a "kimásoltam Notepad++-ba, és úgy láttam, milyen hosszú a karaktersorozat"-jellegű megnyilvánulásokkal.
-
#16567
PumpkinSeed
addikt
fordfairlane
#16564
PumpkinSeed
addikt
válasz
fordfairlane
#16564
üzenetére
FB-n volt egy PHP csoport ahova beléptem és 1 hónap után kiléptem mert más se ment mint a változók kiíratásainál fellépő problémák "echo '$valami'; miért nem megy?".
-
#16566
Sk8erPeter
nagyúr
Peter Kiss
#16565
Sk8erPeter
nagyúr
válasz
Peter Kiss
#16565
üzenetére
Jól hangzik.
-
#16565
Peter Kiss
őstag
fordfairlane
#16564
Peter Kiss
őstag
válasz
fordfairlane
#16564
üzenetére
Csoportos öngyilkosság? PH! találkozó keretein belül.
-
#16564
fordfairlane
veterán
fordfairlane
veterán
Ha a PHP topik ilyen szinten marad a továbbikban, öngyi leszek.
-
#16563
tothjozsi96
addikt
Sk8erPeter
#16562
tothjozsi96
addikt
válasz
Sk8erPeter
#16562
üzenetére
Hallottam, de valahogy előbb jutott eszembe ez mint az strlen.
-
#16562
Sk8erPeter
nagyúr
tothjozsi96
#16561
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16561
üzenetére
"Kiírattam a takelogin-ban és nyomtam egy CTRL+A-t, és beraktam egy Notepad++-ba ami kiírja hogy hány chars pontosan."
Atyaég... stringhossz-visszaadó függvényekről hallottál már? -
#16561
tothjozsi96
addikt
Sk8erPeter
#16560
tothjozsi96
addikt
válasz
Sk8erPeter
#16560
üzenetére
Kiírattam a takelogin-ban és nyomtam egy CTRL+A-t, és beraktam egy Notepad++-ba ami kiírja hogy hány chars pontosan.
Utána megnéztem a password_verifiy-vel is, biztos ami biztos és mivel false lett így.
-
#16560
Sk8erPeter
nagyúr
tothjozsi96
#16559
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16559
üzenetére
Jó, és mivel ellenőrizted, hogy valóban 63 karakter lett?
Mikor lett annyi, adatbázisba való feltöltés után, vagy még az alkalmazás "szintjén"? Az a baj, hogy csomószor harapófogóval kell kiszedni belőled az érdemi, nem mellébeszélő infókat, még sokszor így sem sikerül, és így az embernek csomószor elmegy a kedve a segítéstől. -
#16559
tothjozsi96
addikt
Sk8erPeter
#16558
tothjozsi96
addikt
válasz
Sk8erPeter
#16558
üzenetére
Azért írtam bele hogy $_POST["password"] mert a password_hash valahogy 63 karakter lett, a 60 helyet!!!
És ezért próbáltam meg a POST-al nem pedig az $password-al, remélem világos hogy miért az van ott.
-
#16558
Sk8erPeter
nagyúr
tothjozsi96
#16556
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16556
üzenetére
"Így írtam bele.
echo password_hash($_POST["password"], PASSWORD_DEFAULT);
Alapból így van megadva amúgy:
$password = !empty($_POST["password"]) ? $_POST["password"] : '';
Azt hittem hogy valami baja lesz az empty-vel, de nem ..."
Már kapásból ennek a pár sorodnak sincs értelme. Ellenőrzöd a kulcs meglétét, átadod a tömbben ezalatt található értéket egy változónak, csak azt a változót ($password) nem használod fel a password_hash()-nél... ezért mondom, hogy ember legyen a talpán, aki érti a gondolatmenetedet. ![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyébként meg nyilván ellenőrizni kell egy kulcs/változó meglétét, mielőtt felhasználod, nem tudom, mit kell csodálkozni az Undefined index-szel kapcsolatos Notice-on. -
#16557
PumpkinSeed
addikt
mrpiko
#16554
-
#16556
tothjozsi96
addikt
Sk8erPeter
#16555
tothjozsi96
addikt
válasz
Sk8erPeter
#16555
üzenetére
Igazából egy regisztrációhoz kell, de a Wamp meg folyton Undefined Index-ezik, ezért van rajta az !empty ...
Egy tök alap regisztráció.
Csak az a baj hogy valamiért a 60 karakter helyett 63 lett, de most megnézem egy rendes linux alatt ... -
#16555
Sk8erPeter
nagyúr
tothjozsi96
#16552
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16552
üzenetére
"Nem tudom mi folyik itt."
Igazából ebből a leírásodból ember legyen a talpán, aki megérti, miről beszélsz, hogyan is tesztelted, úgyhogy mi sem tudjuk, mi folyik nálad. ==========================
(#16554) mrpiko :
Egy ilyen igénytelenül összeb@szott "álláshirdetésre" ne várd, hogy értelmes ember jelentkezzen. Nem túl jó ómen, ha még egy becsábító üzenet megfogalmazásába sem vagy hajlandó fektetni 30 másodpercnél többet, és még egy vesszőt sem vagy képes használni a tagmondataid elválasztásához. -
mrpiko
újonc
Szaisztok php programozot keresek majdnem késsz oldalhoz olyan ermberke vegyen fel facera vagy skypera aki ért hozzá és van szabad ideje torrent oldalhoz keresek fejlesztőt ha van ilyen irjon skypen vagy facebookon itt nem mindig vagyok fent elöre is köszönöm további részleteket skype vagy face az
skype: nanonet5
face: https://www.facebook.com/profile.php?id=100007324275230
-
#16553
PumpkinSeed
addikt
tothjozsi96
#16552
PumpkinSeed
addikt
válasz
tothjozsi96
#16552
üzenetére
Simple Text a legbiztonságosabb.
-
#16552
tothjozsi96
addikt
PumpkinSeed
#16551
tothjozsi96
addikt
válasz
PumpkinSeed
#16551
üzenetére
Amúgy érdekes, mert most utána néztem, és most ezt tartják biztonságosnak, már nem nagyon terjesztik az md5-ös belépő rendszereket cookie-val ...
Amikor én kezdtem még régen akkor az volt a favorit, igaz hogy nem webshop és fórum oldalakkal foglalkozom.Mellesleg most megnéztem és most jó a password_hash().
Nem tudom mi folyik itt.
-
#16551
PumpkinSeed
addikt
tothjozsi96
#16543
PumpkinSeed
addikt
válasz
tothjozsi96
#16543
üzenetére
Mintha itt találtam volna egy leírást arról, hogy nem nagyon szabad így megoldani. Viszont hash+besózás egy jó megoldás szerintem, vagy legalábbis amiket én eddig olvastam.
Majd a user által megadott jelszót is ugyanezzel a módszerrel és megnézed, hogy a user által megadott és a db-ben lévő változat egyezik-e, ha igen akkor kap egy kekszet a felhasználó.
-
#16550
tothjozsi96
addikt
tothjozsi96
addikt
Itt azt írják hogy max. 60 karakter.
Na most, nekem 63.
Egy egyszerű regisztrációba kellene.
Így írtam bele.
echo password_hash($_POST["password"], PASSWORD_DEFAULT);Alapból így van megadva amúgy:
$password = !empty($_POST["password"]) ? $_POST["password"] : '';Azt hittem hogy valami baja lesz az empty-vel, de nem ...
De ha simán beírom valahova hogy
echo password_hash("valami123", PASSWORD_DEFAULT);
akkor az 60 karakter lesz.
WTF? -
#16549
DNReNTi
őstag
Sk8erPeter
#16534
DNReNTi
őstag
válasz
Sk8erPeter
#16534
üzenetére
Miután má' leírtam nekem is eszembe jutott.
-
#16548
tothjozsi96
addikt
Peter Kiss
#16547
tothjozsi96
addikt
válasz
Peter Kiss
#16547
üzenetére
Akkor úgy tároljam hogy VARCHAR(60)-al?
Akkor nem teszek rá semmit ha úgy biztonságos. -
#16547
Peter Kiss
őstag
tothjozsi96
#16545
Peter Kiss
őstag
válasz
tothjozsi96
#16545
üzenetére
Elmondom, hogy a dupla hash csak kárt okoz, erre megint ráküldene egy MD5-öt.
@biker
"password_hash() is simple crypt() wrapper" -
#16546
biker
nagyúr
tothjozsi96
#16545
biker
nagyúr
válasz
tothjozsi96
#16545
üzenetére
crypt() + salt, vagy password_hash() ?
-
#16545
tothjozsi96
addikt
Peter Kiss
#16544
tothjozsi96
addikt
válasz
Peter Kiss
#16544
üzenetére
Váóó.
Elsőre tényleg sokkal jobbnak tűnik mint egy md5(sha1()) kombó.Ez jól néz ki, kérdés hogy miben érdemes tárolni SQL-ben.
Mivel látom ez folyton más értékeket generál, de úgy látom akkor is VALID marad ha akár melyik értéket ellenőrzöm ezzel a password_verify()-vel.Erre érdemes MD5-öt tenni az SQL tároláshoz?
Úgy nézem hogy mindig 60 karakter lesz az értéke ... -
#16544
Peter Kiss
őstag
tothjozsi96
#16543
Peter Kiss
őstag
válasz
tothjozsi96
#16543
üzenetére
Ez nem titkosítás, hanem hash-elés.
Azzal, hogy ráküldöd az sha1-re még az md5-öt, sikerült csökkentened a lehetséges jelszóvariánsok számát brute force esetén.
Megoldás: PHP Manual > Function Reference > Cryptography Extensions > Password Hashing
(password_compat, ha kellene)
-
#16543
tothjozsi96
addikt
Peter Kiss
#16542
tothjozsi96
addikt
válasz
Peter Kiss
#16542
üzenetére
Igen, ez igaz.
Főleg hogyha nem a tied a szerver gép hanem mondjuk csak tárhelyet bérelsz ...
Úgy nem igazán fogsz tűzfalon keresztül bannolni senkit.Egyéb:
Szerintetek miben érdemes tárolni a felhasználók jelszavát?
Eddig úgy tároltam hogy md5(sha1($username.$password);Nem tudom hogy lehet biztonságosabb.
Láttam olyan megoldásokat is hogy két külön oszlopba van tárolva egy random érték meg a jelszavad titkosítva és akkor a kettő együtt md5-el ha egyezik akkor belépsz ...Most én ilyesmi féle megoldást nem szeretnék.
Igazából amit tárolni szeretnék az az "username", "hash" ami uniqid lesz és még a "passhash"-t.És nem tudom miben lenne érdemes titkosítani a jelszót.
-
#16542
Peter Kiss
őstag
tothjozsi96
#16541
Peter Kiss
őstag
válasz
tothjozsi96
#16541
üzenetére
Nem kell logolni semmit. In memory intéződik minden, tiltani meg tűzfalból kell hosszútávon.
-
#16541
tothjozsi96
addikt
Peter Kiss
#16540
tothjozsi96
addikt
válasz
Peter Kiss
#16540
üzenetére
Igen, csak mondjuk az se a legjobb megoldás hogyha a sok logolás lassítja meg a szervert ...
Több ezer felhasználó közül kiakar szúrni az ember 1 felhasználót aki nyomja a ddos-t, hát az úgy elég meredek megoldás.Azért akarom ezeket kivédeni.
Mert egy die() nem fogja leterhelni a szervert.
Azért is kérdeztem hogy szerintetek jó megoldás-e ez a rejtett input?Amúgy azt felesleges szerintem vizsgálni hogy POST-e a bejövő adat, olyant már láttam ddos-olni.
De az uniqid-t ezzel ellentétben nem tudja ellopni elvileg, mivel a <form> nem egy lapon van a feldolgozó résszel. -
#16540
Peter Kiss
őstag
Peter Kiss
őstag
Szóval flood ellen úgy lehetne értelmesen védekezni, ha user host address mellé jegyeznénk memóriában az utolsó kérést, és amennyiben ez túl közeli (túl sűrűn kértek adatokat), nem adunk vissza semmit.
-
#16539
tothjozsi96
addikt
Peter Kiss
#16538
tothjozsi96
addikt
válasz
Peter Kiss
#16538
üzenetére
Szerintem sokkal jobb megoldás ha külön van egy input és mindenki kap egy uniqid-t.
Mivel ha nem egyezik a session a post-al akkor sose fog tudni belépni. -
#16538
Peter Kiss
őstag
PumpkinSeed
#16536
Peter Kiss
őstag
válasz
PumpkinSeed
#16536
üzenetére
És a sessionben való tárolás már magával hozhat adatbázis-műveletet is.
-
#16537
Zedz
addikt
tothjozsi96
#16533
Zedz
addikt
válasz
tothjozsi96
#16533
üzenetére
De a végrehajtott fájlt is le kell kérni nem?
Tehát ott is a szerver válaszolgat... -
#16536
PumpkinSeed
addikt
tothjozsi96
#16528
PumpkinSeed
addikt
válasz
tothjozsi96
#16528
üzenetére
Én ezt talán úgy fogalmaznám át, hogy aki egyszer próbálkozott az kap egy ID-t session-ben vagy cookie-ban tárolva és az bizonyos ideig nem csinálhat semmit. Értem ezalatt a regisztrációt. Adsz neki 3 próbálkozási lehetőséget majd ha annyira béna, hogy ezután se tud regelni akkor lehet robot lesz, és ekkor megkínálod 2 perc tiltással, mely minden sikertelen cselekedet után hatványozódik.
-
#16535
wis
tag
tothjozsi96
#16533
válasz
tothjozsi96
#16533
üzenetére
Egy robot mindenre képes lehet amire egy böngésző is
-
#16533
tothjozsi96
addikt
Zedz
#16531
tothjozsi96
addikt
De a DDos-t inkább szerver felőli oldalról érdemes megközelíteni szerintem.
Mivel ha túl sok az egyidejű lekérdezés, meg túl nagy adatok érkeznek meg mittudjaménmik
Akkor értelemszerűen bann jár érte.(#16532) DNReNTi
Az se rossz elképzelés, de szerintem az uniqid-t nehezebb megszerezni, lehet hogy egy robot képes arra hogy szimulálja a postot. -
#16532
DNReNTi
őstag
tothjozsi96
#16530
DNReNTi
őstag
válasz
tothjozsi96
#16530
üzenetére
Szerintem egyszerűbb megnézni a végrehajtóban, hogy a http request post e. Ha nem az, viszlát.
-
#16531
Zedz
addikt
tothjozsi96
#16530
Zedz
addikt
válasz
tothjozsi96
#16530
üzenetére
Itt nem csak azzal van a baj, hogy 1 fájlt támadnak. Hanem a folyamatos lekérés a szervertől. Pl. ddos támadást ismered?
-
#16529
DNReNTi
őstag
tothjozsi96
#16528
DNReNTi
őstag
válasz
tothjozsi96
#16528
üzenetére
És ez miért is akadályozna meg bárkit abban, hogy szétterhelje az oldalt? A robot is megkapja a uniqid()-t.
-
#16528
tothjozsi96
addikt
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy ti mivel védenétek ki egy robot támadást?
Mondjuk valaki úgy akarja leterhelni az Apache-ot hogy elkezdi a bejelentkezést terhelni, persze random adatokkal és több helyről indít egy robotot.Gondolkodtam kicsit és szerintem egy jó megoldásra jöttem rá.
Az a lényeg hogy lenne egy rejtett input, abban benne lenne egy uniqid() és ez el lenne mentve SESSION-ban, és ezt vizsgálnám a végrehajtó php-ban, és ha nincs érték akkor elutasítanám és nem is jutna el odáig hogy adatbázisból lekérje hogy egyáltalán létezik-e a felhasználó.
Vélemény? -
#16527
Sk8erPeter
nagyúr
PumpkinSeed
#16526
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#16526
üzenetére
Jól mondod. Ez a kód szerintem az utóbbi idők összes példaként linkelt kódját felülmúlja ocsmányságban.
Megkapja a PHP topic Arany Málna díját. -
#16526
PumpkinSeed
addikt
peterfihugo
#16522
PumpkinSeed
addikt
válasz
peterfihugo
#16522
üzenetére
Szvsz ezt a kódot még én se használnám, pedig én kezdő fejjel elég sok hibát szoktam véteni.
De a lényeget megragadva, és nem a kérdésedre válaszolva, szerintem ez már kicsit idejét múlta kódrészlet, mert mysql_query-ket használ, már ebből is látszódik, hogy nem ajánlatos a használata.
-
#16524
wis
tag
peterfihugo
#16522
válasz
peterfihugo
#16522
üzenetére
Ezek a részek okoznak átirányítást:
<script>window.location.href='<?=DEVELOP_URL?>/admin/?menu=slider';</script>(#16523) Zedz
Ezt inkább már kukázni kéne -
#16523
Zedz
addikt
peterfihugo
#16522
Zedz
addikt
válasz
peterfihugo
#16522
üzenetére
Édes istenem, ezt te átlátod?
Nem bántásból mondom, de szerintem nagyon gyorsan el kellene kezdened rendszerezni a kódod. -
#16522
peterfihugo
csendes tag
peterfihugo
csendes tag
[link]
A fenti linken található kódsorból valaki mondja már meg hogy mi a hiba .... mert nem tudok rájönni... amint ez a php-t beinclude-olom az admin felületemen, akkor olyan, mintha folyton elkezdené újratöltögetni az oldalt.... és nem bírok rájönni miért... már lehet h fáradt vagyok... -
#16521
DNReNTi
őstag
tothjozsi96
#16520
DNReNTi
őstag
válasz
tothjozsi96
#16520
üzenetére
De most ha mondjuk 0.1 másodpercenként van egy üzenőfali bejegyzés, ami lássuk be elég aktív oldal lehet, akkor naponta, 864.000 db bejegyzés keletkezik. Legyen 1 millió, hogy könnyű legyen számolni. Ez az INT-et 4290 nap alatt, azaz majdnem 12 év alatt meríti ki, ilyen extrém használat mellett.
Wtf? -
#16519
DNReNTi
őstag
tothjozsi96
#16518
DNReNTi
őstag
válasz
tothjozsi96
#16518
üzenetére
"Láttam olyan oldalt ahol problémát okozott már az INT(10) is."
Az 4.2+ milliárd rekord. Milyen oldal lehet az ahol ez problémát okoz? igyelmen kívül hagyva természetesen az interneten belüli interneteket (Google, Facebook, és társaik.)Most remélem nem fogok hülyeséget írni, de: Egyébként az INT esetében a mező méretének definíciója teljesen felesleges, az INT ígyis úgyis 4 byte, azaz 4.2+ milliárd egyedi egész számot tárollhatsz így. A sima INT értéktartománya: -2147483648- tól 2147483648-ig terjed. Ha ID-hoz használod az INT típusú mezőt, akkor célszerű INT UNSIGNED-ként definiálni, így negatív értékek nincsenek, 0-tól 4294967295-ig mehetnek bele az értékek.
Ha ez sem elég, ott a BIGINT, 8 byte-on, UNSIGNED-nak definiálva 0-18446744073709551615 egész szám. Nem tudom elképzelni, hogy ez se lenne elég.
Hogy a többire is válaszoljak:
Teljesen projekt függő. E-mail címeknek én simán VARCHAR(255)-öt adnék. Vannak elég extrém címek. A többi rajtad múlik. Fontos viszont, hogy a beadott stringek hosszúságát ellenőrizd szerver oldalon, ne told bele a max 40 hosszú mezőbe a 120 hosszú stringet, mert így jársz. -
#16518
tothjozsi96
addikt
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy ti milyen hosszúságokat szoktatok beállítani SQL-ben?
Pl.
ID -> INT(10)
Username -> VARCHAR(40)
Email -> Varchar(40)Ezekre lennék kíváncsi, egy régebbi oldalban láttam ezeket, de nem tudom hogy mennyire hasznosak.
Láttam olyan oldalt ahol problémát okozott már az INT(10) is. -
Des1gnR
őstag
Sziasztok!
Egy ilyen hibát dob az oldalam:
Please enable cookies.
Error 1001 Ray ID: 17d551354a1b0563
DNS resolution error
What happened?
You've requested a page on a website (uijquery.org) that is on the CloudFlare network. CloudFlare is currently unable to resolve your requested domain (uijquery.org). There are two potential causes of this:
Most likely: if the owner just signed up for CloudFlare it can take a few minutes for the website's information to be distributed to our global network.
Less likely: something is wrong with this site's configuration. Usually this happens when accounts have been signed up with a partner organization (e.g., a hosting provider) and the provider's DNS fails.
CloudFlare Ray ID: 17d551354a1b0563 • Your IP: 195.70.47.141 • Performance & security by CloudFlareTalálkoztatok már vele?
-
#16515
DNReNTi
őstag
honda 1993
#16514
DNReNTi
őstag
válasz
honda 1993
#16514
üzenetére
-
#16514
honda 1993
senior tag
honda 1993
senior tag
Üdv.
Hol találok olyan táblázatot, vagy oldalt ahol minden egyes karakter jelentése le van írva?
Mint pl ahogy a (.) - ot úgy hívjuk hogy összefűző operátor, vagy a ("") - be a karakterláncokat írjuk, stb.
Azért kellene, mert elég gyakran elfelejtem hogy mi mit jelent, és jó lenne ha egy helyen meglenne minden.
-
disy68
aktív tag
Jelszó tároláshoz érdemes egy biztonságosnak tekintett hash algoritmust használni sóval (ami biztos, hogy az md5 és sha1 elavultnak tekinthető). Nem szabad abban bízni, hogy az általunk használt eljárás nem ismert (security through obscurity).
Természetesen plusz funkcióként használhatunk captcha-t (többszöri próbálkozás ellen), de ez nem mentesít a megfelelő tárolástól.
Ennek azért elég nagy az irodalma érdemes rendesen utánajárni, ha valóban fontos a biztonság (algoritmusok, só, iterációk, ellenőrzés).
Egy jó cikk a témában. Van példakód is pár nyelven.
-
#16511
DNReNTi
őstag
fordfairlane
#16510
DNReNTi
őstag
válasz
fordfairlane
#16510
üzenetére
Van bizony. Most kipróbáltam olyan mezőn amin nincs, úgy >700ms.
Szerkesztéshez: +1.(#16509) disy68
E má' level 4. -
#16510
fordfairlane
veterán
DNReNTi
#16508
fordfairlane
veterán
válasz
DNReNTi
#16508
üzenetére
Van azon a string mezőn index?
Egyébként meg a biztonsági vitához: Szerintem egy kezdő ne akarjon ilyenbe belemenni, elég volna, ha a beépített sessionkezelőt használja. Ez még mindig sokkal jobb opció, mint ahogy eredetileg akarta, hogy majd nekiáll cookieba menteni házibarkács hash-adatokat meg jelszót. Nem is értem, hogy miért erőlteti ezt a dolgot, amikor alapvető dolgokkal nincs tisztában.
-
disy68
aktív tag
válasz
DNReNTi
#16504
üzenetére
Amit én használok biztonságos megoldásként az kicsit bővíti az általad írt 3. megoldást (sajnos az eredeti cikket nem találom):
- Van egy "sorozat" token
- Van egy egyszeri tokenMindkét token egy hash érték, amiket úgy generálunk, hogy egyedi értékek legyenek - ne forduljon elő, hogy két felhasználónak azonos értéket adunk. A tokeneket a felhasználó egyedi azonosítójával együtt egy külön tábla tartalmazza - itt tárolhatunk egyéb információkat is a bejelentkezésekhez, pl. ip, user agent, stb.
Amikor a felhasználó bejelentkezik, akkor kap egy-egy tokent. A "sorozat" token nem fog változni a bejelentkezés alatt, viszont az egyszeri token minden lekéréskor változik - ezt természetesen figyelembe kell venni a tervezés során, hiszen minden oldallekérés adatbázisművelettel is párosul, kis felhasználószám esetén nincs jelentősége.
Egy felhasználóhoz több sorozat + egyszeri token rendelhető (egy "sorozat" token egy egyszeri tokennel áll párban), így lehet a felhasználó több kliensen egyszerre bejelentkezve. Bejelentkezéskor a felhasználóhoz tartozó tokenek törlésével/nem törlésével oldhatjuk meg a "nem lépek ki más böngészőből" itt a ph-n is használatos funkciót.
Amennyiben valaki megszerzi a két értéket, akkor addig tud ügyködni a nevünkben, amíg mi nem frissítjük az oldalt -> amikor ellenőrizzük a 2 tokent, akkor a sorozat ugyanaz, de az egyszeri nem, ezért kiléptetjük a felhasználót.
A két tokent és a felhasználó egyedi azonosítóját tárolhatjuk session és/vagy cookie értékként (akár az egészet egy stringként), elsődlegesen a session változót figyelembe véve. Amennyiben nincs session csak cookie, akkor kezelhetjük úgy a felhasználót, hogy nem biztonságosan van bejelentkezve és egyes funkciókat (pl. jelszóváltoztatás) csak a jelszó újbóli megadása után teszünk elérhetővé. Ha a felhasználó bejelöli a "bejelentkezve maradok" pipát, akkor tároljuk az értékeket cookie-val és session-nel, ha nem akkor csak session-nel.
Remélem sikerült érthetően megfogalmaznom a lényeget.
-
#16508
DNReNTi
őstag
Peter Kiss
#16505
DNReNTi
őstag
válasz
Peter Kiss
#16505
üzenetére
"Az meg nettó hülyeség, hogy ennyire kicsi adat mellett bármit számítana a szám vs. szöveg megkeresése"
Most csak a kedvedért egy 96.675 soros táblán lefuttattam egy-egy selectet:
String-re (felhasználónév) keresve: 125 ms.
Int-re (id) keresve: <0 ms.Egy forgalmas oldalnál szvsz ez igenis számít, napi több tízezer (esetleg még több) lekérés esetén ez nagy különbség. A random szám generálást nálam egy saját metódus oldja meg, ami eredetileg random stringet generál, de beállítható paraméterrel, hogy a string csak 0-9-ig karakterekből álljon, így "számosítható" az eredmény.
-
#16507
biker
nagyúr
tothjozsi96
#16502
biker
nagyúr
válasz
tothjozsi96
#16502
üzenetére
Most lehet páran nekem ugranak, vagy legalább elindul egy vita, de...
Az md5 NEM alkalmas jelszó titkosítására, mert nem titkosító eljárás. egy kód, ami 32 bit hosszú, akkor is, ha az input "a" vagy épp NULL, és 32 bit akkor is, ha egy 10GB-os image file ellenőrzőkóód generálás a feladat.
Ebből ered, hogy információt nem hordoz, és persze nem is visszafejthető, (de vannak md5/szó pár adatbázisok)
Ellenben kis valószínűséggel, de előfordul hogy két teljesen más karaktersornak ugyanaz lesz az md5 értéke.
A többit rád bízom, mit választasz -
#16506
Sk8erPeter
nagyúr
Peter Kiss
#16505
Sk8erPeter
nagyúr
válasz
Peter Kiss
#16505
üzenetére
Szerintem mindenki jobban jár, ha leírod a megfelelő megközelítést.
-
#16505
Peter Kiss
őstag
DNReNTi
#16504
-
#16504
DNReNTi
őstag
tothjozsi96
#16502
DNReNTi
őstag
válasz
tothjozsi96
#16502
üzenetére
A biztonságos beléptetés valamint főleg a felhasználói adatok biztonságos kezelése elég összetett dolog, írhatnék délig, mire leírom az egésszel kapcsolatban a véleményemet.
Mivel az idő az ellenségem, rövidre fogom. Ami már kiderült itt korábban is a felhasználói adatok sütiben tárolása a lehető legrosszabb megoldás, ha ráadásul még a jelszót is sütiben tárolod (ahogy korábban írtad) az pedig egyenesen kötél általi halált ér. Leírom az én alap megoldásom, aztán majd a többiek kijavítják vagy kiegészítik, szerintem ez egy weboldal esetén megfelelően biztonságos:
A felhasználók az alap adataikon kívül regisztrációkor kapnak egy mondjuk 20 számjegy hosszú unique random számsort, amely adatbázisban a felhasználó táblában van rögzítve. Amikor a felhasználó a felhasználónév és jelszó párossal helyesen belép, akkor a $_SESSION[] változóban eltárolom ezt a random azonosítót. Innentől a böngésző bezárásáig ez alapján azonosítom a felhasználót. A számsor unique, szóval ugyan úgy használhatom erre a célra mint mondjuk az id-t. Ha lehetőséget adsz arra, hogy a felhasználó belépve maradjon, akkor ezt a számsort nyugodtan tárolhatod sütiben is, így amikor a felhasználó újra meglátogatja az oldalt, a süti tartalmát beállítod a session változóba és minden megy tovább ahogy eddig. Kilépéskor a sütit "lejáratod" a sessiont unset()-eled.Miért számsor és nem string?
Mert az SQL lekérdezés gyorsabb számszerű ekvivalenciára mint szöveges egyezésre.Miért jó ez megoldás?
Mert ha még valaki, valahogyan hozzá is jutna, ehhez az azonosítóhoz (pl. a sütiból), abban semmilyen logikai minta nincs, ami alapján a többi felhasználó azonosítója megszerezhető lenne.Hogyan lehet ez még biztonságosabb?
Ennek a level 2 változata, ha random azonosítót minden belépéskor generálod és mented el a felhasználóhoz, ez viszont félmegoldás, mivel ha a felhasználó miközben be van lépve, belép egy másik eszközről, akkor az eredeti munkamentét el fogja veszíteni.Hogyan akadályozható ez meg?
Egyszerűen, level 2 helyett egyből a level 3-mal. Ugyan úgy egyedi azonosítót generálsz belépéskor, de ezt már nem a felhasználó táblában, hanem egy külön a belépéseket kezelő táblában rögzíted. Fontos, itt nem elég csak a random azonosítókat és a felhasználó id-kat tárolni, az egyértelmű azonosítás érdekében környezeti változók mentésére is szükség van. Kilépéskor a tárolt munkamenet célszerű az adatbázisból eldobni, így nem lesz tele szeméttel, továbbá érdemes időközönként háttérfolyamattal takarítani, teszem azt mondjuk a 48 óránál régebbi munkameneteket eldobni.Röviden ennyi.
Aki nem ért egyet pls javítson ki. -
#16503
mobal
nagyúr
tothjozsi96
#16502
válasz
tothjozsi96
#16502
üzenetére
Mindenképpen session cookie.
-
#16502
tothjozsi96
addikt
DNReNTi
#16501
tothjozsi96
addikt
-
#16501
DNReNTi
őstag
tothjozsi96
#16500
DNReNTi
őstag
válasz
tothjozsi96
#16500
üzenetére
A kérdésedben benne a válasz.
UTF8 a fájlod, erre beállítod hogy a böngésző ISO-8859-2 formátumként kezelje.
Olyan jól fogalmaz. 
Asszem tényleg abba kéne hagyni a topic követését, mert ez már szánalmas, hogy hol tartunk. De még egy rohadt kérdést sem képesek mostanában megfogalmazni értelmesen az emberek, hogy mégis mi a frászt akarnak tudni. Most már 
ne higgyétek, hogy egy rakás PHP programozó, aki ugyan nem ír ide, egy pindurit is magasabb szinten van az itt kérdezőktől ), és csak akkor jön ide olvasni, amikor privátban megkapja az aktuális új gyöngyszemet 
Mikor lett annyi, adatbázisba való feltöltés után, vagy még az alkalmazás "szintjén"? Az a baj, hogy csomószor harapófogóval kell kiszedni belőled az érdemi, nem mellébeszélő infókat, még sokszor így sem sikerül, és így az embernek csomószor elmegy a kedve a segítéstől.![;]](http://cdn.rios.hu/dl/s/v1.gif)
Egyébként meg nyilván ellenőrizni kell egy kulcs/változó meglétét, mielőtt felhasználod, nem tudom, mit kell csodálkozni az Undefined index-szel kapcsolatos Notice-on.
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RTX 4060Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy A22/Samsung Galaxy A23/Samsung Galaxy A25/Samsung Galaxy A05s
- Bomba ár! Fujitsu LifeBook U757 - i3-7GEN I 16GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Garancia!
- QNAP TS-870U-RP 8 lemezes Rack NAS
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest