- Futott egy Geekbench kört egy új HTC készülék
- Poco X6 Pro - ötös alá
- Azonnali mobilos kérdések órája
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- Huawei Mate 10 Pro - mestersége az intelligencia
- Vodafone-ra áttért Digi Mobilosok
- Xiaomi Mi 11 Ultra - Circus Maximus
- iOS alkalmazások
- Yettel topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
Új hozzászólás Aktív témák
-
disy68
aktív tag
válasz PumpkinSeed #16447 üzenetére
Az MVC pattern, ahogy a neve is indikálja külön kezeli az adatot (model), megjelenítést (view), és a kettőt összefogó irányítást (control) - csak így egyszerűen megfogalmazva. Ez által adott, hogy ezeket a részeket külön kezelve, jellemzően külön fájlokként fogod megoldani - sok esetben ez több ezer külön fájlt is jelenthet. Persze itt számít az mvc keretrendszer működése, felépítése stb. (lehet, hogy a keretrendszer alapja áll csupán pár ezer kisebb fájlból és a számodra ténylegesen készítendő fájlok száma ehhez képest elenyésző).
A php / html keverése sokszor alapvetően adja magát, azonban egy template-kezelő működhet úgy is, hogy magában a template fájlban se html, se php kód nem fog szerepelni - persze ezt is php dolgozza fel, ami behelyettesíti a htmlt a template alapján.
MVC esetében, fontos, hogy a szerepek elkülönüljenek. Ez jelenti azt, hogy a controllereid és modelleid jellemzően nem fognak html kódot tartalmazni, csak php-t, míg a view több, mint valószínű, hogy fog mindkettőt. A lényeg, hogy az adott megvalósítás struktúrája fogja meghatározni, hogy a fájlok mit fognak tartalmazni.
--
Amennyiben kevered a html és php kódokat érdemes figyelni az olvashatóságra (a kód karbantartása miatt).pl. e helyett:
<?php
$menupontok = array('egy','kettő','három','négy');
echo '<ul>';
foreach($menupontok as $menupont){
echo "<li>$menupont</li>";
}
echo '</ul>';
?>könnyebben átlátható ez (alternative syntax használattal):
<?php $menupontok = array('egy','kettő','három','négy'); ?>
<ul>
<?php foreach($menupontok as $menupont): ?>
<li>
<?php echo $menupont ?>
</li>
<?php endforeach; ?>
<ul>
?>--
Egy függvény visszatérési értéke pedig egy darab "érték". Ez az "érték" tartalmát tekintve lehet nagyjából bármi. Ha neked egy darab szöveges érték kell, akkor egy string, ha kettő vagy több, akkor lehet array, ami tartalmazza a két vagy több stringet. Ha valami bonyolultabb struktúra kell, akkor lehet tömbök, tömbje, vagy akár egy objektum is, ami tövábbi logikát is tartalmazhat (metódusok).De először a nyelvi alapokat kell mindenképpen megismerni, és utána érdemes nézelődni a különböző programozási paradigmák, programtervezési eljárások és egyéb best-practice megoldások felé.
[ Szerkesztve ]
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
fordfairlane
veterán
válasz PumpkinSeed #16447 üzenetére
Maga az MVC csak nagy vonalakban ad iránymutatást arra nézve, hogy miféle nyelvi elemeket keverhetsz a kódodban. Az nagyjából oké, hogy a html a megjelenítéshez kapcsolódik, de az adott nézetnek számos egyéb funkciója is lehet.
A manapság bevett gyakorlat nagyjából annyi, hogy az oldal szerkezetét leíró html kód többnyire egy template fájlba kerül, amibe csak a legegyszerűbb php, vagy az adott template kezelő nyelvi elemei kerülnek bele. Pl. blokkdefiniálás, iteráció (foreach), beágyazás (include), csak a legegyszerűbb vezérlési szerkezetek. A többi, az adott nézethez kapcsolódó kódrészek mondjuk egy View objectben kaphatnak helyet, ami tisztán csak php utasításokat tartalmaz.
Én úgy szoktam csinálni, ha az adott rendszerben nincs template kezelő, hogy a nézetben a PHP alternatív nyelvi szintaktikáját használom, ezzel is érzékeltetve, hogy ez egy nézetleíró fájl.
<?php if(): ?>
<?php else: ?>
<?php endif; ?>
<?php foreach(): ?>
<?php endforeach; ?>[ Szerkesztve ]
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16447 üzenetére
Szerencsére a többiek elég alaposan válaszoltak az érdemi részre.
"Illetve egy függvény, hogy tud több String típust is visszaadni, például egy adatbázisból kiolvasott név és lakcím adatot például?"
Csak a pontosság kedvéért: nincs olyan, hogy "több String típus", string van, és kész, szerintem Te arra gondoltál, hogy mondjuk több string "értéket" szeretnél visszaadni. Tehetsz ilyet összetett típussal, tömbbel vagy objektummal is vissza tudsz térni egy függvényből. Egy függvénynek egy darab visszatérési értéke van.
Szerk.: ja, most látom, disy68 ezt is leírta neked.
Amúgy ilyen, hogy "adatbázisból kiolvasott név és lakcím adat", tipikusan valami objektumhoz kellene, hogy tartozzon ahhoz, hogy ez normálisan kezelhető legyen (ne pedig többdimenziós asszociatív tömbborzalmakat kelljen kezelned), például van egy Person osztályod (most csak a példa kedvéért), és ezt megfelelően példányosítod (példányosítás után lesz belőle objektum). Ha sok személy van, akkor objektumok tömbje is egy jó megoldás lehet (értsd: egy tömbbel térsz vissza, ebben pedig egy vagy több objektum van).(#16451) disy68 :
Szépen összeszedett válasz![ Szerkesztve ]
Sk8erPeter
-
kozicsd
tag
Sziasztok
Nagy szükségem lenne a PHP5 24 óra alatt című könyv cd mellékletére, sulihoz kellene. Elvileg ingyenes elérhető, de a link már nem él, ahonnan le lehetett tölteni. Esetleg nincs meg valakinek, és megszánna vele?
Köszönöm előre is! -
PumpkinSeed
addikt
Köszönöm a válaszokat. Igazából nincs is több kérdésem.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
tothjozsi96
addikt
Egy kérdés.
Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül? -
Sk8erPeter
nagyúr
válasz tothjozsi96 #16457 üzenetére
"Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül?"
Direkt idéztem a kérdésedet, csak hogy még egyszer lásd - szerinted mi értelme van ennek a kérdésnek?Sk8erPeter
-
válasz tothjozsi96 #16457 üzenetére
$szoveg .= $masikSzovegAVegere; //sima concat is megy nyilvan
$szoveg[$valahanyadikKarakter] = $kicserelemMasikra; //nem multi-byte safe
Mire kellene gondolni?
-
tothjozsi96
addikt
válasz Peter Kiss #16459 üzenetére
Tehát ha POST-ból jön egy ilyen adat "pista 123 pista".
Akkor az 123-at cserélje ki mondjuk arra hogy számok.
Tehát str_replace nélkül.
Igazából a smileyekhez kell, de 300 smileynél már lassú a string replace.
-
Speeedfire
nagyúr
válasz tothjozsi96 #16460 üzenetére
Esetleg preg_replace ?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
tothjozsi96
addikt
válasz Speeedfire #16461 üzenetére
Ez is lassú, azért kellene valami egyedi kivitelezés ...
Túl sok BB kódot kell átalakítanom ahhoz hogy gyors legyen.
-
fordfairlane
veterán
-
DNReNTi
őstag
válasz tothjozsi96 #16462 üzenetére
Csak kíváncsiságból, pontosan mit jelent az, hogy lassú? Úgy értem mondjuk egy 3.000 karakter hosszú string-nél milyen eredmény jön most ki, és mi lenne elfogadható? Egyáltalán mifajta oldal / alkalmazás az, ahol ennyire számítanak a milisec-ek? Már korábban is írtad valamire, hogy lassú. Egyébként minek 300 smile? Nem e elég mondjuk 20?
(#16463) fordfairlane +1
[ Szerkesztve ]
but without you, my life is incomplete, my days are absolutely gray
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #16462 üzenetére
Nem fogsz tudni kitalálni jobb általánosan alkalmazható, bizonyos szabályokat megfogalmazni képes "egyedi kivitelezést". Azért ez nem egy triviális feladat. Maradj csak a könyvtári függvényeknél, vagy max. keress valami komplex library-t... Amúgy a javasolt strtr sem tudom, mitől lenne jelen esetben jobb, mint az str_replace...
Mellesleg a te esetedben pont nem az str_replace a probléma, ami a lassúságot okozza, hanem az iszonyat sok smiley és hozzá tartozó külön-külön reguláris kifejezés, preg_replace-szel annak illeszkedésére való keresgélés és csere... (Magyarul a preg_replace jobban lassít, mint az annál jóval egyszerűbb cserére alkalmas str_replace.)
De ezt már egyszer kifejtettem neked. Ismétlés a tudás anyja.[ Szerkesztve ]
Sk8erPeter
-
DNReNTi
őstag
válasz Sk8erPeter #16465 üzenetére
Az strtr-el elkerülhető ciklus használata. Szerintem ennyivel "gyorsabb". Ki kellene próbálni, hogy ez a gyorsabb, vagy egy while ciklus a behelyettesítési tömbön.
szerk: elírás
[ Szerkesztve ]
but without you, my life is incomplete, my days are absolutely gray
-
Sk8erPeter
nagyúr
válasz DNReNTi #16466 üzenetére
Nézd meg a linken található kódot, ott nem nagyon van olyan rész, amire ez megoldást jelentene... Amúgy meg korábban azt írta a srác, hogy megoldódott a probléma, mert eleve feltöltésnél átalakítja a szövegeket (amit párszor korábban is javasoltam neki, de akkor valamiért neki nem jött át ), és akkor nem észrevehető a különbség, szóval most nem tudom, miért került elő újból a probléma...
Sk8erPeter
-
PumpkinSeed
addikt
Már nincs ötletem miért nem megy.
$target= "var/www/img_share/uploaded_img/";
$file_name = $_FILES['file']['name'];
$tmp_dir = $_FILES['file']['tmp_name'];
if(!preg_match('/(jpe?g|png)$/i', $file_name))
{
$error_msg = 1;
}
else
{
$target = $target.$file_name;
$feltoltve = move_uploaded_file($tmp_dir,$target);
echo $feltoltve;
}A move_uploaded_file nem teszi bele a fájlt a megadott mappába. Már végig próbáltam az összes lehetséges cél mappa elérési útvonalat. Illetve ellenőriztem a $tmp_dir tartalmát annak is van értéke. Valami jogosultsági probléma lesz, de viszont Debian alatt megadtam a www-data nevű felhasználót a teljes www mappa tulajdonosának, szóval az apache azt csinál vele amit akar. De mégse akar működni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
disy68
aktív tag
válasz PumpkinSeed #16468 üzenetére
Ebben:
$target= "var/www/img_share/uploaded_img/";nem inkább /var az útvonal eleje? A perjel nélkül a script helyétől keresné a var mappát és a többit.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
Sk8erPeter
nagyúr
válasz disy68 #16469 üzenetére
Mondjuk sokkal jobban is tenné, ha nem ilyen módon adna meg elérési útvonalakat, mint a /var-ral kezdődő, ami igencsak rossz megoldás, akkor már legyen a webalkalmazáshoz képest relatív (és persze az az útvonal legyen helyes is) - pl. ez ilyen módon kb. lehetetlenné teszi egy Windows-os szerverre való átköltöztetést (hacsak ott nincs var könyvtár az adott partíció rootjában (még a forward slash nem lenne probléma az útvonalnál, hiába Windows)).
Szerk.: félre ne értsd, ez nem neked szól, mert Te a lehetséges problémát tártad fel, inkább a kérdezőnek.
[ Szerkesztve ]
Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #16470 üzenetére
akkor már legyen a webalkalmazáshoz képest relatív
Vagy pedig használhatja a $_SERVER["DOCUMENT_ROOT"] -ot.
x gon' give it to ya
-
PumpkinSeed
addikt
válasz Sk8erPeter #16470 üzenetére
Ezt az utat már körbejártam. uploaded_img/-el kezdtem, szóval más lehetőséget oda nem tudok elképzelni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
disy68
aktív tag
válasz Sk8erPeter #16470 üzenetére
Persze ha már hordozható kódról van szó meg útvonalakról, akkor érdemes megemlíteni a php előredefiniált DIRECTORY_SEPARATOR konstansát, ami az adott rendszeren az érvényes elválasztó - még ha a "/" nem is okoz gondot mindenhol.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
Sk8erPeter
nagyúr
válasz disy68 #16473 üzenetére
Igen, a DIRECTORY_SEPARATOR atombiztos megoldás, de mivel Windows-on is nyugodtan lehet használni a forward slash-t (/) az elérési útvonalaknál (attól még, mert Windows esetén a backslash (\) a bevett konvenció), ezért nem biztos, hogy megéri vele szenvedni (pl. ronthatja az olvashatóságot). Tudsz mondani olyan esetet, ahol a forward slash használata elvérezne?
(Windows+IIS alatt én még nem találkoztam ilyen esettel (vagy csak nem emlékszem ), de ettől még lehet.)(#16471) fordfairlane:
Ja igen, az végül lemaradt, köszi a kiegészítést.
Mondjuk azért az esetek nagy részében a feltöltött kép elég közeli viszonyban van a konkrét webalkalmazással, szóval a webalkalmazás rootjához képest relatív útvonal talán az esetek többségében talán egy fokkal használhatóbb.(#16472) PumpkinSeed :
Mi az, hogy "más lehetőséget oda nem tudok elképzelni"? Ezt mire írtad?
"uploaded_img/-el kezdtem"
Az épp futtatott szkripthez képest az uploaded_img könyvtár elérhető volt, jól adtad meg az útvonalat? Oda tudsz bármit is írni? Pl. csak próbából file_put_contents() segítségével tudsz egy akármilyen fájlt létrehozni a célkönyvtárba?[ Szerkesztve ]
Sk8erPeter
-
PumpkinSeed
addikt
válasz Sk8erPeter #16474 üzenetére
Warning: file_get_contents(uploaded_img/people.txt): failed to open stream: No such file or directory in /var/www/img_share/upload.php on line 62
Warning: move_uploaded_file(): The second argument to copy() function cannot be a directory in /var/www/img_share/upload.php on line 63
Warning: move_uploaded_file(): Unable to move '/tmp/phpSohzUi' to 'uploaded_img/' in /var/www/img_share/upload.php on line 63Ezeket kapom. De a mappa jogosultsága most kb úgy néz ki, hogy nobody, nogroup, 777...
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16475 üzenetére
Az utóbbi két hibaüzenet alapján elég egyértelmű: a $file_name változód üres. A $target = $target.$file_name; soroddal tehát ez esetben olyan, mintha azt írtad volna, hogy $target = target;, mivel nem fűztél hozzá semmilyen nevet (így marad a könyvtárnév). Így nem csoda, hogy nem tudja mozgatni.
Az első hibaüzenet meg csak annyit mond, hogy nem létezik uploaded_img/people.txt fájlod... Az igazából nem tudom, hogy jött ide, a lényeg az volt, hogy a célkönyvtárba tudsz-e írni. (file_put_contents() használatát javasoltam) Gondolom valóban nem létezik a people.txt fájl, vagy még mindig rosszul adod meg az elérési útvonalat... Ez esetben nem ártana, ha elmondanád, hogy milyen a könyvtárszerkezet (mi hol van), akkor még meg is tudnánk mondani, mit rontasz el.
[ Szerkesztve ]
Sk8erPeter
-
PumpkinSeed
addikt
válasz Sk8erPeter #16476 üzenetére
A $file_name kiíratásakor pedig megvan a feltöltött fájl neve. és mikor kiírom a $target-et akkor pedig kiírja a teljes "cuccot".
Igazából tényleg nem létezik, csak copy-ztam egy ilyen függvényt gyorsba. Amúgy úgy nézz ki, hogy a www mappában van az im_share mappa, majd ebben a .php állományok illetve a css mappa, uploaded_img mappa és profil_img mappa. Az uploaded_img mappa tartalmát az img_share mappában lévő .php fájlokból akarom szabályozni. Szóval szerintem a uploaded_img/ elérési útvonal helyes.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
tothjozsi96
addikt
válasz Sk8erPeter #16465 üzenetére
Én azt mondtam hogy nem teljesen olyan, de hasonló.
Az enyémben nincs preg_replace, főleg nem preg_match, csak tömbökből kinyert adat, aztán str_replace.[ Szerkesztve ]
-
tothjozsi96
addikt
Egy kérdés.
Mit érdemes szerintetek cookie-ban tárolni?
Nem tudom mennyire lenne ajánlott egy olyan beléptető rendszer ami SESSION alapú és naponta kb. 1.000 felhasználó lép ki/be.Mit lenne érdemes alkalmaznom?
Jelenleg úgy van megoldva hogy 1 generált hash-t tárolok.Előtte a felhasználó ID-je és a password md5-je volt tárolva.
Nem tudom mi ajánlott, mivel nagy oldal.
-
DNReNTi
őstag
válasz tothjozsi96 #16479 üzenetére
Én felhasználó beléptetésre mindenképp a session-t javaslom. Ha pedig engedélyezed, az "emlékezz rám" (ne lépjek ki ha bezárom a böngészőt) funkciót, akkor a kettő kombinációja. Ez esetben jó egy unique hash sütiben ami alapján be tudod léptetni a felhasználót. Sütiket szerintem csak "nem globális" beállítások tárolására érdemes használni, pl mondjuk az előbb említett "emlékezz rám". Továbbá ne felejtsd el, hogy most már fel kell hívd a felhasználók figyelmét arra, hogy sütiket használsz, és mielőtt használod őket, ezt ők el kell fogadják.
but without you, my life is incomplete, my days are absolutely gray
-
fordfairlane
veterán
válasz tothjozsi96 #16479 üzenetére
Ha a felhasználó munkamenetével kapcsolatos adatokat akarsz tárolni, akkor az általánosan bevett megoldás az, hogy a kliensnél egy egyedi, véletlengenerált azonosítót tárolsz, pl. hash formájában, minden más adatot a szerveren. A hash azonosítja a klienst minden egyes requestnél, így a többi adat hozzárendelése szerveroldalon könnyedén megoldható. PHP-ban erre való a beépített session-kezelő.
[ Szerkesztve ]
x gon' give it to ya
-
sztanozs
veterán
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ó
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
tothjozsi96
addikt
Csak mert sok helyen nem ajánlották ezt a Session-t, a szervert darálja.
Ezt hallottam ... -
fordfairlane
veterán
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16477 üzenetére
Jó, és a tanácsokat elolvastad, hogy hogyan javítsd ki az útvonalat? Akár relatív útvonalakat használva a webalkalmazáshoz, akár $_SERVER['DOCUMENT_ROOT']-ot felhasználva. Nyilván amíg az elérési utat nem javítod ki, és még egy egyszerű tesztcélú fájlírás sem működik a célkönyvtárba, addig hiába megy az oda-visszaírogatás.
Amúgy meg kéne tanulni az Xdebug használatát, nem pedig kiírogatni, hogy épp milyen a változó értéke, hanem normálisan debuggolni, arra találták ki, hogy egyszerűbb legyen a fejlesztés, és az ember rájöjjön a hibáira. Korábban is javasoltam, a kolléga igen gyorsan rá is jött, hogy kell használni. Követhetnéd a példáját, és akkor menetközben kapásból látnád, milyen útvonalakra próbál írni, az egyes visszatérési értékeket pedig korrektebb módon ellenőrizhetnéd.
Azt sem ártana tudni, milyen HTML-kód van a frontenden. Pl. a mező neve (name attribútum) valóban egyszerűen "file"? Hogy néz ki akkor a most használt, komplett kódod (miután elvileg javítottad)?(#16483) tothjozsi96 :
Hol olvastad ezt a hülyeséget? Nem árt megnézni, az ember milyen forrásokból tájékozódik, és milyen fórumos kommentárokat vesz komolyan.(#16478) tothjozsi96:
Akkor már végképp nem értem, most épp milyen kódról beszélsz, mert
ez a kód, amit ide bemásoltál, tele van preg_match-csel és preg_replace-ekkel.[ Szerkesztve ]
Sk8erPeter
-
tothjozsi96
addikt
válasz Sk8erPeter #16485 üzenetére
"Elég rosszul van megírva, de mutatok egy examplet. "
Itt úgy értettem hogy ez nem pont az enyém, az sokkal hosszabb, de nincs benne preg_match.
Tehát a str_replace részek a megegyezőek csak, nagyjából ennyi.
Köszi.[ Szerkesztve ]
-
PumpkinSeed
addikt
válasz Sk8erPeter #16485 üzenetére
Elnézést a késői reakciót, működik. A Linuxos jogosultságok beállítása mellett még annyi hiba volt, hogy a php.ini-ben a feltöltött fájl max mérete 1MB-ra volt állítva, amit úgy tudtam meg, hogy a $_FILES['file']['error']-al tudtam meg.
A kód most így néz ki:
$target= "uploaded_img/";
$file_name = $_FILES['file']['name'];
$tmp_dir = $_FILES['file']['tmp_name'];
if(!preg_match('/(jpe?g|png)$/i', $file_name))
{
$error_msg = 1;
}
else
{
$target = $target.$file_name;
move_uploaded_file($tmp_dir,$target);
}[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
tothjozsi96
addikt
válasz Sk8erPeter #16485 üzenetére
És szerinted milyen egy biztonságos session?
Olvastam olyant hogy ajánlott a session_id-t elmenteni cookie-ban külön, és ha nem egyezik akkor kiléptet az oldal.
Mint biztonsági elemként nem rossz szerintem.De session-al nem volt még dolgom, azt tudom róla hogy a böngésző bezártával törlődik és újra be kell jelentkezni.
-
wis
tag
válasz tothjozsi96 #16488 üzenetére
A PHP alapból tartalmaz session kezelőt, neked a session cookie-val nem kell foglalkoznod közvetlenül.
Próbáld ki a példákat és figyeld meg, hogy létrejön a böngészőben a PHPSESSID cookie.Ha szeretnéd, hogy a böngésző bezárása után törlődjön akkor a session_set_cookie_params függvényben az első paraméter legyen 0.
-
tothjozsi96
addikt
Aha, nézegetem.
De még mindig nem értem hogy ez mitől is lesz biztonságosabb mint egy $_COOKIE.Az igaz hogy a kliens gépén nincs tárolva "szó szerint" az adat, szóval passhash meg ilyesmi, de mitől jobb?
Megnéztem az alapvető kulcsok működését, nem túl bonyolult.
Tehát egy login-t feltudnék építeni elég egyszerűen.[ Szerkesztve ]
-
wis
tag
válasz tothjozsi96 #16490 üzenetére
Ugyanolyan "biztonságos", hiszen ez a megoldás is cookie-t használ.
A kliens gépén az egyedi session azonosító tárolódik amit minden kéréskor elküld a szervernek.
Ehhez az azonosítóhoz szerver oldalon társíthatod azt az információt, hogy pl. be van-e lépve.Miért tárolnád a passhash-t cookie-ban? Milyen kulcsok működését nézted meg?
-
tothjozsi96
addikt
Igazából oké hogy COOKIE-ban tárol ez is de más, mivel több kulcsot tárol egyben.
De ez így lehet hogy jobb is, mivel nekem kettő dolog fő a tároláshoz, igazából az egyik a felhasználó ID-je a másik pedig a jelszava megkeverve valamivel, még nem tudom mivel ...
Tehát md5($valami.$password.$valami);De a COOKIE-nál ki lehet olvasni a böngészőből, itt pedig nem tehát biztonságosabb az biztos.
Kérdés hogy SQL injektálás szempontból milyen lesz majd. -
DNReNTi
őstag
válasz tothjozsi96 #16492 üzenetére
"Kérdés hogy SQL injektálás szempontból milyen lesz majd."
Wat?"nekem kettő dolog fő a tároláshoz, igazából az egyik a felhasználó ID-je a másik pedig a jelszava megkeverve valamivel"
Wat? Miért kellene ezeket tárolnod? Miért nem elég mondjuk egy minden helyes loginnál generált unique hash, amely alapján azonosíthatod a felhasználót, és 100% biztonságban csak szerver oldalon kezelnéd az id-t jelszót, stb-t?but without you, my life is incomplete, my days are absolutely gray
-
wis
tag
válasz tothjozsi96 #16492 üzenetére
Nem. Ne tárolj felhasználó adatokat cookie-ban semmilyen formában. Amennyiben szükséged van a felhasználó nevére vagy azonosítójára, azt rakd bele a $_SESSION tömbbe. Pl. $_SESSION['user_id'] = $user_id;
-
DNReNTi
őstag
válasz tothjozsi96 #16494 üzenetére
Jaja, pontosan. Sot ha uberbiztonsagos akarsz lenni a loginok kezelesre kulon tablat hozol letre, nem pedig a felhasznalo tablajaban tarolod. Ez mondjuk szvsz egy sima weboldal eseteben mar agyuval a verebre kategoria.
but without you, my life is incomplete, my days are absolutely gray
-
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy van egy ilyen rész:
$title = isset($title) ? ($SITE["name"] . " :: " . $title) : ($SITE["name"]);Na most, az $title adja meg az oldal címét.
Tehát Oldal neve :: Lap címeDe hogyha úgy hívom meg a függvényem hogy fuggveny(""); tehát nem adom meg a title részt akkor is kiírja a ::-ig de ez így nem jó, tudom hogy if-el meglehet oldani de így érdekelne.
A php.net-en azt írják és tapasztaltam is hogy az isset(trim()) nem működik, de máshogy meglehet oldani?
Érdekelne ez a megoldás, if-el megtudom csinálni csak na.[ Szerkesztve ]
-
moltam88
tag
válasz tothjozsi96 #16497 üzenetére
isset() helyett !empty() -t használj. Az empty() true-t ad vissza, ha a változó nem létezik, vagy üres a tartalma (konkrétan false-al való egyezőséget vizsgál).
Bővebb leírás PHP.net-en.
-
tothjozsi96
addikt
Egy kérdés.
Ez mitől van hogy UTF8 BOM nélkül van beállítva a notepad és a html charset ISO-8859-2 és karakterhibás ami megjelenik ...
Új hozzászólás Aktív témák
- Debrecen és környéke adok-veszek-beszélgetek
- Futott egy Geekbench kört egy új HTC készülék
- Apple notebookok
- Anime filmek és sorozatok
- gban: Ingyen kellene, de tegnapra
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- DIGI kábel TV
- Premier előzetesen a Gray Zone Warfare
- Windows 10
- További aktív témák...