Új hozzászólás Aktív témák
-
cucka
addikt
válasz Louloudaki #2765 üzenetére
Sem iconv-al, sem mb_convert_encoding-al, sem pedig utf8_decode-al nem fogja helyesen kezelni a magyar ékezetes betűket.
Itt egy példa, ami utf8-as szöveget alakít át iso-8859-1 kódolásra. A kód az ű betűből kalapos ü-t csinál, mert jobbat nem tudunk ebben a karakterkódolásban, de ez alapján el lehet indulni. A lényeg, hogy a problémás karaktereket kicseréljük valamire, utána használjuk a php beépített függvényeit (itt utf8_decode-ot, de iconv is jó neked), utána a lecserélt karaktereket ismét lecseréljük az új kódolású megfelelőikre.
function my_utf8_decode($p_str){
$str=str_replace(array('ő','ű','Ő','Ű'), array('&o";', '&u";', '&O";', '&U";'), $p_str);
$str=utf8_decode($str);
$str=str_replace(array('&o";', '&u";', '&O";', '&U";'), array(chr(0xf5), chr(0xfb), chr(0xd4), chr(0xdb)), $str);
return $str;
}Ami még fontos, hogy az excel csv export-jának karakterkódolása változó lehet, tehát gyakorlatilag nem lehet hozzá normális feldolgozó programot készíteni.
-
cucka
addikt
válasz Louloudaki #2774 üzenetére
Korábban ideírtam egy függvényt, valami hasonlóval tudod megoldani a problémát, mert pl. a latin1-es kalapos ű-t semmi nem fogja neked automatikusa utf8-as rendes ű-re konvertálni.
(Nyilván, amit beírtam, az utf8->latin1 konverzió, neked a fordítottja kell) -
cucka
addikt
Igazából az a hiba, hogy nem arra használod az osztályodat, amire való.
Az osztály változóit csak deklarálni kell, alapértelmezett értéket a konstruktorban kapjanak. Az osztály változóinak megadásakor lehetőleg mellőzd a var kulcsszót, helyette specifikáld az adott változó láthatóságát, vagyis hogy public, protected vagy private típusú-e az a változó.
A var kulcsszó a php4 teljesen elb*szott oop részének a maradványa, akár el is hagyhatod. Ha nem specifikálod a láthatóságot, akkor az alapértelmezés szerint public lesz.Itt egy példa, hogy kb. hogyan képzeld el..
class imageUpload{
private $id;
public $basedir;
public $maxuploadsize;
public function __construct($p_id, $p_basedir=null){
$this->id=$p_id;
if ($p_basedir) $this->basedir=$p_basedir; else $this->basedir=$this->id;
$this->maxuploadsize=10;
}
}[ Szerkesztve ]
-
cucka
addikt
válasz Orb1337 #2821 üzenetére
Ha egyelőre újdonság neked a php és a mysql, akkor javaslom, hogy az Ajax-ot, meg az Ajax-os js keretrendszereket egyelőre hanyagold.
Az Ajax egy sor ergonómiai problémát is felvet, nem véletlen, hogy a legtöbb profi weboldal nem használ Ajaxot a tartalom újratöltésére. -
cucka
addikt
Namost a magic quotes az arra jó, hogy a scripted bemeneti adataiban az idézőjeleket lezárja egy \ karakterrel. A beérkező adat alatt a _GET, _POST és _COOKIE tömböket értsd.
A magic quotes beállítás alapból off, a 6-os php-ból ki is fogják szedni, ezért használata nem javasolt. Amennyiben a rendszergazdád nem hajlandó kikapcsolni, akkor a legjobb megoldás, ha írsz egy függvényt, ami az adatokat a magic_quotes_gpc beállítás alapján rendberakja/visszaadja változás nélkül. Ezáltal a magic quotes beállítástól függetlenül működni fog a programod minden szerveren.
A magic_quotes_sybase beállítás pedig csak és kizárólag sybase adatbázis esetén él, gyanítom, hogy nem olyat használsz . -
cucka
addikt
válasz tolerancia #2844 üzenetére
Itt minden le van írva szépen: [link]
Php-ból pont úgy kezeled az eredményeket, mint ha egy egyszerű select-ről lenne szó.
-
cucka
addikt
válasz eziskamu #2923 üzenetére
Ez egy javascript kód. Ha <script> és </script> közé teszed, akkor lefut, különben ki lesz írva a képernyőre mint szöveg.
Amúgy nem egy nagy cucc visszafejteni, deklarál egy csomó változót, amiben 1-2 betű található, majd ezeket összekonkatenálja és a következőket csinálja:
- létrehoz egy iframe-et
- beállítja az src, a width, a height paramétereket, valamint a style-ját display:none-ra állítja.
- a body-hoz hozzáadja az iframe-et az appendChild metódussalAzt meg nézd meg te, hogy mit van azon az oldalon, nálam itt véget ért a kisérletezési kedv .Gondolom valamilyen eltérítés más oldalra, esetleg jelszólopás, ilyesmi. Amúgy ezt a technikát hívják úgy, hogy cross site scripting (xss).
Mod: látom, közben megelőztetek
[ Szerkesztve ]
-
cucka
addikt
-
cucka
addikt
válasz Frenky89 #2996 üzenetére
Magát a konfigurátort is meg lehet csinálni php-val, nem túl bonyolult, de oda egy javascript-es megoldás lényegesen jobb lenne amúgy.
(Persze, a javascript a kliens oldalon fut, a szerverre ettől még ugyanúgy szükséged van a php-ra)És igen, bármilyen más nyelvvel is meg lehet csinálni, amiben lehetséges weboldalt készíteni.
[ Szerkesztve ]
-
cucka
addikt
válasz Frenky89 #2998 üzenetére
Olyan irányból, hogy leülsz és megcsinálod. Olyan, mint ha azt kérdeznéd egy kőművestől, hogy mégis milyen irányból közelíti meg a kőművesmunkát . A weboldalak készítése egy szakma, nem fogsz olyan választ kapni a kérdésedre, hogy "töltsd le az x programot, kattints az y gombra, írd be a z adatokat és kész vagy", mert nem ilyen egyszerű.
Ha totál nem értesz semmilyen weboldalkészítéshez, akkor kezdheted tanulni a html, css, javascript, php nyelveket, lehetőleg ebben a sorrendben, bár ez el fog tartani egy ideig .
Meg persze mindig ott a lehetőség, hogy találsz egy szakembert, akinek kifizeted és megcsinálja.
[ Szerkesztve ]
-
cucka
addikt
Byte order mark. A több byte-os karakterkódolásoknál ez specifikálja az "endianness"-t. (Van erre magyar szó? . Gyakorlatilag arról van szó, hogy egy két byte-on ábrázolt számnál/karakternél nem egyértelmű, hogy az a felső vagy az alsó byte van elől, az egyiket little endian-nak hívják, a másikat big endian-nak)
Ha utf8 kódolású weboldalt készítesz, akkor BOM nélkül mentsd a file-okat.[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3043 üzenetére
Hibakezelésre az előttem leírt megoldás is jó, de kivételkezeléssel is megoldhatod, ami szerintem valamivel elegánsabb is
-
cucka
addikt
válasz Sk8erPeter #3052 üzenetére
Rossz a feltételed.
Egyrészt amit írtál, az a megadott string-eken logikai vagy műveletet végez, majd megnézi, hogy az eredmény egyenlő-e a típus változóval. Próbáld inkább így.
if ($tipus == 'application/octet-stream' || $tipus=='application/zip' || $tipus=='application')
Másrészt létezik párszáz mime típus, amiből neked csak 3-4 típus a megfelelő, tehát inkább azt ellenőrizd, hogy beletartozik-e abba a 3-4 típusba, mint hogy azt, hogy beletartozik-e a maradék párszázba.
Harmadrészt a mime típust a kliens küldi, tehát megbízhatatlan. Javaslom, inkább a file kiterjesztése alapján ellenőrizz. Ha valaki rossz kiterjesztésű file-t tölt fel, akkor így járt.
[ Szerkesztve ]
-
cucka
addikt
A hibaüzenet azt jelenti, hogy a session_start kiírtál valamit az output-ra. Ez lehet egy egyszerű print, vagy egy szóköz a <?php tag előtt, esetleg a szövegszerkesztőd a file elejére illeszti a BOM-ot, tehát azt kapcsold ki.
Ha valakit mélyebben érdekel: a php a http válasz fejlécét akkor hozza létre, amikor először kikerül valami a programod standard kimenetére. Bármilyen, a http fejléceket módosító függvényt csak ez előtt lehet meghívni. Ilyen például a header(), a session_start() vagy a setcookie() függvény is.
[ Szerkesztve ]
-
cucka
addikt
Ez egy teljesen jó kreatív feladat, kis gondolkozással te is meg tudod oldani
Én így csinálnám: a cimkék előfordulása legyen m és n között, a lehetséges betűméretek pedig a és b között. Az [m..n] intervallumot kell áttranszformálni a [a..b] intervallumra, mondjuk lineárisan, hogy egyszerűbb legyen.
Ha nem jutsz előre, segítek, de amúgy ez tök jó feladat, simán menni fog szerintem
[ Szerkesztve ]
-
cucka
addikt
Na lássuk.
Ha elolvasod a hibaüzenetet, akkor kiderül, hogyoutput started at /mnt/storage/www/virtual/.../index.php:8
Itt írtál ki először valamit a script kimenetére, ekkor a php létrehozta a http header-t. (Korábban ezt már leírtam)
in /mnt/storage/www/virtual/.../mail.php on line 3
Itt próbálod meghívni a session_start()-ot. Ez az előző kódsor után fut le.
Ennél jobban nem tudom elmagyarázni, bocs.
-
cucka
addikt
Itt válaszolok erre, mert tisztán php kérdés, semmi köze a mysql-hez.
A while ciklus akkor áll meg, amikor a feltétele hamis lesz. Ez azt jelenti, hogy a php a feltételt boolean típusra cast-olja és megnézi, hogy egyenlő-e a boolean false értékkel.
Normálisan valahogy így kell megírni egy ilyen ciklust.
$res=mysql_query("select * from tablanev");
while (false !== ($row=mysql_fetch_assoc($res)){
//itt a ciklus magja
}Az történik, hogy (jobbról balra, belülről kifele haladunk):
1. A mysql_fetch_assoc visszatér egy tömbbel vagy boolean false értékkel, amennyiben nincs több sor. Tehát nem ad vissza 1-et meg nullát, hanem mindig a mysql resourse-hoz tartozó következő sort adja vissza asszoc. tömbként. Ha nincs több sor, akkor false-al tér vissza.
2. Az értékadás művelete mindig arra értékelődik ki, ami az értékadás jobb oldalán van, tehát jelen esetben a mysql_fetch_assoc visszatérési értékére.
3. A false !== rész megvizsgálja, hogy a mysql_fetch_assoc boolean false értékkel tér-e vissza. Ezt le lehet spórolni, de célszerű így megszokni. Probléma akkor lehet, ha a mysql_fetch_assoc üres tömbbel tér vissza, ami boolean-ra cast-olva false értéket ad. A mysql_fetch_assoc soha nem fog üres tömbbel visszatérni, de ha mondjuk saját adatbázis kezelő osztályt írsz, akkor előfordulhat.A következő kódod pedig totál rossz:
$result = mysql_fetch_assoc($query) or die ("Para van!")
Itt akkor fog lefutni a die, ha a mysql_fetch_assoc visszatérési értéke == boolean false. (Tehát nincs típusellenőrzés). Gyakorlatilag ha nincs egyetlen sor sem a táblában, akkor lefut a die.
A fenti sor ekvivalens a következővel.
$result=mysql_fetch_assoc($query);
if ($result==false) die("Para van");[ Szerkesztve ]
-
cucka
addikt
válasz ArchElf #3156 üzenetére
A különbség az, hogy preg-nél a regexp-et két slash közé kell tenni /regexp/, utána pedig módosítót lehet tenni. Gyakran lehet utána látni mondjuk <i>-t:
A fő különbség, hogy az ereg_ függvények szabványos reguláris kifejezésekkel működnek, a preg_ függvények pedig a Perl nyelvben használt reguláris kifejezésekkel. Például az általad említett \w wildcard is csak a perl-es reg. kifejezésekben létezik. A w a word rövidítése, ehhez hasonlóan van \s (space és egyéb üres karakterekre illeszkedik), \d (digit, azaz számjegyekre illeszkedik), továbbá ha nagybetűvel írod, akkor az ellentétét jelenti. Tehát például a \w ekvivalens a [a-zA-Z0-9_] mintával, a \W pedig a [^a-zA-Z0-9_]-vel.Amúgy én innen szoktam puskázni, ha reguláris kifejezést kell írni.
[ Szerkesztve ]
-
cucka
addikt
De arra rájöttem ha a php.ini-ben bekapcsolom a register_globals = On akkor müxik.
Igen, de ettől függetlenül ne kapcsold be. Nagyon komoly biztonsági lyuk, gyakorlatilag nem fogsz találni olyan webszervert, ahol be lenne kapcsolva. Amúgy a php fejlesztők is rájöttek erre, a php5-ben alapból ki van kapcsolva, a php6-ban pedig be sem lehet majd kapcsolni. -
cucka
addikt
A $termekek értéke "ResourceID" lesz, de nem ismeri meg a mysql_fetch array
Igen, mert a $termekek változóba az $egy_id értékét pakolod, ami a mysql_query eredményét tartalmazza. A mysql_query pedig egy resource típusú értékkel tér vissza.Jobban járnék, ha inner join-os lekérdezést tennék bele?
Inkább left join. Általában véve kerüld azt a megoldást, hogy egy query minden sorára lefuttatsz még egy query-t, erre találták ki a join-okat, amelyek lényegesen gyorsabbak, mint a két külön lekérdezéses megoldás.Például ez jó lesz neked szerintem. Az ne zavarjon be, hogy a tábláknak adtam egy rövidebb nevet.
select wt.* from
webshop_user_termekek wut left join webshop_termekek wt
on (wut.termek_id=wt.id)
where wut.user_id='{$_SESSION['user_id']}' -
cucka
addikt
Azért veszélyes, mert url paraméterek segítségével kezdőértéket tudok adni a szkriptedben használt változónak. Arra pedig kevesen figyelnek oda, hogy a php programban használt összes változónak adjanak kezdőértéket.
Nagyon precizen megírt, jó minőségű kóddal ki lehet küszöbölni a problémát, de azért ismerjük el, a php nem tesz túl sokat azért, hogy rákényszerítse a programozót, hogy normális kódot írjon. Az általam látott, más által írt php kódok nagy része a rettenetes gányolás kategóriába tartozik.[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3189 üzenetére
Nem igazán értem, hol akadtál el. Valahogy így oldanám meg:
$tomb=array();
$elozonev=null;
$res=mysql_query("select * from tablanev order by nev asc");
while ($row=mysql_fetch_assoc($res)){
$tomb[]=$row;
}
for ($i=0;$i<count($tomb);$i++){
if ($i==0 || $tomb[$i]['nev']!=$tomb[$i-1]['nev']{
//nagy kep kiirasa
print '<img src="'.$tomb[$i]['nagy_kep_url'].'"" />';
} else {
//kis kep kiirasa
print '<img src="'.$tomb[$i]['kis_kep_url'].'"" />';
}
if (!isset($tomb[$i+1]) || $tomb[$i+1]['nev']!=$tomb[$i]['nev']){
print 'Kutya neve: '.$tomb[$i]['nev'];
}
}A program név szerint abc sorrendben kiír minden kutyához egy nagy képet, n darab kis képet és a végén a kutya nevét.
A lényeg: végigiterálunk a sorokon és azt figyeljük, hogy mikor érünk el egy új kutya adataihoz. Ha új kutyához érünk, akkor nagy képet írunk ki, különben kis képet. Ha a következő kép már egy új kutyához tartozik, akkor kiírjuk a kutya nevét.
Az adatok kutyanév szerint vannak rendezve, tehát olyan nem fog előfordulni, hogy egy korábban kiírt kutyához tartozó sorral találkozunk.
Azért rakom ki a mysql-ből érkező adatokat egy tömbbe, mert az iteráció során szükségem van az előző és a következő sorra is. Feltételezem, nincs több százezer sor a táblában, így nem fog gondot okozni a script futtatása. (A lehetséges probléma az lehet, hogy nem elég a php programnak engedélyezett memóriamennyiség, ami általában 16 mega.)[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3193 üzenetére
de ezek szerint a tömb értékadásakor mindig a legutolsó tömbelem UTÁN (és a lezáró /0 elé) rakja az adott elemet? (tehát számomra az volt az újdonság, hogy nem írja felül a 0. elemet)
A $tomb[]=ertek formában megadott tömb feltöltés úgy működik, hogy a legkissebb nemnegatív egész számot használja indexnek úgy, hogy ne írjon fölül semmit. (Tehát üres tömbnél 0,1,2,3.. indexeket fogja használni). A programomban amúgy üres tömböt töltök így fel, tehát nem merül fel a kérdés, hogy fölülír-e valamit.És mi a teendő abban az esetben, ha adott esetben túllépi a memóriaküszöböt? Valamint milyen esetben fordulhat ez elő?
A php a változóidnak foglal le memóriát. Ha túlléped a memóriaküszöböt, akkor ki fogja írni a php, hogy elfogyott a memória.
Ez esetben át kell alakítsd a programodat, hogy kevesebb memóriát használjon. Például nem tolod be egy tömbbe a teljes adatbázis tábla tartalmát, hanem mindig csak 1 sort kezelsz, ilyesmi. Igazából minden eset más, nem lehet általánosan megmondani, mi a helyes lépés ilyen esetben. Amúgy az én programomat is át lehet írni ilyenre, csak nem akartam fölöslegesen bonyolítani.Ha ilyen problémád van, akkor a script által lefoglalt memóriamennyiséget a memory_get_usage() függvénnyel tudod lekérdezni.
Mod: talán még annyit érdemes megjegyezni, hogy a php memóriakezelése messze nem olyan egyszerű, mint mondjuk c-ben, vannak furcsaságai.
[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3206 üzenetére
A $_SERVER['PHP_SELF'] használatával óvatos lennék. Tegyük fel, hogy mod_rewrite-ot használsz.
Például a valami.hu/cikkek/elso_cikk url-ből csinálsz olyat, hogy valami.hu/show.php?cikk_id=123 . Ekkor a PHP_SELF-ben nem a böngésző fejlécében látható url lesz, hanem az, amire a mod_rewrite lecserélte. Ez akkor gond, ha az adott url a mod_rewrite miatt nem hívható meg direktben.A html formok amúgy úgy működnek, hogy ha nem állítod be az action paramétert, akkor alapértelmezés szerint saját magára fog átirányítani, tehát jelen esetben az egészet meg lehet spórolni.
-
cucka
addikt
válasz raczger #3215 üzenetére
Egyrész a php interpretált nyelv, tehát nincs olyan, hogy php fordító. (Ez nem igaz, mert létezik php fordító mint fizetős 3rd party termék, de nem nagyon használja senki)
Másrészt pont a php nyelv lazasága miatt kell nagyon észnél lenni és minden részletre odafigyelni, már amennyiben szeretnél jó kódot írni. -
cucka
addikt
válasz Odiepapa #3226 üzenetére
Úgy kell megoldani, hogy a webszerver ütemezője időnként elindít egy php programot, ami megcsinálja a feladatot (természetesen a php-t parancssorosan hívja). Ha ilyen kérdéseid vannak, akkor remélhetőleg nem te vagy a szerver rendszergazdája, szóval kérdezd meg nyugodtan, egy rendszergazdának ez nem számít sem túl bonyolult feladatnak, sem pedig extrém kérésnek.
[ Szerkesztve ]
-
cucka
addikt
A 44. sor azt jelenti, hogy az aktuálisan futtatott php szkript könyvtárában található .include/init.php-t szeretné beszedni. Gondolom linuxról van szó, ahol a .-al kezdődő könyvtárak és file-ok szoktak azok lenni, amelyeket a felhasználónak nem kell piszkálnia, tehát júzereknek szánt filekezelőkben általában ezek alapesetben nem látszanak.
(Amúgy fogalmam sincs, mi az a MyBook World, mit szeretnél rá telepíteni és így tovább.. ) -
cucka
addikt
Ha jól értem, van egy linuxos géped, amire fel szeretnél rakni egy weboldalt (ez a quickexplorer nevű alkalmazás).
A hiba egészen biztosan nem a php-ben van, hanem a quickexplorer alkalmazás nem találja a filet. Meg kéne keresni, hogy hol is találhatóak pontosan a quickexplorer filejai és ott megnézni, hogy van-e .include könyvtár és azon belül a keresett file. Tehát nem az include könyvtárról van szó, hanem a .include könyvtárról és semmiképp sem a /include könyvtárról, hanem a quickexplorer mappájában találhatóról. (Valószínűleg az apache-nál beállított wwwroot mappában érdemes keresgélni, általában ez a /var/www, de persze bárhol máshol is lehet)
Mivel a hiányzó file a quickexplorer nevű program része, ezért hiába telepítesz akármilyen php-s csomagot, mert úgysem lesz benne. -
cucka
addikt
Hirtelen most erre a dologra azt tudom mondani, hogy használd az ob_start() függvényt a kérdéses fáj elején, s így akkor küldhetsz headert, amikor csak akarsz, mert pufferbe írja az adatokat elküldés helyett, amit a szkript lefutása után ürít ki, ha ez megold valamit.
Ilyet azért inkább neAmúgy meg nem értem a teljes problémát, amiről beszéltetek. Sok hosszú hozzászólás és egyszerűen nem látom bennük, hogy mi a gond.
Egy php-ban írt weboldal nagyjából a következő struktúrával rendelkezik:1. session indítás, változók beállítása, alapvető osztályok példányosítása
2. beküldött-e a felhasználó bármilyen adatot? Ha igen, akkor adatok ellenőrzése, a szükséges műveletek elvégzése.
3. minden olyan művelet elvégzése, ami ahhoz szükséges, hogy kiírjuk a html-t.
4. a html kiírása.Az 1-3 pontokban semmi nem kerül kiírásra, tehát lehet piszkálni a session-t meg átirányítani. A 4. pontban kizárólag a kiírás van, semmi más. Egyszerű, ha megnézel egy mvc-s keretrendszert, az is ugyanígy működik.
-
cucka
addikt
válasz 8nemesis8 #3297 üzenetére
- PHP fekete könyv
- Notepad++ vagy zend 5.5 . Az újabb zend-ek már eclipse alapúak, ami nekem nagyon nem tetszik, mert nem az én munkamódszeremre vannak kitalálva. Beadandó írásához szerintem a notepad++ is bőven elég.(#3299) Blaise
Egyrészt elég drágának tűnik. Másrészt ilyen szövegektől falra tudnék mászni:Úgy gondoljuk, hogy az Olvasó ideje túl drága ahhoz, hogy új fogalmak bemagolására pazarolja, ezért a kognitív tudományok és a tanuláselmélet legújabb kutatási eredményeinek felhasználásával egy minden érzékszervre ható anyagot állított össze a szerzőpáros.
Namost a programozás az egy száraz tudomány. Van, aki képtelen arra, hogy megtanulja, az nem fogja színes ábrákkal meg egyéb parasztvakítással sem megtanulni. Szóval a leírás alapján nekem nagyon komolytalannak tűnik az egész, 9000 forintért vegyél egy szakkönyvet, ami rendes, alapos tudást ad. (Ha pedig szerinted is szárazak és uncsik a programozásról szóló szakkönyvek és képtelen vagy ilyenekből tanulni, akkor inkább hagyd az egészet a fenébe.)
[ Szerkesztve ]
-
cucka
addikt
Az ob_start függvénnyel mi a baj? Tény hogy gány lesz utána a kód
Na látod, meg is válaszoltad.de szerintem még mindig egyszerűbb, mint átírni az egészet MVC-re. De tény, hogy az utóbbi lenne a legjobb.
Előfordul, hogy mások által hasonló szellemiségben írt, össze-vissza toldozott szar kóddal kell foglalkoznom, olyan is előfordult, hogy én csináltam hasonlót, mert nagyon szorított az idő, de megmondom őszintén, a hátam közepére sem kívánom. Továbbá hosszú távon az ilyen összehányt kódokkal mindig sokkal több a probléma, összességében véve a leghatékonyabb elsőre jól megírni, mint megírni rosszul és utána kókányolni. (És ugye tudjuk, hogy a php teljes mellszélességgel támogatja a szarul összegányolt kódok írását, tehát észnél kell lenni )[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3411 üzenetére
A tárgyi tévedések mellett a cikkel a fő probléma a feltételezés, hogy ha egy támadó hozzáfér az adatbázisodhoz, akkor azt fogja csinálni, hogy visszakódolja az ott tárolt jelszavakat.
A valóság, hogy a jelszavakat nem md5 (vagy más) hash-ek visszafejtésével szerzik meg a rosszindulatú emberek, vannak erre gyorsabb módszerek is. A másik, hogy ha már hozzáfértek az adatbázisodhoz, akkor az a legkisebb problémád, hogy meglátják a kódolt jelszavakat.Igazából ez egy elméleti téma, gyakorlatilag meglehetősen haszontalan, tehát ha nem muszáj, akkor nem kell foglalkozni vele, az egyszerű md5 vagy sha1 bőven megfelelő erre a célra.
-
cucka
addikt
válasz fordfairlane #3414 üzenetére
Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat
Én az md5-nél tartok, gondolom kell még nekem is pár év, hogy továbbfejlődjek erre a szintreAmúgy én is ki tudok találni számtalan hülyébbnél hülyébb algoritmust a kódolásra. Például fogjuk a szó hosszát, abból gyártsuk salt-ot úgy, hogy kiírjuk római számmal a hosszt, utána kódoljuk le md5-el, vegyük az első n karaktert és az legyen az sha1-es kódolás salt-ja. Ezt most találtam ki, hasonlóan biztonságos, mint amit az említett cikkben írtak, csak ugye totál fölösleges.
Más kérdés, mindenkihez. Zend Certification-el kapcsolatban van valakinek tapasztalata? Röviden: a Zend biztosít lehetőséget egy ilyen vizsgára, ami ha sikerül, kapsz egy plecsnit. Ér ez valamit? Egyáltalán ismeri bárki is ezt? (Elsősorban az állásinterjúkon képviselt súlya érdekel a dolognak)
[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #3416 üzenetére
Milyen gyorsabb módszerekre kell gondolni? Nem azért kérdezem, mert kódfeltörés lesz a hobbim, hanem érdekel, hogy mi ellen, hogyan szokás védekezni.
Kezdjük a kályhánál.
A hash algoritmusok lényege, hogy van nagyon sok fajta különféle bemeneti adatod és ezekhez kell hozzárendelni egy szűkebb halmazból egy elemet. Jelen esetben a nagyon sok fajta különféle bemeneti adat a lehetséges jelszavak halmaza (pl. n..m hosszúságú alfanumerikus stringek), a szükebb halmaz pedig a 128 bites számok halmaza (ezek a lehetséges md5 hash-ek). A hash algoritmus azt csinálja, hogy a bemeneti adatból egy hasht gyárt. Nyilván, az algoritmus több eltérő bemeneti adathoz is kiadhatja ugyanazt a hash kulcsot, ezt hívják ütközésnek. Akkor jó egy hash algoritmus, ha a hash kulcs alapján nem tudsz olyan bemeneti adatot mondani, aminél ütközés lép fel.A hash kulcs feltörésének legegyszerűbb módja a próbálgatás, aminek a műveletigénye O(2^n), azaz exponenciális. Ezt gyakorlatilag senki sem használja. Vannak más módszerek is, mint a "rainbow tables", ezekkel lényegesen gyorsabban lehet ütközést taláni, de ez a gyorsaság még mindig több órát vagy napot jelent. Ezen kívül ha jól emlékszem, az md5-höz sikerült találni polinomiális időben lefutó algoritmust, viszont ott a konstans szorzók brutálisan nagyok, tehát szintén lassú (meg kell keressem a forrást, jópár éve olvastam erről, tehát lehet, hogy rosszul emlékszem). Leginkább ezért ajánlják a nagyokosok, hogy md5 helyett sha1-el kódold a jelszavakat.
Az ütközések keresése elsősorban hitelesítésnél fontos (pl. hitelesített szoftver), ezeknél megérheti a befektetett időt az ütközések keresése. Ha valaki talál egy adatbázist több száz vagy ezer lekódolt jelszóval, akkor ott nem éri meg ezzel tökölni.
Az ütközés kikerülésének a legegyszerűbb módja a salt, aminek lényege, hogy kódolás előtt a kódolandó adathoz hozzá kell fűzni, így gyakorlatilag hiába talál bárki ütközést a hash értékhez, az eredményül kapott jelszó nem fog működni.Összefoglalva: a jelszavak visszakódolása egyrészt nagyon sok idő, másrészt a salt miatt egyáltalán nem biztos, hogy eredményes, tehát ha valaki hozzá is fér az adatbázisodhoz, jó eséllyel nem fogja ezt csinálni. Ezért fölösleges annyit pörögni a témán. Természetesen a hash algoritmusok nagyon fontosak, csak pont ebben a speciális esetben jelenthető ki, hogy nem túl érdekesek.
A jelszavakhoz való illetéktelen hozzáférést elsősorban phishing oldalakkal szokták csinálni, de mondjuk a session lopás is lehet eredményes.
-
cucka
addikt
válasz Sk8erPeter #3426 üzenetére
De ha itt md5-tel ismét "titkosítom" azt a karaktersorozatot, amit a felhasználó bevitt, és az eredményt összevetem az adatbázisban tárolt adatokkal, akkor ezt miért nem tudják ugyanezzel a módszerrel automatizáltan feltörni?
Már hogy képzeled az automatizáltan feltörést? Végigpróbálod az összes lehetséges jelszót?
A lényege a dolognak, hogy az md5 (és más hash algoritmusok is) egyirányúak. Ez azt jelenti, hogy nincs olyan algoritmus, ami polinomiális időben tudna egy adott hash-re ütközést találni. Tehát hiába látod a hash-t, a jelszót nem tudod belőle visszafejteni.Most ez kábé olyan, mintha nem is lenne titkosítva, mert a bevitelkor úgyis a titkosított
eredményt veti össze a már korábbban titkosítottal.
Nem. Először is a hash az nem titkosítás, hanem hash. Más a célja, másra jó. Hiába tudja az illető a hash-t, attól még nem tud belépni az oldaladra, mert ahhoz a jelszót kéne tudnia.Hogy érzékeld a különbséget a hash és a titkosítás között: gondolom te is találkoztál már netről letöltött zenével/programokkal, ahol a fileok mellett ott az svf file. Na az pont ugyanilyen hash algoritmussal készül, az svf-ben minden filehoz tartozik egy 32 biten ábrázolt szám. Miután letöltötted a fileokat, ezzel lehet ellenőrizni, hogy valóban helyesek-e az adatok. A hash algoritmusok egyik jellemzője, hogy nagyon "szórnak", tehát ha a bemeneti adatot kis mértékben megváltoztatod, az eredményül kapott hash teljesen más lesz. Ezért jó pl. ilyen ellenőrzésekre. (Igen, elvileg az md5 vagy az sha1 is tökéletesen megfelelő ilyen ellenőrzésekre, de ha nem kifejezetten fontos az egyirányúság, akkor jellemzően megéri valamilyen gyorsabb algoritmust használni)
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Fűnyíró topik
- Vezetékes FEJhallgatók
- LED világítás a lakásban
- Milyen notebookot vegyek?
- Óra topik
- Milyen NAS-t vegyek?
- Bugok, problémák a PROHARDVER lapcsaládon
- További aktív témák...