Új hozzászólás Aktív témák
-
mallee
tag
válasz
DNReNTi
#15478
üzenetére
Egy kicsit kritizálok, ha nem baj
Configuration
Az osztálynak van konstruktora, amely az általad linkelt kódokban sehol sem kerül meghívásra. Ezenfelül csak statikus változót és metódust tartalmaz, nem értem a szándékodat. Vagy legyen statikus osztály (inkább ne) vagy ne legyen az (inkább ez).Database_Connection
Továbbra is végez felesleges dolgokat, lásd ini_set. És hiába nem akarod, hogy belekössünk, bele fogunk
A display_errors amúgy is legyen kikapcsolva, a hibákat nem kiíratni kell, hanem loggolni.
A die() helyett hagyd az exception-t "felbuborékozni" és egy másik szinten kezeld le a hibaoldalt.Database
őőő, ez így nem az igazi szerintem. De majd később kifejtem.Amúgy összességében jó irányban halad a dolog, de még sokat kell ezen dolgozni
-
#15469
csabyka666
veterán
DNReNTi
#15468
-
#15467
csabyka666
veterán
DNReNTi
#15465
-
#15460
csabyka666
veterán
DNReNTi
#15459
-
#15453
csabyka666
veterán
DNReNTi
#15451
válasz
DNReNTi
#15451
üzenetére
Köszi, ez szép és jó, de ahogy a leírás is említi, hogy nem kell vacakolni az escape-léssel, azért jó az "i" - én is ezzel győzködöm magam. Szóval én inkább vacakolok, nem akarom az egész projektet átírni.
Aki gyakorlott a témában, annak biztos nem akkora feladat ez, de én még csak abban a fázisban vagyok, hogy örülök, ha működik a kód (amit mellesleg, igaz, sokat fórumoztam miatta, de végülis én írtam, ez nagy szó ám
), szóval nem nagyon akarok mélyebben belenyúlni.
Az escape-lés mellett ellenőrzöm még a bevitt string hosszát, üres stringet nem postolok, több helyen is mintára illesztem a bevitt adatot, valamint az adatbázisban is le van korlátozva karakterhosszra a bevitel maximuma. Erre még rápakolom a mysql_real_escape_string()-et, és ha nem is atombiztos ez a megoldás, a semminél mégiscsak több...MOD: és igen, nyilván nem ez a világ legbiztonságosabb megoldása, de nekem az elsődleges cél, hogy működjön a kód. Ezt elértem, szóval a többi már csak "extra", persze ettől még ugyanúgy fontos.
-
mallee
tag
válasz
DNReNTi
#15427
üzenetére
de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra
Hirtelen ezek a megoldások jutottak eszembe erre:
1. Használj autoload-ot és a konfigurációs beállításokat egy osztályba tedd, pl Config_Database. Ez még mindig nem szép megoldás, de a problémát feloldja.
2. Biztos van valamilyen inicializáló, közös része az alkalmazásodnak, ahol be tudod olvasni a konfigurációt és be tudod állítani a Database_Connection statikus mezőit. Ehhez azonban a láthatóságot át kell állítanod. Ez már egy egészen jópofa megoldás kezd lenni, viszont ebben az esetben koncepcionálisan rossz a Database_Connection osztályod.
3. Van egy osztályod, ami a konfigurációt kezeli (beolvassa a megfelelő helyről) és tőle lekérdezi a Database_Connection osztály a megfelelő értékeket. Ez már szép megoldás is lehet, megvalósítástól függ.
4. Van valamilyen osztályod, amely a függőségeket kezeli, pl eltárolja a Database objektum referenciáját és ahol adatbázissal akarsz foglalkozni, ott ettől az osztálytól kérdezed le a Database objektum referenciáját. Ennek egy nagy hibája, hogy eléggé központosított lesz a kód, túlzottan erős lesz a szerepe ennek az osztálynak, minden tőle fog függeni.Úgy gondoltam egy osztály marad a lekérdezések kezelésére, csak több metódus lesz. Lesz egy private, ami ellenőrzi a lekérdezés helyességét, a paramétereket, stb, valamint query típusonként 1-1 metódus.
Ez elég szép megoldásnak hangzikA többit már elmondták előttem, várjuk az új verziót
-
#15437
Sk8erPeter
nagyúr
DNReNTi
#15427
Sk8erPeter
nagyúr
válasz
DNReNTi
#15427
üzenetére
"Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt."
Te ezt írtad:error_reporting(0);
$DB_Connect = new mysqli(self::$DB_Host, self::$DB_User, self::$DB_Pass, self::$DB_Name);
if ($DB_Connect->connect_error) {
echo 'Database connection failed. Code : ' . $DB_Connect->connect_errno;
}
$DB_Connect->set_charset(self::$DB_Char);
error_reporting(1);Tehát fogod, és 0-ra, majd 1-esre állítod az error_reportingot.
Egyrészt eleve milyen alapon nyúlkál az osztályod az error_reporting értékéhez, minek? Az ilyesmit felejtsd el gyorsan. A kód ne csináljon többet az elvártnál.
Másrészt sztem te az error_reporting()-ot a display_errors értékével kevered.
Harmadrészt miért állítod be az error_reporting szintjét pont az E_ERROR-ra? Az error_reporting(1); ugyanis ekvivalens azzal, ha azt írod, hogy error_reporting(E_ERROR); Mi van, ha korábban az error_reporting értéke szándékosan E_ALL-ra volt állítva, ami 32767? (Itt láthatod az értékeket.)"»»"Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
Az előzőben benne a válasz. Élesben egy hibaoldalra dob."
Hát ez eleve rossz megközelítés. Most akkor itt echo-zol, de aztán majd élesben átírod normális hibakezelésre? Ez így nem lesz jó. Az ilyenből tuti, hogy az lesz, hogy tesztelésnél nem jelentkezik semmilyen hiba, tök jól működnek a dolgaid, aztán majd élesben jöhet a gebasz, és akkor szépen kiírtad a képernyőre a hibaüzenetet, ahelyett, hogy eleve normálisan kezelted volna a hibákat, már amikor megírtad a kódot.
Jótanácsként mondom, ne szopasd magad azzal, hogy "hát ezt majd átírom", mert úgyis elfelejted, vagy pedig később csak macerás lesz megcsinálni.
Szóval az echo-zás helyett dobj szépen egy exceptiont, hiszen komoly hiba, ha nem tudtál csatlakozni az adatbázishoz.A többit asszem mallee már leírta, például hogy tök értelmetlenek az if-else-be rakott exception-dobásaid.
Pont azért jó, hogy tudsz dobálni exceptionöket, mert elkerülheted az ilyen ocsmány if-else szerkezeteket. -
TomyLeeBoy
tag
válasz
DNReNTi
#15435
üzenetére
Na hát az itt latin1_swedish_ci, de akkor jelenik meg jól ha az oldalt utf8-ra állítom, csak akkor meg az oldal esik szét :/
Szerk: Azt még csak megértem hogy az adatbázisból olvasott adatoknak nem mindegy, de egy akármilyen áéőöüó utf8-ra kódolt php lapon generálvi miért ??-eket jelenít meg?
Mert így az adatbázisból olvasott adatok jók, csak a kézzel az oldalba írtak helyén van kérdőjel. -
mallee
tag
válasz
DNReNTi
#15412
üzenetére
Gondolatébresztők:
Database_Connection
private static $DB_Host = ........: Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak.
error_reporting(0);: Miért kezel az adatbázis osztályod error reportolást? Mi köze van a kettőnek egymáshoz? (azon túl, hogy az adatbázis-kapcsolat felépítése esetén is jöhet hiba). Ennek inkább egy inicializáló, környezetet beállító, stb php-ben kellene lennie
echo 'Database connection failed. Code : ' . $DB_Connect->....; Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább, noha ő arra számított, hogy lesz adatbázis-hozzáférése. Ehelyett használj exception-t
Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?
Database
Hát ez így nagyon nem jó. Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján, pl Database_Select_SQL valósítaná meg a selectes logikákat, Database_Insert_SQL az inserteset, stb. Ezzel elkerülhetnéd azt a csúnya és nehezen értelmezhető switch-case szerkezetet. Egyébként bár látom, hogy mi akar az osztály célja lenni, mégis nagyon rosszul olvasható a kód. A sok egymásba ágyazott if-else throw exception megoldás helyett inkább azt kéne vizsgálnod a feltételben, hogy sikertelen volt-e a végrehajtás: ha így van, akkor exception, egyébként fusson tovább a kód, pl:
$stmt = $this->_DB_Connect->prepare($SQL_command);
if ($stmt === false) { throw new Exception("blablabla"); }
$parameter_type_list = '';
foreach($SQL_parameters as $parameter) {
és nincs utána else!Ez sem tökéletes megoldás, de átláthatóbb a kevesebb egymásba ágyazott szerkezet miatt.
-
#15415
csabyka666
veterán
DNReNTi
#15414
-
#15352
Sk8erPeter
nagyúr
DNReNTi
#15351
Sk8erPeter
nagyúr
válasz
DNReNTi
#15351
üzenetére
Nincs 3 másodperc, lásd Quick JavaScript Switcher ([link])
Ahogy elnézem, most csak annyi a feladat, hogy az adott URL-en PHP-vel jelenít meg MySQL-adatbázisból egy nagyon egyszerű adatot, és lényegében ennyit kell tudnia annak az oldalnak. Szóval itt nagy biztonsági rések nincsenek, főleg, hogy már PDO-t használ prepared statementekkel, így már az SQL Injection veszélye is elhárult, ettől függetlenül ronda, ha nem kezeli le azt az egyetlen hibalehetőséget, ami két sor lenne.
Az is kérdéses, miért nem inkább az Android-alkalmazásból kapcsolódik közvetlenül a MySQL-adatbázishoz (beállítás kérdése, engedélyezünk-e távoli kapcsolódást), ami ezek szerint localhoston van; inkább a közvetlen hidat teremteném meg a kettő között, nem pedig egy "harmadik szereplőt" vezetnék be, de végül is így is lehet. -
#15288
trisztan94
őstag
DNReNTi
#15287
trisztan94
őstag
válasz
DNReNTi
#15287
üzenetére
Csórt kód.
Nyilván nem ezt használnám élesben, de sehogy sem megy.Most kicsit egyszerűbb kóddal próbálkozom:
if(!empty($_FILES['xls'])) {
echo '<pre>',print_r($_FILES,1),'</pre>';
}
else {
die('POST ÜRES');
}Ezt dobja a print_r():
Array
(
[xls] => Array
(
[name] =>
[type] =>
[tmp_name] =>
[error] => 4
[size] => 0
)
)Fogalmam sincs, hogy mi az a 4 error.
-
cucka
addikt
válasz
DNReNTi
#15266
üzenetére
Az első ciklusban érték szerinti értékátadást használsz a ciklusban. Ez úgy működik, hogy az $uj_tomb[0] értéke a $regi_tomb[0] értékének másolata. Tehát a háttérben egy darab memória tartalmát átmásolja egy másik memóriaterületre.
A második ciklusban referencia szerinti értékátadás történik. Ez úgy működik, hogy az $uj_tomb[0] semmi más, csak egy új név ugyanarra a memóriadarabra, amire a $regi_tomb[0] is mutat. Lényegében ez egy alias. Ha az egyik értékét módosítod, a másik is módosul. A memória, amire mutatnak, csak akkor fog felszabadulni, ha mindkét változót törlöd (unset) - ez fasza memory leak forrás, oda kell rá figyelni.
A harmadik ugyanaz, mint a második, csak for helyett foreach ciklussal. Többnyire ezt érdemes a for ciklus helyett használni.
Ja, és az ne zavarjon meg, hogy a tömbök 0. elemével írtam a példát, a fentiek bármilyen változóra igazak. Továbbá z objektumok érték szerinti átadása totál máshogy működik.
-
#15235
Sk8erPeter
nagyúr
DNReNTi
#15223
Sk8erPeter
nagyúr
válasz
DNReNTi
#15223
üzenetére
Bizony, minden alkalommal, amikor ilyen kódot osztasz meg, God kills a kitten.
"Hogyan lehetne másképp?
"
Úgy, hogy prepared statementeket használsz.
Meg a SELECT * FROM ... sem egy jó szokás, ne az legyen az alap, hogy minden mezőt lekérünk, mert az teljesítményromlással is jár, hanem soroljuk fel szépen azokat a mezőket, amikre szükségünk van.
Nem beszélve az elgépelésekről, de az mondjuk a legkisebb gond.
(#15225) :
"Hüm. Ha esetleg a prepared statements-re gondolt akkor amiatt nem kell aggódni, ahol kell azt használom"
Jogos volt cucka korábbi kérdése, hogy hol nem kell."csak PDO helyett mysqli-t. Itt a példában nem akartam még azzal is karatézni. De jogos."
Teljesen mindegy, hogy PDO vagy mysqli (ez egyben válasz (#15224) mobalnak is), a lényeg a prepared statement volt.
Az pedig szerintem nem jó hozzáállás, hogy a kezdőnek jó lesz szarul is prezentálni, de mi közben a saját fejlesztéseink során jól használjuk. A kezdő ne tanuljon meg rossz példákat. Most pedig nyilvánvaló, hogy az alapján csinálta meg, amit te mutattál neki...
(#15232) :
"Például olyan metódusokban nem szoktam használni ahol a szerver oldal ad át ellenőrzött paramétert, mondjuk egy user_id-t, azaz garantáltan nem jelent veszélyt."
Uhh, ez rossz megközelítés, ezt inkább felejtsd el, nincs olyan, hogy "garantáltan nem jelent veszélyt"... de látom ezt közben cucka kifejtette.(#15231) laceeeboy :
Ismerjük az atw.hu-t, komolytalan. Felejtős. -
cucka
addikt
válasz
DNReNTi
#15232
üzenetére
Például olyan metódusokban nem szoktam használni ahol a szerver oldal ad át ellenőrzött paramétert, mondjuk egy user_id-t, azaz garantáltan nem jelent veszélyt.
És mi van, ha újra szeretnéd hasznosítani azt a metódust? Vagy csapatban dolgozol és a másik ember szeretné használni a metódusaidat? És ha mondjuk egy 1 év múlva lesz, amikor már nem emlékszel pontosan, hogy mely metódusokba építettél biztonsági lyukat lustaságból? -
#15233
fordfairlane
veterán
DNReNTi
#15232
-
-
#15226
fordfairlane
veterán
DNReNTi
#15225
fordfairlane
veterán
válasz
DNReNTi
#15225
üzenetére
Ha esetleg kényelmetlennek tartod a prepare-bind-execute használatát, ajánlom a Doctrine DBAL-t, ott van egy olyan metódus, hogy executeQuery. Egyébként erre sokan csináltak saját, PDO-ból örökölt osztályt, amiben egyetlen metódushívással helyettesítik ezt a három műveletet.
-
laceeeboy
tag
-
#15185
csabyka666
veterán
DNReNTi
#15183
-
#15178
PumpkinSeed
addikt
DNReNTi
#15177
PumpkinSeed
addikt
válasz
DNReNTi
#15177
üzenetére
Amúgy soha nem értettem ezt, hogy miért nincs. Most ahova kerültem céghez első dolgom volt a chrome telepítése minden gépre illetve a jogtiszta szoftverekre való csere.
Az átállás nem hogy negatívumokat, hanem egyenesen pozitív visszajelzéseket mutatott. Egy nagyobb cégnél se lehet olyan bonyolult és hosszabb távon jobb választás is.
-
#15175
csabyka666
veterán
DNReNTi
#15173
-
#15172
trisztan94
őstag
DNReNTi
#15168
trisztan94
őstag
válasz
DNReNTi
#15168
üzenetére
Én már futottam bele céges intranetre szánt megrendelésnél abba, hogy miután leadtam kb. rögtön hívtak, hogy az ékezetes betűk viccesen jelennek meg. Kiderült, hogy FF2.0 és IE6-hoz vannak kötve, ami nem támogatja a HTML5-öt. És persze a helyi rendszergazda nagy arrogánsan csak annyit írt: "Megoldottam, ezt a varázslatos sort hagytad ki az oldalból: --html4 charset -- Legközelebb figyelni kellene erre."
Azóta amikor eszembe jut, mindig a HTML4-es UTF-8 karakterkódolást adom meg a biztonság kedvéért. -
#15171
csabyka666
veterán
DNReNTi
#15170
válasz
DNReNTi
#15170
üzenetére
Köszi!
Egyébként valószínűleg az volt a hiba, hogy a böngésző és az adatbázis karakterkódolása nem egyezett meg, mert ha úgy csinálom, ahogy mondtátok, akkor az újak jók, de a régiek nem, ha pedig a régiekhez odaírom a konverziót(?), akkor azok jók lesznek, viszont az újak nem...
-
#15169
csabyka666
veterán
DNReNTi
#15168
-
#15167
csabyka666
veterán
DNReNTi
#15166
-
#15165
csabyka666
veterán
DNReNTi
#15161
-
#15154
csabyka666
veterán
DNReNTi
#15148
-
#15152
csabyka666
veterán
DNReNTi
#15148
-
#15007
Sk8erPeter
nagyúr
DNReNTi
#15005
Sk8erPeter
nagyúr
válasz
DNReNTi
#15005
üzenetére
Itt próbáld meg: WordPress topic.
-
#14950
Tele von Zsinór
őstag
DNReNTi
#14948
-
#68216320
törölt tag
válasz
DNReNTi
#14637
üzenetére
Az a helyzet, hogy az 500 karakter a maximum. Tehát, ha nem mondatvégi írásjel (.!?") akkor visszafele kellene néznem a dolgokat. olyat már meg tudtam csinálni, hogy explode-al szétbontottam az 500 karaktert a szóköz segítségével és az utolsót nem számoltam, így biztosra mentem, hogy nem szó közben vágom el. A te módszereddel, a hozzáfűzéssel az a baj, hogy vannak a szövegben szakmai részek, amik elég kerek mondatok és akár +200 karaktert is jelenthetnek könnyedén. ennyi hely nincs a div-ben, ahova menne a szöveg. Így is trükköznöm kellett, hogy a spec HTML részeket (pl. <br />) eltüntessem strip_tags()-al.
Gondban vagyok még a " (idézőjel) karakterrel, mert ha egy mondat abban van akkor nem elég a mondatvégi írásjel, hanem az is kell még. Ha nem fér bele az idézőjelek közti rész az 500 karakterbe az egészet ki kellene hagynom. -
#14181
Sk8erPeter
nagyúr
DNReNTi
#14179
Sk8erPeter
nagyúr
válasz
DNReNTi
#14179
üzenetére
Most nézem, hogy átsiklottam az előtte írt "Másrészt szerintem ilyen feltételeknél nem célszerű a '===' használata mert például ha ez a helyzet:" mondatrészen, és amit idéztem, emiatt totál az ellenkezőjét jelentette. Szóval nem volt kellően egyértelmű.
(#14180) PumpkinSeed :
szívesen. -
#14176
Sk8erPeter
nagyúr
DNReNTi
#14172
Sk8erPeter
nagyúr
válasz
DNReNTi
#14172
üzenetére
"$elso = 6;
$masodik = '6';
Akkor ez egyenlőtlenség lesz, mivel a $masodik egy string típusú változó, hiába 6 az is, de szöveg nem szám. Ezt megelőzendő perfekt a sima == kifejezés."Pont a lehető legrosszabb példát írtad, mert ez úgy, ahogy van, nem igaz.
Ebben az esetben az if($elso == $masodik) pont, hogy IGAZ lesz, mivel castolódik.
Éppen itt jön a képbe az, hogy csak az if($elso === $masodik) (lásd három egyenlőségjel, típusvizsgálattal) lesz csak HAMIS. -
#14175
PumpkinSeed
addikt
DNReNTi
#14174
-
#14032
Sk8erPeter
nagyúr
DNReNTi
#14029
Sk8erPeter
nagyúr
válasz
DNReNTi
#14029
üzenetére
"A require() a szigorúbb. Betölti a fájlt abban az esetben is ha az egy nem teljesülő feltételben van"
Az lehetetlen.A többi amúgy stimmel, a lényeg nagyon röviden, hogy az include a fájl hiánya vagy más para esetén warningot okoz, a require fatal errort, a _once végű függvények pedig ugyanezt csinálják, csak annyi különbséggel, hogy valóban csupán egyszer töltik be a megadott fájlt.
(#14028) Petyyyyy
"Az egyikük minden alkalommal betölti az adott fájlt, a másik csak akkor, ha szükség van rá."
Az include_once(), require_once() függvényekre gondolsz, de ez így nem pontos, hogy csak akkor tölti be, ha szükség van rá, inkább akkor tölti be a fájlt, ha még korábban nem töltötte be (ergo mindenképp "szükség van rá", ha a kódban ezt mondod, de nem mindegy, hányszor).=============
Szerk.:
(#14031) kenwood :
ja, hogy így, OK. -
bolvar
senior tag
válasz
DNReNTi
#13598
üzenetére
Igen mi is így vagyunk vele
.Igen meglepő volt mikor mac-ről megpróbáltuk használni az appot és ez fogadott az adatbázisban .És időnként még dupla id-val is tudnak emberek regelni(szóval hiába van id rögzítve újra tud regelni gondolom, mert 2x jelenik meg az adatbázisban) de ez kb 100-ból 1-2-t jelent. -
bolvar
senior tag
válasz
DNReNTi
#13595
üzenetére
Nem azt nem tároljuk ki mire szavazott mert az nem lényeg hanem hogy ki szavazott csak simán.Erre úgy láttuk a face id mentése a legegyszerűbb de bizonyos böngészők használata esetén nem menti ezt.Mert ha valaki szavazott rögtön az első oldalon ezt megvizsgáljuk és ő már csak az eredményekre tud továbblépni szavazni újra nem
.Vagyis a cél ez lett volna Tele von Zsinór
Köszi megnézem
A display_errors amúgy is legyen kikapcsolva, a hibákat nem kiíratni kell, hanem loggolni.
Eggyel feljebb olvashatod.
Új hozzászólás Aktív témák
Hirdetés
- Óra topik
- Az áremelések és a GTA VI késése miatt nem költekeznek a játékosok?
- TCL LCD és LED TV-k
- Milyen házat vegyek?
- Gaming notebook topik
- Nintendo Switch 2
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Raspberry Pi
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Kazy Computers - Fehérvár - Megbízható?
- További aktív témák...
- Használt gamer/ workstation laptop felvásárlás TÉNYLEG magas áron!
- Intel Core Ultra 7 265 /// Bontatlan, Teljesen Új // Üzletből, Számlával és Garanciával
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Újszerű Gamer Asztali PC Számítógép 2026-ig Garis ASUS H510M-K R2.0 i5 11400F RTX 4060 8GB Dobozába
- Samsung Galaxy Tab A8 (2021) , 3/32 GB,
- BenQ PD-3200-U Monitor - Designer 4K 32"
- Bomba ár! Dell Latitude 5500 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- BESZÁMÍTÁS! AMD FX-8320 8 mag 8 szál processzor garanciával hibátlan működéssel
- DELL PowerEdge R740 rack szerver - 2xGold 6130 (16c/32t, 2.1/3.7GHz), 64GB RAM, 10Gbit HBA330, áfás
- Bomba ár! HP Elitebook 850 G3 - i7-6GEN I 16GB I 256GB SSD I RadeonI 15,6" FHD I Cam I W11 I Gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest