- sziku69: Fűzzük össze a szavakat :)
- ricshard444: Fényképező ? Telefon helyett
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Yutani: Yutani Retró Hangkártyái: OAK Mozart Wavetable
- Meggyi001: Egy olcsó vállfás megoldás a pólóimnak...
- VoidXs: Tényleg minden játék optimalizálatlan?
- sziku69: Szólánc.
Új hozzászólás Aktív témák
-
Vladek83
tag
Sziasztok!
Elakadtam egy kicsit, nem tudom mit írtam rosszul....
Nem adja vissza a mysql-ből az értékeket... Valakinek lenne ötlete?
Előre is köszönöm.<?
$parancs = "SELECT * FROM kigyujtes";
$eredmeny = mysql_query($parancs);while ($sor = mysql_fetch_array($eredmeny)) {
?><tr>
<td><?= $sor["cikkszam"] ?></td>
<td><?= $sor["db"] ?></td>
<td align=center>
<a href="">Módosítás</a>
<a href="">Törlés</a>
</td>
</tr>
<?
}
?> -
#15498
cucka
addikt
DeltaPower
#15493
cucka
addikt
válasz
DeltaPower
#15493
üzenetére
Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt...
Jelszónál is érdemes. El sem hinnéd, hogy hány 1bites felhasználó van, aki a generált jelszót kézzel írja át, nem kopipészteli.
Amit érdemes kiszedni: 0,1 számjegyek, L, O, I betűk (kicsi és nagy) és p,q betűk.Ez a kód amúgy olyan, mint ha a "legszarabbul megírt jelszógeneráló függvény" versenyre készült volna. Nem működik, olvashatatlan, tesztelhetetlen és legalább még lassú is.
-
#15497
DNReNTi
őstag
Sk8erPeter
#15496
DNReNTi
őstag
válasz
Sk8erPeter
#15496
üzenetére
Igen, éppen az a program.
-
#15494
Sk8erPeter
nagyúr
DeltaPower
#15493
Sk8erPeter
nagyúr
válasz
DeltaPower
#15493
üzenetére
"Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt..."
Jogos, hogy emiatt lehet, ez már valahogy fél 3-kor eszembe se jutott.
Amúgy a pwdgen() névből ítélve inkább jelszógeneráló lehet. De lehet, hogy csak a név félrevezető, és neked van igazad, és a CAPTCHA-ban megadandó szöveget is jelszónak hívják náluk. "A $QUERY_STRING-re nem csoda hogy sikít az interpreter, se paraméterként se global-al behúzva nincs ott a függvényben
"
Az egész függvény tele van undormány megoldásokkal, úgyhogy ez csak egy része a sok parának... -
#15493
DeltaPower
addikt
Sk8erPeter
#15492
DeltaPower
addikt
válasz
Sk8erPeter
#15492
üzenetére
A regexp betűiből szándékosan maradt ki az i és l (mint ló), I (mint Ilona) és O betű, meg a 0-s és 1-es szám, mert valaki azt gondolta, ettől biztonságosabb lesz a dolog?
Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt...
A $QUERY_STRING-re nem csoda hogy sikít az interpreter, se paraméterként se global-al behúzva nincs ott a függvényben
-
#15492
Sk8erPeter
nagyúr
umek7
#15491
Sk8erPeter
nagyúr
Azt a qrva, de jó ronda. Hogy sikerült ezt így összehozni? Attól kifejezetten rossz minőségű lesz a kód, ha be van hányva egy sorba egy csomó minden - lásd azt a csodálatos while+regexp-tesztelés+változónak értékadás+sprintf+rand sort... Az ilyen hányadék kódhoz már szinte művészi tehetség kell.
Ha ezt meg így kaptad, hát az szívás, de itt az ideje, hogy átalakítsd valami áttekinthető formátumúra.
$i=($QUERY_STRING)?($QUERY_STRING):"10";
helyette
$i=( isset($QUERY_STRING) ? $QUERY_STRING : 10 );
vagy
$i=( !empty($QUERY_STRING) ? $QUERY_STRING : 10);Amúgy minek ide a $QUERY_STRING változóhoz a nagybetű? És ez valami globális változós undormány? Miért nem kapta meg ezt paraméterként a függvény, és lett egy default értéke a paraméternek, ami jelen esetben 10 (amennyiben nem lenne az megadva a fvhíváskor; ja, és nem mindegy, hogy nem "10" stringként, hanem 10 intként)?
A $pwd változót meg deklaráld előre még az első while-ciklus előtt:
$pwd = '';A regexp betűiből szándékosan maradt ki az i és l (mint ló), I (mint Ilona) és O betű, meg a 0-s és 1-es szám, mert valaki azt gondolta, ettől biztonságosabb lesz a dolog?
-
umek7
őstag
Hogyan lehetne ezt megoldani? Előre is köszi.
Notice: Undefined variable: QUERY_STRING on line 13
Notice: Undefined variable: pwd on line 16function pwdgen () {
srand(time());
$i=($QUERY_STRING)?($QUERY_STRING):"10";
while($i--) {
while(!preg_match("/[abcdefghjkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVXYZ2-9]/i",$chr=sprintf("%c",rand(48,127))));
$pwd .= $chr;
}
return $pwd;
} -
#15490
fordfairlane
veterán
Speeedfire
#15489
fordfairlane
veterán
válasz
Speeedfire
#15489
üzenetére
Írtam én valahol is azt, hogy a cookienál kell eszképelni is valamit?
Ha nem tűnt volna fel, épp ez a téma. Az hogy mit hogyan escapelsz, az nem független attól, hogy hova szánod.
-
#15489
Speeedfire
félisten
fordfairlane
#15487
Speeedfire
félisten
válasz
fordfairlane
#15487
üzenetére
Írtam én valahol is azt, hogy a cookienál kell eszképelni is valamit?
Egyedül az eszképelésre írtam egy megoldást, ahol nincs adatbázis.Részemről a téma lezárva.
-
#15488
mallee
tag
Speeedfire
#15486
mallee
tag
válasz
Speeedfire
#15486
üzenetére
Tudsz mondani olyan esetet, ahol az addslashes jó?
-
#15487
fordfairlane
veterán
Speeedfire
#15484
fordfairlane
veterán
válasz
Speeedfire
#15484
üzenetére
setcookie-nál nincs mit escapelni. Ha direktben akarod manipulálni a cookie-kat kezelő fejléceket, akkor urlencode-ot használsz.
-
#15485
mallee
tag
Speeedfire
#15484
mallee
tag
válasz
Speeedfire
#15484
üzenetére
Adatbázisos escapeléshez a prepared statement-ek valóak, de jó még a mysql_real_escape_string() is. Cookienál nincs mit escapelni. XSS támadás szűréséhez pedig megint más megoldások vannak.
-
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
-
#15482
mallee
tag
Speeedfire
#15462
mallee
tag
válasz
Speeedfire
#15462
üzenetére
addslashes? Semmi értelme, haszontalan.
-
#15481
trisztan94
őstag
csabyka666
#15473
trisztan94
őstag
válasz
csabyka666
#15473
üzenetére
-
#15480
DNReNTi
őstag
csabyka666
#15479
DNReNTi
őstag
válasz
csabyka666
#15479
üzenetére
Az dicséretes hogy küzdesz mint disznó a jégen, no meg mindenki kezdte valahogy, de ez nem elfogadható hozzáállás: "elsődleges cél, hogy működjön a projekt, még ha tákolással is". Pont néhány napja írtam: attól mert valami működik még nem biztos hogy jó. 5 perc alatt írok neked egy bejelentkezős form-ot, ami működik, és kell még 5 óra, hogy jó is legyen. Ha ezzel akarsz foglalkozni, mármint komolyan, mondjuk pénzt szeretnél keresni azzal hogy webalkalmazásokat készítesz, akkor ezt az "elsődleges célt" gyorsan felejtsd el.
Én úgy látom - ismét, no offense - hogy sokszor nálad alapjaiban szétcsúsznak a dolgok, úgy gondolom ennek elsősorban a kapkodás, netről összeollózás, és főleg a mindegymáncsakműködjön hozzáállás az oka. Gyakran tök alap problémákat önmagad sz*patása céljából nagyítasz fel, és ész nélkül próbálsz megoldást találni a problémára, aminek a vége: még több probléma, lásd: sütikben mysql_real_escape_string().
Attól mert nem 10 éve foglalkozol ezzel, még senki nem fog hülyének nézni, vagy leköpni mert felteszel egy kérdést, de érthető a felháborodás, mikor már a sokadik kérdés-válasz után nem fogadod el a segítséget, és ahelyett, hogy a javasolt jó úton próbálnád megoldani a feladatot, elvárod, hogy inkább rossz/hibás/elavult kód megírásában segítsenek neked.
Jó hasznát pedig akkor veszed a topiknak ha megfogadod a tanácsokat.
Ismét: no offense. -
#15479
csabyka666
veterán
Nem az okozta a problémát, hogy UTF-8 és ISO-8859-1 is volt a kódban. Én is erre gondoltam első körben, de nem oldotta meg az sem, ha egyezett a kettő.
Szerintem sohasem fogok közös nevezőre kerülni veletek. Én megértem, ha ti sokkal professzionálisabb megoldásokkal álltok elő, de ti meg azt értsétek meg, hogy nekem az elsődleges cél, hogy működjön a projekt, még ha tákolással is.
Ennek ellenére jó hasznát vettem (és remélhetőleg veszem is) a topicnak, szóval oltsatok nyugodtan, nem fogok megsértődni.
![;]](//cdn.rios.hu/dl/s/v1.gif)
MOD: és persze ki is fejtettem.
-
#15478
DNReNTi
őstag
Sk8erPeter
#15477
DNReNTi
őstag
válasz
Sk8erPeter
#15477
üzenetére
Na hogy végre valami érdemi dologról legyen szó.
Elkészült az adatbázis kezelő "projektem" 1.2 verziója, az észrevételek figyelembevételével. Update-ek:
- Van konfigurációs osztály, amely később minden egyéb más konfigurációs feladatot elláthat. A getDatabaseConfiguration() metódus konfig fájlból beolvassa a szükséges adatokat, majd egy tömbben tér velük vissza.
- Ennek folyománya hogy megváltozott a kapcsolatot létrehozó osztály. első kérdés lehet miért szerepel benne az ini_set();. Sajnos ha a host rosszul van megadva a try ellenére is hibákkal bombáz szét a php, így viszont nem. Ezúttal csak a megjelenítés van kikapcsolva nem a reporting, ahogy Sk8erPeter írta korábban. Ha minden jól megy egy mysqli objektumot ad vissza, ha nem, akkor kivétellel elszáll, és átmenetileg a csodás die() függvény szolgáltatását igénybe véve véget vet a futtatásnak. Erre mindenképp szeretnék valami szebb megoldást, de a try-ból nem lehet kiugrani header-el hibaoldalra.
- A legtöbb változás magát a lekérdezést kezelésért felelős osztályt érintette. Egy halom privát metódusra szedtem az ellenőrzést, valamint született egy szintén privát executeQuery() nevű metódus, ami a futtatással bezárólag elvégez minden ellenőrzést, idáig minden lekérdezés ugyan úgy fordul le. Három különböző metódusra bontottam a lekérdezéseket, azok típusainak megfelelően, egyelőre tehát van select(), insert(), update() metódus. A select() eredmény tömbbel, az update() az érintett sorok számával az insert() pedig az utolsó beillesztett id-val tér vissza.
Használata alig változott, például:
$DB = new Database();
$SQL_command = 'SELECT content FROM example WHERE id = ? AND active = ?';
$SQL_parameters = array(547,1);
try {
$result = $DB->select($SQL_command, $SQL_parameters);
} catch (Exception $e) {
echo 'ERROR : ' . $e->getMessage() . '<br>';
}Osztálybetöltés autoloader-rel van megoldva. Egyelőre úgy látom minden szuperül működik, és így az én két üveg Heinekentől csipás szememmel megfigyelve, sikerült többnyire implementálni az észrevételeiteket.
Kérdések:
- Jó e?
- Hogyan oldjam meg szépen, hogy az openConnection() metódus, hiba esetén (nem sikerül kapcsolódni az adatbázishoz), egy header()-rel adott hibaoldalra dobjon?Köszi!
-
#15477
Sk8erPeter
nagyúr
csabyka666
#15470
Sk8erPeter
nagyúr
válasz
csabyka666
#15470
üzenetére
Milyen jó lett volna, ha megfogadod a tanácsunkat, és PDO-t használsz exception-kezeléssel.
(#15473) csabyka666 :
Könyörgöm, fejezd már be ezt a mentalitást! Bocs, de minek jössz ide kérdezgetni, ha tákolni akarsz, és ragaszkodsz a saját elképzeléseidhez? Azért nem érdemes használni a mail()-t, mert egyszerűen túl sok a problémalehetőség, formázási problémák vannak vele, olyan gondjaid fognak előfordulni, amit épp a javasolt SwiftMailerben vagy a PHPMailerben már régesrégen megoldottak. Korrekt kimenetet kaphatnál, és fordíthatnád az idődet HASZNOS tevékenységekre, HASZNOS önfejlesztésre, ahelyett, hogy ilyen baromságokkal szopatnád magadat.
Megint én vagyok a beszólogatós köcsög, de vállalom, valakinek meg kell mondania időben, hogy hülyeséget csinálsz.(#15476) Soak :
Notórius önszopató, mondhatjuk neki mi a magunkét, egyszerűen szarik rá, "jó lesz az"-alapon. Mindjárt jön a hosszú kifejtése annak, hogy "de hát én így meg úgy, ti meg úgy meg amúgy", szóval fűrészelhetjük majd vele a fingot keményen megint, ahelyett, hogy valami érdemi dologról lenne szó végre ebben a topicban. -
#15476
Soak
veterán
csabyka666
#15473
Soak
veterán
válasz
csabyka666
#15473
üzenetére
Persze, vegulis minek hallgatnal azokra akik mar vegig szoptak ugyanugy ahogy te.
-
#15475
DNReNTi
őstag
csabyka666
#15471
DNReNTi
őstag
válasz
csabyka666
#15471
üzenetére
Mivel charset=utf-8 van a tartalomban és charset=iso-8859-1 a headerben. Nem is csoda hogy nem jól jelenik meg.
-
moltam88
tag
válasz
csabyka666
#15471
üzenetére
Nem használtam még mail() -t, de nem lehetm, hogy mindkét helyen utf-8 kódolást kellene megadnod? ($headers-ben iso-8859-1 -et írtál)
-
#15473
csabyka666
veterán
trisztan94
#15472
válasz
trisztan94
#15472
üzenetére
Hú, gondoltam, hogy van szebb / jobb / fullosabb megoldás, de én - ahogy megszokhattátok - hajthatatlan vagyok, és maradnék a mail()-nél. Azt a pár karaktert, amit én küldök vele, azt megcsinálja nekem, csak a kódoláson kellene hegeszteni.
-
#15472
trisztan94
őstag
csabyka666
#15471
trisztan94
őstag
válasz
csabyka666
#15471
üzenetére
-
#15471
csabyka666
veterán
Valaki használja közületek a PHP mail() függvényét?
Megformáztam HTML doksira, és gmail-en jó is, de freemail-re küldve nem jó a karakterkódolás.
Ezt írtam a head-be:<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\">
plusz ezt is hozzátettem:
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";de ugyanúgy rossz.
Mit lehet (kell) még beállítani, hogy működjön?
-
#15470
csabyka666
veterán
Megoldódott a probléma. Elmondom, mi volt a baj, de ígérjétek meg, hogy nem nevettek ki.
Localhost-on minden működött, ellenben a szerveren nem tudtam törölni rekordokat a táblákból. Persze, ha megnéztem volna mysql_error();-ral, hogy mi a nyűgje, akkor nem ültem volna a gép előtt fél napot.
A lényeg: a webtárhelyen a DELETE nem került engedélyezésre, valamiért figyelmen kívül hagytam, amikor beállítottam az adatbázist. Atyaég...Eszembe nem jutott volna, hogy ez a hiba, annál is inkább, mert a phpmyadmin felület alól tudtam törölni.
Természetesen ettől függetlenül köszönöm a segítséget!
-
#15469
csabyka666
veterán
DNReNTi
#15468
-
#15468
DNReNTi
őstag
csabyka666
#15466
DNReNTi
őstag
válasz
csabyka666
#15466
üzenetére
Több észrevétel:
1. Hibakereséshez, írasd ki a generált sql lekérdezést, és ellenőrizd! Valszeg azért nem fut le, mert hibás lekérdezés generálódik.
2. A törléshez semmiképp sem használnék get változókat. Ügyesebb megoldás lenne a session használata, DE!!! még akkor is mindenképp ellenőrizned KELL, hogy adott elem törléséhez van e jogosultsága a felhasználónak. Ha az ellenőrzés kimarad és ráadásul url-ben átadott paraméterekkel dolgozol, annak az az eredménye, hogy minimális hozzáértéssel törölhető minden kosár tartalma. -
#15467
csabyka666
veterán
DNReNTi
#15465
-
#15466
csabyka666
veterán
fordfairlane
#15464
válasz
fordfairlane
#15464
üzenetére
Most már működnek a cookie-s dolgok, és get-tel is el tudom kapni az URL-eket, hála az ob_start()-nak.
Egy olyan szituáció áll most fenn, aminek a megoldásához szerintem mélyebbre kéne ásni a PHP bugyraiban.
A probléma: kosárból akarok törölni elemeket.
A megoldás, ami localhost-on működik is: rákattintok a törlésre a weblapon, ez feldobja az elem sorszámát az URL-be, get-tel elkapom, majd ebből kreálok egy SQL query-t. Eddig szép és jó, el is készül a query, viszont nem hajlandó kitörölni az elemet. Ha az elkészült query-t phpmyadmin-on keresztül manuálisan futtatom le, akkor frankón kitörli.Ahogy mondtam már, localhost-on nincs ezzel bajom. És ebben nincs cookie sem, szóval az sem lehet probléma...
-
#15465
DNReNTi
őstag
csabyka666
#15463
DNReNTi
őstag
válasz
csabyka666
#15463
üzenetére
No offense, de én itt már egy alapjaiban rossz koncepciót látok.
Ha egy termék vonalkódja módosul, egyáltalán miért sütibe kerül? Miért nem az adatbázisba egyből? Közben felmerült, hogy mi van ha később adatbázisba mented? Ismét megkérdezem: miért nem egyből? Nem látom a dolog egészét, de most ha végiggondoljuk, nem célszerűbb lenne e egyből elmenteni? Teszem azt, megváltoztatom egy termék vonalkódját, majd törlöm a sütiket. Akkor mi van?
A legfontosabb kérdés:
Mi a cél? -
#15464
fordfairlane
veterán
csabyka666
#15463
fordfairlane
veterán
válasz
csabyka666
#15463
üzenetére
Légyszi ne rakd offba a hszeket, csak ha nem PHP témájú. A cookie állítgatás lehetőleg mindenféle kiíratást, html kódot előzzön meg. Az ob_start ugyan segíthet, de jobb, ha arra sincs szükség.
-
#15463
csabyka666
veterán
Jójó, de a lényegen nem változtat: localhost-on működik minden, "igazi" szerveren pedig még mindig süket némelyik funkció.
-
#15462
Speeedfire
félisten
csabyka666
#15460
Speeedfire
félisten
válasz
csabyka666
#15460
üzenetére
Inkább addslashes.
-
#15461
fordfairlane
veterán
csabyka666
#15460
fordfairlane
veterán
válasz
csabyka666
#15460
üzenetére
A mysql escape-t mysql műveleteknél kell használni.
-
#15460
csabyka666
veterán
DNReNTi
#15459
-
#15459
DNReNTi
őstag
csabyka666
#15458
DNReNTi
őstag
válasz
csabyka666
#15458
üzenetére
A kérdés szerintem arra irányul hogy minek mysql_real_escape_string() mikor nem adatbázisba mentesz?
-
#15458
csabyka666
veterán
Sk8erPeter
#15457
válasz
Sk8erPeter
#15457
üzenetére
Mert egy beviteli mező tartalmát mentem a cookie-ba. Próbáltam úgy is, hogy nem írtam be a mysql_real_escape_string()-et, de úgy sem működött.
ob_start()-tal már majdnem mindegyik esetben jó.
-
#15457
Sk8erPeter
nagyúr
csabyka666
#15456
Sk8erPeter
nagyúr
válasz
csabyka666
#15456
üzenetére
A cookie beállításához miért használsz mysql_real_escape_string()-et?
-
#15456
csabyka666
veterán
csabyka666
#15455
válasz
csabyka666
#15455
üzenetére
ob_start(); részben megoldotta a problémát, de még mindig van pár eset, amikor nem készül el a cookie.
-
#15455
csabyka666
veterán
Üdv ismét!
Feltöltöttem webszerverre a projektet, és az a furcsa jelenség állt elő, hogy amikor $_GET-tel akarok kivenni infókat az URL-ből, akkor bizonyos esetekben működik, bizonyos esetekben viszont nem. Localhoston nem volt ilyen gondom, ott minden működött.
Annyi a jó hír, hogy legalább következetes a hiba, mert mindig ugyanott működik, és ugyanott nem működik.Ez a kód azt csinálja, amit kell:
if(isset($_GET['vonalkod'])){
setcookie("vonalkod_modositas", mysql_real_escape_string($_GET['vonalkod']), time()+3600);
setcookie("vonalkod_backup_modositas", mysql_real_escape_string($_GET['vonalkod']), time()+3600);
header("Location: index.php?menu=termek_adatainak_modositasa");
}Ez viszont nem hozza létre a cookie-t:
if(isset($_GET['vonalkod'])){
setcookie("vonalkod_h_arazas", mysql_real_escape_string($_GET['vonalkod']), time()+3600);
header("Location: index.php?menu=arazas#hagyomanyos_arazas");
}A linkben benne van a ...?vonalkod=..., szóval nem értem, miért nem teljesül a feltétel.
Van valami ötletetek így elsőre?
-
#15454
Sk8erPeter
nagyúr
csabyka666
#15453
Sk8erPeter
nagyúr
válasz
csabyka666
#15453
üzenetére
Pont azért lenne érdemes időben átállnod a manapság is jól használható eszközökre, mert minél tovább húzod a dolgot, annál nehezebb lesz később átírni a projektet. Csak rá kell érezned, és nem lesz akkora katasztrófa átírni a mostani, kerülendő mysql_*-es megoldást.
Természetesen próbálgasd előbb localhoston, egy tök másik projekten, hogy hogy is működik a dolog, és meg fogod szokni. -
#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.
-
#15452
fordfairlane
veterán
csabyka666
#15449
fordfairlane
veterán
válasz
csabyka666
#15449
üzenetére
Injection ellen vagy escapeled a bejövő paramétereket, vagy prepared statementet használsz. Utóbbira a mysqli vagy a pdo interfész ad eszközöket. Ne használd a mysql_* kezdetű függvényeket. 2011 óta "deprecated" státuszúak, és valószínűleg ki lesznek szedve a PHP.ból a jövőben.
-
#15451
DNReNTi
őstag
csabyka666
#15449
DNReNTi
őstag
válasz
csabyka666
#15449
üzenetére
Vagy használj mysqli-t ha a PDO túl idegen elsőre.
Itt egy rövid leírás alap példákkal (englishül). -
#15450
Sk8erPeter
nagyúr
csabyka666
#15449
Sk8erPeter
nagyúr
válasz
csabyka666
#15449
üzenetére
Még mindig (addig fogod kapni ezt a választ, amíg nem váltasz a mysql_ kezdetű függvényekről): használj PDO-t prepared statementekkel, és akkor elkerülöd az ilyen szerencsétlenkedéseket.
-
#15449
csabyka666
veterán
SQL topicban már feltettem ezt a kérdést, de itt lehet, hogy jobb helye van. Szóval.
SQL injection ellen mi (vagy mik) a legjobb PHP függvények? Ezt találtam: mysql_real_escape_string(), és kérdeznélek benneteket, hogy ez elegendő, vagy küldjek rá még másik függvényeket is?
(Nem OOP a projekt, hanem az alap mysql_* függvényeket használom.)Más: eddig ha ' (aposztróf) karakter szerepelt a beszúrt mezőben, akkor mindig hibát dobott az SQL. Most, hogy lekezeltem minden beviteli mezőt mysql_real_escape_string() függvénnyel, már bekerülnek az '-os stringek is az adatbázisba. Ez így rendben van, vagy ezzel nyitottam egy biztonsági rést?
-
#15448
csabyka666
veterán
Sk8erPeter
#15443
válasz
Sk8erPeter
#15443
üzenetére
Mindegy is, legalább sikerült segítséget adnom, ez nekem nagy szó.
Amúgy nyilván igazatok van...
-
#15447
trisztan94
őstag
PumpkinSeed
#15446
trisztan94
őstag
válasz
PumpkinSeed
#15446
üzenetére
Titkosításhoz menjen HTTPS protokoll alatt.
-
#15446
PumpkinSeed
addikt
mallee
#15445
PumpkinSeed
addikt
-
mallee
tag
válasz
PumpkinSeed
#15444
üzenetére
Mit értesz biztonságos alatt? Amúgy bármilyen webről jövő adatot nem biztonságosnak kell tekinteni.
-
#15444
PumpkinSeed
addikt
PumpkinSeed
addikt
Hülye kérdés, de nem találom a megfelelő kulcsszavakat se hozzá.
A POST-al átküldött adat mennyire biztonságos, illetve hogyan lehet biztonságosabbá tenni azt?
-
#15443
Sk8erPeter
nagyúr
csabyka666
#15440
Sk8erPeter
nagyúr
válasz
csabyka666
#15440
üzenetére
"Itt kaptam egy tanácsot a PH-n, hogy írjam oda minden adatbázis-kapcsolódás után, hogy:
mysql_query("SET NAMES SET 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
"
Ilyen tanácsot sztem nem adtunk.
A mysql_* kezdetű függvényeket már nem használjuk, deprecated ahogy ezerszer ki lett tárgyalva a topicban.
Ilyesmi inkább elképzelhető:$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
); -
#15442
csabyka666
veterán
TomyLeeBoy
#15441
válasz
TomyLeeBoy
#15441
üzenetére
Igazán nincs mit!
-
TomyLeeBoy
tag
válasz
csabyka666
#15440
üzenetére
Sehogy sem tudok olyat elérni hogy mindkettő jó legyen. Azt csináltam amit tanácsoltál, így az adatbázisból olvasott adatok helyesen jelennek meg, viszont az összes többi nem... Azokkal a direktbe beírt karakterekkel mit tudok csinálni?!Úgy néz ki meg lett a megoldás. Adatbázis lekérés a javaslatod alapján, illetve az összes fájlom kódolásának átállítása ANSI-ról UTF8-ra. Köszönöm a segit!
-
#15440
csabyka666
veterán
TomyLeeBoy
#15436
válasz
TomyLeeBoy
#15436
üzenetére
Nekem is volt hasonló problémám az adatbázissal. Vagy az adatbázisban voltak értelmezhetetlen karakterek, de az oldalon jól szerepelt, vagy fordítva. Itt kaptam egy tanácsot a PH-n, hogy írjam oda minden adatbázis-kapcsolódás után, hogy:
mysql_query("SET NAMES SET 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");Nekem ez megoldotta, most mindenhol jó a kódolás.
A head-ben nekem ez szerepel:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />, az adatbázis illesztése pedig "utf8_general_ci". -
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
-
#15438
DNReNTi
őstag
Sk8erPeter
#15437
DNReNTi
őstag
válasz
Sk8erPeter
#15437
üzenetére
Köszke neked is, jövök majd a v1.2-vel, ezek figyelembevételével.
-
#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. -
#15435
DNReNTi
őstag
TomyLeeBoy
#15434
DNReNTi
őstag
válasz
TomyLeeBoy
#15434
üzenetére
Dede. Az lesz. Bocs én írtam rosszul.
-
#15433
DNReNTi
őstag
TomyLeeBoy
#15432
DNReNTi
őstag
válasz
TomyLeeBoy
#15432
üzenetére
Az adatbázis és a táblák Szerkezet / Structure tabján.
-
#15431
DNReNTi
őstag
TomyLeeBoy
#15430
DNReNTi
őstag
válasz
TomyLeeBoy
#15430
üzenetére
Csekkold le egészen biztosan mindenhol utf-8 e a karakterkódolás:
- adatbázis (táblák és mezők is !)
- a kapcsolat
- az oldalHa minden utf-8, akkor nem kéne gondnak lennie. Továbbá nézd meg azt is, hogy az adatbázisban helyesen vannak e tárolva az adatok, az is lehet a korábbi rossz kódolás miatt, eleve rosszul vannak tárolva az adatok, és az oldal maga jól írja ki.
-
#15430
TomyLeeBoy
tag
TomyLeeBoy
tag
Üdv!
Átköltöztettem egyik munkámat wamp-ról iis-re, és a karakterkódolással akadt egy kis problémám. A mysql-ből nyert adatok széthullanak. iso-8859-2 volt beállítva eddig. Ha átállítom utf8-ra, akkor megfordul a helyzet, a mysql adatok lesznek jók és az összes többi nem. próbáltam mysql_set_charset-al az adatbázis hívásokat utf8-ra állítani de nem lett semmi változás. Valaki tudna ebben segíteni?
-
DNReNTi
őstag
válasz
mallee
#15416
üzenetére
Szia,
Köszi az észrevételeket!
"Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak."
Igen, így is volt, de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra akkor sajnos elhasalt, mivel nem találta a config file-t a megadott helyen. Abszolút hivatkozással működik de azt csúnyának ítéltem meg, így egyelőre maradt ez a megoldás.
Erre mi lenne a legszebb, legjobb eljárás?"Miért kezel az adatbázis osztályod error reportolást?"
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."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."Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?"
Ez az osztály, pontosabban ennek az egy szem statikus metódosa egy mysqli objektumot ad vissza. Meghívásra egyszer kerül, a Database osztály konstruktora példányosítja saját maga számára."Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján"
Ebben teljesen egyet értek, és így is lesz. Illetve majdnem. Ú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.Összességében jól értem, hogy főleg szépséghibák vannak, de a működés, és az elképzelés életképes?
Ha lesz időm ma update-elem, és jövök megint. -
#15426
csabyka666
veterán
fordfairlane
#15425
válasz
fordfairlane
#15425
üzenetére
Okés, így már bátrabban teszem csak az elejére. Köszi!
-
#15425
fordfairlane
veterán
csabyka666
#15424
fordfairlane
veterán
válasz
csabyka666
#15424
üzenetére
Nincsenek rejtett dolgok. Felépítesz egy adatbázis kapcsolatot, az addig él, amíg a PHP fut az adott végrehajtási szálon, akárhány fájlból is tevődik össze. Amint véget ér a futás, a kapcsolat lezárul magától.
-
#15424
csabyka666
veterán
fordfairlane
#15422
válasz
fordfairlane
#15422
üzenetére
Azért "akadékoskodok" itt, mert annyira mélységeiben nem látom át, ezért kérdezlek benneteket. Nyilván, ha az index.php hívja be a többit, akkor annak az elején is jó a kapcsolódás, de hogy biztos legyek a dolgomban, inkább kérdezek.
Hátha van a PHP-nak valami sajátossága, hogy pl. fájlok behúzásakor is ki kell adni a kapcsolódást (persze nincs ilyen, csak példának írom)...szóval ha vannak rejtett dolgok, akkor azt ti tudjátok, én viszont nem. -
mallee
tag
válasz
fordfairlane
#15420
üzenetére
Helyesen az ilyen kreátor objektumoknak az általad felvázolt módon sem lenne szabadna létezniük, helyette minden objektum kívülről várná a függőségeinek "kielégítését": bővebben.
-
#15422
fordfairlane
veterán
csabyka666
#15421
fordfairlane
veterán
válasz
csabyka666
#15421
üzenetére
Jó, de ha egyszer te tudod, hogy melyik fájlod milyen sorrendben hívódik meg, akkor még milyen plusz infó kell? Én adtam egy olyan megoldást, ami sorrend-független, minden másra ott a közös programfájl, ami mindig végrehajtódik. Azt behúzod az összes php fájlod elejére. Ha az index.php csinál mindent, akkor annak az elejébe teszed.
-
#15421
csabyka666
veterán
fordfairlane
#15420
válasz
fordfairlane
#15420
üzenetére
Ez biztosan így van, de ahogy mondtam, nekem most az a lényeg, hogy működjön a dolog.
-
#15420
fordfairlane
veterán
csabyka666
#15419
fordfairlane
veterán
válasz
csabyka666
#15419
üzenetére
Ez az előnye a "kreátor" objektumnak. Csak meghívod a megfelelő metódusát, az pedig visszaad neked egy adatbáziskapcsolati objektumot. Az objektum életciklusával nem kell foglalkoznod. Sem azzal, hogy mikor hívod meg, hányszor hívod meg, hol hívod meg, hogy az index.php jön először, vagy azután, vagy soha.
Egyszer létrehozza, és utána már ugyanazt adja vissza az összes olyan programrésznek, amelyiknek adatbázis műveleteket kell végrehajtania.
-
#15419
csabyka666
veterán
mallee
#15418
-
#15418
mallee
tag
csabyka666
#15417
mallee
tag
válasz
csabyka666
#15417
üzenetére
Érzésem szerint az index.php minden újratöltéskor lefut.
Ha mindig lefut, akkor elég ennek az egy fájlnak a tetején létrehozni a kapcsolatot.
-
#15417
csabyka666
veterán
Sőt, közben eszembe jutott még valami.
Nálam úgy áll össze az oldal szerkezete, hogy van egy index.php fájlom, és ebben a fájlban vizsgálom, hogy éppen melyik menüpontot választotta ki a felhasználó. Érzésem szerint az index.php minden újratöltéskor lefut.
Szóval elegendő lenne csak ennek az elejére tenni a csatlakozást, és kihagyhatom az összes többi fájlból? Mármint, ami az index.php-n belül hívódik meg...? Mennyire jó megoldás ez? -
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
-
#15414
DNReNTi
őstag
csabyka666
#15413
DNReNTi
őstag
válasz
csabyka666
#15413
üzenetére
Felre ertetted az inicializalos mondanivalom.
Egy adatbazissal is hasznos egy init fajlba osszegyujteni a behuzando dolgokat. Fuggvenyek, adatbazis kezeles stb. De hogy valaszt adjak konkret kerdesre: eleg egyszer a file elejen adatbazis kapcsolatot nyitni. -
#15413
csabyka666
veterán
Köszi segítséget mindenkinek!
Az én "projektem" nem túl komoly, persze ettől még jogos, hogy OOP kézenfekvő, nem is ezzel van a probléma.
Esetemben egyetlen adatbázis van, egyetlen névvel/jelszóval, és vélhetően ennyi is marad, szóval úgy érzem, nem szükséges az init.php, de mindegy is, a kérdés igazából az lenne továbbra is, hogy a PHP fájlok elején elegendő-e a csatlakozást megejteni (include-dal vagy anélkül, az most mindegy, a hangsúly a csatlakozáson van), vagy pedig minden egyes query előtt includeoljam a csatlakozós php-t?Vagy pedig a harmadik út: hagyjam úgy, ahogy van most, mert ha csak az elején csatlakozok, vagy ha csak közben, az eredmény ugyanaz lesz?
-
DNReNTi
őstag
Ha már úgyis témánál vagyunk, feldobom egy korábbi kérdésem. Tehát készült a kezem alatt egy lekérdezéseket kezelő osztály, ami jelen formájában nagyon jól működik, de a kérdés az hogy jó is e?
A kapcsolatot kezelő osztály szkriptje.
A lekérdezéseket kezelő osztály szkriptje.
A használata:
$DB = new Database();
$SQL_command = 'SELECT user_name FORM users WHERE id = ? AND active = ?';
$SQL_parameters = array(23,1);
try {
$DB->executeSQL($SQL_command, $SQL_parameters);
} catch (Exception $e) {
echo 'ERROR : ' . $e->getMessage() . '<br>';
}Én még nem tudtam megfektetni, eddig bármilyen (select, insert, update) lekérdezést jól lekezelt, vagy hibával (jól) elszállt. Tehát a kérdés: oké hogy működik, de jó e?
-
#15411
DNReNTi
őstag
Sk8erPeter
#15409
DNReNTi
őstag
válasz
Sk8erPeter
#15409
üzenetére
Az irónia lejött. Rosszul tettem fel a kérdést.
Nem úgy értettem hogy szerinted miért gáz, hanem általánosságban.
Mi szól a minta használata ellen, ilyen alapfeladat ellátása esetén mint az adatbázis kapcsolat kezelése? -
#15410
fordfairlane
veterán
Sk8erPeter
#15409
fordfairlane
veterán
válasz
Sk8erPeter
#15409
üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
Nem tudom, minek az egyvelege. Külön osztály végzi a példányosítást, és a példány felügyeletét futásidőben, ennyi. A Singletonnal szemben a leggyakoribb kifogás, hogy keveredik az objektum hagyományos szerepköre, a domain-funkció, és a példányosítási-futásidejű implementálási technika, és ezért nehezen tesztelhető.
Itt nem keveredik, szét van választva. Persze lehet tovább alakítani, hogy automatikus tesztekre alkalmasabb legyen, dependency konténerrel és társaival, de ez már végképp olyan szint, amivel semmiképp nem terhelnék egy kezdőt. Már ez is sok volt neki.
-
#15409
Sk8erPeter
nagyúr
fordfairlane
#15402
Sk8erPeter
nagyúr
válasz
fordfairlane
#15402
üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
(#15403) DNReNTi :
"Mért lenne gáz? Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás."
Egyrészt szerintem az ironikus hangvételből kiderült, hogy nem feltétlenül tükrözi a véleményemet a dolog, még ha bőven van is igazsága az azt ellenzőknek, tehát nincs szükség a szemforgatásra (arra amúgy sincs, ha szakmai vitát akarunk nyitni), másrészt meg javaslom, keress rá a topicban (pl. Athlon64+ kolléga itt kardoskodik ellene: [link]), illetve Stack Overflow-n és más forrásokban is, hogy mik is az érvek a Singleton-minta ellen; az "Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás" mondatra meg az a válasz, hogy van, akik meg tudják oldani nélküle, tehát lehet jobb megoldás. Most is előkapható a sablon-érv, hogy "nincs legjobb megoldás". -
#15408
fordfairlane
veterán
csabyka666
#15404
fordfairlane
veterán
válasz
csabyka666
#15404
üzenetére
Működik, csak nehezen módosítható, nehezen karbantartható (nem tesztelhető automatikus testscriptekkel, nem testreszabható attól függően, hogy fejlesztői vagy éles környezetben fut stb, stb...). Ezért vannak ezek a technikák, amikkel nem csak működni fog a rendszered, de modulárisabb, ezáltal kezelhetőbb is lesz.
-
#15407
DNReNTi
őstag
csabyka666
#15404
DNReNTi
őstag
válasz
csabyka666
#15404
üzenetére
Erre mondaná a volt programozás tanárom az egyetemen: működik de nem jó.
Ez egyben az is jelentette hogy meg vagy bukva, csak viccesen szeretett fogalmazni. A lényeg: amit csináltál valóban működik DE:
1. A mysql_ parancsok nyugdíjazva vannak, tehát várhatóan ki is fognak kerülni a frissebb php verziókból, ami azt jelenti, hogy ez belátható időn belül nem fog működni.
2. fordfairlane is írta, hogy az, hogy minden file elején inicializáló parancsokat raksz be nem jó. Persze működik, de önmagad szívatod vele. Ugyan az mint amit css-re írtam, egyszerűbb ha ezek egy helyen vannak és később nem 500 helyen kell módosítani. Minden inicializációval kapcsolatos include és parancs mehet egy init.php-ba, és csak az egyet include-olod.
3. Kapcsolódik az elsőhöz, kezdj el ismerkedni az OOP-vel, elsőre bár bonyolultnak tűnik, de egy mysqli vagy PDO osztály használata meghálálja magát. -
mallee
tag
válasz
mallee
#15405
üzenetére
A legjobb az egészben, hogy több egymásnak ellentmondó infót is találtam
Limitations
Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.Forrás: http://phpunit.de/manual/3.7/en/test-doubles.html
Úgy tűnik, hogy 3.5 alatt támogatott volt: http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html
-
#15404
csabyka666
veterán
Biztos úgy van, ahogy mondjátok, de nekem ez már tényleg haladó szint.
Az biztos, hogy működik az oldal így is, ahogy most van, szóval akkora butaságot talán nem csináltam...
-
#15403
DNReNTi
őstag
Sk8erPeter
#15401
DNReNTi
őstag
válasz
Sk8erPeter
#15401
üzenetére
Mért lenne gáz?
Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás. -
#15402
fordfairlane
veterán
Sk8erPeter
#15401
fordfairlane
veterán
válasz
Sk8erPeter
#15401
üzenetére
Talán rosszul tudom, de a singleton egy olyan objektum, ami önmagát állítja elő, futásidőben egyszer. Ez nem saját magát állítja elő, hanem a PDO-t.
-
#15401
Sk8erPeter
nagyúr
fordfairlane
#15398
Sk8erPeter
nagyúr
válasz
fordfairlane
#15398
üzenetére
Vigyázz, mert mindjárt megkapod, hogy a Singleton qrva gáz.
"Majdnem olyan, mint egy Singleton"
Hogy érted azt, hogy majdnem olyan? Jelen formájában ez konkrétan Singleton-minta.
Amúgy a pwdgen() névből ítélve inkább jelszógeneráló lehet. De lehet, hogy csak a név félrevezető, és neked van igazad, és a CAPTCHA-ban megadandó szöveget is jelszónak hívják náluk. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Revolut
- Forrmell.enn
- Genshin Impact (PC, PS4, Android, iOS)
- Elektromos autók - motorok
- iPhone topik
- Eurós árlista a Google Pixel 10 telefonokhoz
- HP notebook topic
- A fociról könnyedén, egy baráti társaságban
- Nintendo Switch 2
- Új kétfiókos NAS-sal gyarapodott a Synology palettája
- További aktív témák...
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! GigabyteA620M R5 7500F 32GB DDR5 500GB SSD RX6700XT 12GB Bitfenix Nova Mesh Enermax 750W
- Bomba ár! Dell Latitude E6400 - Intel P8400 I 3GB I 160GB I 14,1" I Intel VGA I Garancia!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest