php - sql update

Internet: PHP, CGI, stb.

sziasztok!

Tanulás céljából vágtam bele, de most sajnos megakadtam, s kérném a segítségeteket.
kódrészlet:
http://pastebin.com/6HmsbGDg

php form segítségével feltöltöttem adatokat az sql-be jól megy, de most szerkeszteném őket.

A táblákba előre felvett értékek vannak, és egy legördülő menüben lehet kiválasztani.

Úgy szeretném megcsinálni, hogy az

íde a feltöltött adat szerepeljen az első helyen, mivel az egy másik táblában van, ezért itt kezdődtek a problémáim,hiába nyitok { } egy uj részt és odaírom be, hogy melyik táblából olvassa ki az adatokat nem teszi...

Mert ha a végén rányomok a frissít gombra akkor ne üres adattal írja felül...

Segítségeteket köszönöm!

  • 5789 megtekintés

( hrgy84 | 2015. 06. 15., h – 12:54 )

Nnna, kezdjuk az elejen:

- Attol, mert masik tablaval dolgozol, nem kell ujranyitni a connection-t. Siman hasznalhatod az eredeti $link-et.
- Ha mar uj connection-t nyitsz, legalabb zard le a regit (mysqli_close).
- Az elso es a masodik connection-bol is a $adat valtozoba szeded le az adatokat, de az elso connection eredmenyet gyakorlatilag nem hasznalod fel. Mivel a PHP nem java, es itt nincs olyan behatarolt scope-juk a valtozoknak (az elso definialas helye hatarozza meg a scope-t, de legfeljebb function szintu lehet), igy a masodik connectionrol torteno olvasasnal nekifutasbol irod felul az elozo connection erteket.
- A PHP dokumentacio nem ismer olyat, hogy mysqli_fetch_assoc. Elkepzelem, hogy van ilyen, de eros ketelyeim vannak, foleg, mivel a mysqli elsosorban prepared statementekkel dolgozik. Szerintem az egesz kod lukra szalad undefined function hibaval, de megmondom oszinten, nem probaltam ki (ceges gepen nem tudom). Olyan van, hogy mysqli_stmt_fetch, de az tok masra jo.
- Fejezd be a mysqli_pconnnect hasznalatat. A mysqli_connect ugyanolyan jo.

Megoldasi javaslat:

- Dobd ki azt a tutorialt/konyvet, ami alapjan most irod a kodot, meg a hozza kapcsolodo osszes linket.
- Keress a neten egy PHP 24 ora alatt cimu kotetet, azt told vegig, es utana lehet adatbaziskodni. A PHP4-es verzio itt elerheto, az alapveto nyelvi elemek nem valtoztak a PHP5-ben a konyvhoz kepest (a fuggvenyek esetleg, de a vezerlesi szerkezetek, a fobb utasitasok azok nem), kiindulasi alapnak ez is jo, de kezeld fenntartassal.
- Adatbaziskapcsolatra probald ki a PDO-t. Nehezebb ugyan hasznalni, mint a mysql/mysqli fuggveny-alapu konyvtarait, viszont sok jo szokasra szert tehetsz a hasznalataval, meg ha maga a PDO-nak megvannak is a maga korlatai. Tanulni tokeletes, minden masra ott a MasterCard mysqli.
--
Blog | @hron84
Üzemeltető macik

( Frantique v | 2015. 06. 15., h – 12:57 )

$ret = mysqli_query($link, "SELECT * FROM `tabla` WHERE ID=".$_GET["id"]);

Ennél a sornál az SQL injection annyira hívogató, hogy nem is olvastam tovább. Gondold át az egészet, főleg azt a részét, hogy miért nem használod ki a változó előkészítést, valamint miért töröd szanaszét a php fájlod nyitó-záró tagekkel.
--
Coding for fun. ;)

Nem szabad ilyen kemenyen venni. Ahogy nezem, a sracnak ez a masodik PHP kodja (az elso mindenkinel a Hello World volt) eleteben. Az, hogy SQL injection van benne, a legkisebb problema a koddal.

Valld be, te se egybol MVC szemeletben irtad meg az elso ket kododat.
--
Blog | @hron84
Üzemeltető macik

+1, szerintem nagyon korrektül írtad a kritikát, meg is lepődtem, hogy az első hsz nem egy arrogáns leugatás, ahogy sokszor szokott lenni, még állásinterjúknál is (természetesen nem a te tolladból!). Nekem is az sql injection szúrt szemet először, de amit te írtál, annak a kérdező sokkal több használt veszi.

Igen, tudom, igazad van, elnézést kérek mindenkitől, nem volt szándékomban bántani, azonban egy rossz beidegződést nehezebb lesz később átformálni. Ma nekiugrok, és blog formájában elkezdek írni egy minél lényegretörőbb PHP bevezetőt, ahol a lehetséges buktatókat és nyelvspecifikus témákat foglalom össze.
--
Coding for fun. ;)

Az a baj az elterjedt PHP tutorialokkal-könyvekkel, hogy nagyon régen íródtak, az ártatlanság érájában - ahogy én hívom. Akkoriban nem feltételezett senki semmi rosszat, meg se fordult a fejükben, hogy a bemenetet szanálni kéne, ha mégis megtették, akkor legfeljebb azért, hogy ne okozzon szintaxis hibát.
Szerintem a legegyszerűbb példát is úgy kell kezelni, mintha államtitkot bíznánk rá. Továbbá a PHP esetében a szerver beállításai se biztos, hogy minden esetben minket támogatnak (a legtöbb helyen még mindig 5.3 vagy az alatti verzió fut, bekapcsolt register_globals-szal - hozzáteszem, nem tartom ördögtől valónak, amennyiben a kódot körültekintően írják meg.), ezért én ajánlani szoktam minimum a változó alapértékkel való initelését, valamint a típusellenőrzést (pont azért, mert a PHP rugalmasan kezeli ezt). Stb. stb. (Majd összeszedem szépen elejétől, úgyis uborkaszezon jön.)
--
Coding for fun. ;)

Ezek mind szep es jo dolgok, de amikor valaki az if es a switch kozotti kulonbseget sem erzekeli, akkor nem pont az a legnagyobb problema, hogy nem fogja ellenorizni az inputot (btw, a szanalni az teljesen mast jelent).

Szerintem fokozatosan kell haladni, tudja a nyelvi elemeket magabiztosan hasznalni, ertse, hogy miert jo objektumorientaltan programozni, aztan johet a tobbi.
--
Blog | @hron84
Üzemeltető macik

Meg lehet tanulni az OOP-t és a nyelvi alapokat hello world szintű feladatokkal is, amikben nincs sechole.

Nem azt mondom, hogy rögtön oda kell figyelni az összes létező veszélyre, még a nyelvi alapok előtt (habár egy figyelmeztetés nem árt). Hanem hogy amikor valaki egy-egy új technológiát tanul, azt rögtön biztonságosan tanulja meg. Így nem olyan nagy erőfeszítés, mint utólag.

Amikor valaki azt tanulja, hogy működik a $_POST és barátai, akkor ugyanott tanulja meg rögtön, hogy mire kell vigyázni.

Amikor valaki adatbázis elérést tanul, akkor rögtön úgy tanulja meg, hogy csak konstans stringet adunk át query-nek.

--

Egy picit felrecsuszott a kommunikacio, nem az ellen vagyok, hogy ezeket oktassuk, hanem hogy ezeket elvarjuk. Egy technologia tanulasi folyamata altalaban nem fuggoleges vonal szokott lenni, hanem tobbe-kevesbe hegyesszogu meredely. Amikor valaki az alapveto nyelvi elemekkel nincs tisztaban, akkor en egyszeruen korainak erzem azt, hogy belekossunk abba, hogy egyebkent ott figyel egy SQL injection a kodban, egyszeruen nem adekvat ezt hibakent felroni. Tuti, szazket szazalek, hogy barki random ember aki csak most tanul egy tecnhologiat az elso ket pelda tele lesz hibaval, amit tapasztalt fejlesztokent eszedbe nem jutna elkovetni - azonban te annak az utnak a vegen vagy, amire o meg mindig reszketve lep be. Az ilyet elobb motivalni kell, kijavitani az ertelemzavaro hibakat, latni, hogy kepbe tud kerulni a problemaval es ra tud jonni, hogy mi a megoldas, es ha mar mindez megvan, akkor meg egyszer elovenni a kodot, es atvenni a biztonsagi es stilisztikai szempontokat. Ez azert fontos, mert az ember - akarmennyire is nem ugy tunik - egyfokuszu leny, egyszerre csak egy dologra tud 100%-ban odafigyelni. Ha egyszerre kell megtanulni egy tok uj nyelvet, egy tok uj platformot es meg a kulonbozo hibakra is odafigyelni, az lehet, hogy sok lesz, tulsagosan megoszlik a figyelem, elsikkad a lenyeg. Ha mar rutinna valik a nyelv kezelese, elob-utobb rutinna tud valni a biztonsagi problemakra valo odafigyeles is, de a fokozatossag elvevel gyorsabban lehet celratoroen haladni, mint az orokos agyonaggodassal.

A diak inkabb allitson elo egy biztonsagilag megkerdojelezheto, de szintaktikailag es logikailag helyes es atlathato kodot, mint kapkodjon ossze-vissza, es legyen egy olyan kod, amiben rengeteg spagetti kod van a kulonbozo biztonsagi sebezhetosegek javitasara, de meg o maga sem erti, hogy mit csinal _valojaban_ a kodja.
--
Blog | @hron84
Üzemeltető macik

Tökéletesen egyetértek veled. A topikindító bejegyzésben sajnos átsiklottam afölött, hogy a kérdező még nagyon az elején jár (elolvastam, de amint megnyitottam a linkelt kódot, ki is ment a fejemből), valószínű, hogy a tartalomban levő haladóbb szintet igénylő függvények láttán reagáltam így, ahogy.

--
Coding for fun. ;)

"Amikor valaki az alapveto nyelvi elemekkel nincs tisztaban, akkor en egyszeruen korainak erzem azt, hogy belekossunk abba, hogy egyebkent ott figyel egy SQL injection a kodban, egyszeruen nem adekvat ezt hibakent felroni."

Evvel egyet értek, csak ennél eggyel tovább megyek: aki az alapvető nyelvi elemekkel nincs tisztában, az meg se próbáljon adatbázishoz kapcsolódni, mert az még korai. Akkor kezdjen el adatbázisozni, ha már megvannak az alapok. Minden egyes lépést csináljon meg _rendesen_. Amikor nyelvi alapoknál tart, azt csinálja meg rendesen. Amikor adatbázisnál tart, azt is csinálja meg rendesen. Annak nincs értelme, hogy mindenbe belenéz egy kicsit, és már megy is tovább. Sokkal egyszerűbb egyszere egy területet megtanulni, de azt jól, mint megtanulni valamit félig, aztán később leszoktatni a rossz szokásokról.

De ez csak filozófiai jellegű vita inkább, és az eredetihez már kevés köze van. Lehet, hogy az illető nem is akar rendesen megtanulni programozni, akkor meg fölösleges az egész :).

--

Szerintem az adatbaziskapcsolattal semmi baj sincsen, a legegyszerubben eletszagu problemakon lehet megtanulni a programozast, mert ezzel burkoltan azt is megtanulja az illeto, hogy hogyan kosse ossze a kodot a valosaggal.

Srackoromban en is irtam olyan PHP kodokat, amiket ma mar fejvesztve tagadnek le, hogy soha nem is jartam arra, kerem, en ott sem voltam amikor az keszult... am kozben felnottem es most mar tudom, hogy mi hogy mukodik, es eszembe nem jutna azokat a hibakat ujra elkovetni.
--
Blog | @hron84
Üzemeltető macik

+1, mert szerintem tanulni csak konkrét céllal lehet, hogy valamit meg akar valósítani. Az először nem lesz se szép, se hatékony, de legalább értelme van, és ez motiváló. Az alapokat cél nélkül, szárazan végigrágni halál, csak a nagyon fanatikusok tudnak ezen az úton célba érni.

Egyefene megbocsátok,:) (jogos volt)
de csak akkor ha majd dobsz egy linket a blogodról, mert érdekelne az sql inject elleni védelem.

Jah a linkedre ezt dobja a nod:

Access denied
Details:
Web page: http://artinvoice.hu/spams
Comment: Access to the web page was blocked by ESET Endpoint Antivirus. The web page is on the list of websites with potentially dangerous content.

Nem enged hozzaszolni a postokhoz, szoval kenytelen vagyok ide:

"Ajánlatos a fájlban kerülni a többszörös tag nyitás-zárást, mivel ilyenkor az értelmezőt gátoljuk a futásban, emellett nehezebben olvasható a kód, amit írunk."

Fuh. Tekintve, hogy egy eredetileg templating nyelvnek szant cuccrol beszelunk, azert en azt gondolnam, hogy a tobbszoros nyitas-zarast az ertelmezonek azert el kellene birnia kezelni, foleg, mivel a view kodban amugy is olyanokat fogunk irni, hogy <?php echo $user->name ?>, egyszeruen azert, mert ezt igy lehet megvalositani ertelmesen. A <?php echo '<html><head>' kezdetu pelda egy picit sem eletszeru, raadasul a gyakorlatban szinte sosem igy hasznaljuk, mert keves IDE kepes felismerni a szovegben a HTML kodot es ad hasznalhato szintaxis kiemelest (az autocomplete-t mar meg sem emlitem), raadasul folyamatosan problemas a kulonbozo idezojelek kezelese, mar HTML-ben is, hat meg ha meg egy szinten ezt kezelni kell. Ahogy fejesjoco is mondta, jobb, ha nem eleve rossz szokasok beidegzesevel kezdunk, marpedig az "irjuk az egesz HTML-t egy baromi nagy echo-ba" az sokminden, de se nem atlathato, se nem kenyelmes, se nem error-proof.
--
Blog | @hron84
Üzemeltető macik

Talán. A célom elvezetni a srácokat az MVC irányába, az pedig, hogy HTML blokkok közé php szkriptrészleteket beszórjanak - hááát, majd, ha már csuklóból megy a 300 sorral feljebb deklarált változó beazonosítása. Nem beszélve egy csapatmunka esetén.
Én inkább az elkülönített template-es megoldásokat preferálom, pont az átláthatóság miatt.

Erre gondolok, sematikusan:

template.html:

{user_name}
{user_age}

-------------

parser.php:

<?php
include "extra_foo.php"; // whatever, ahol a template feldolgozó lakik

.....

echo parse_template("template.html", array("user_name"=>$user->name, "user_age"=>$user->age));

?>

A template.html dizájnolását meg rá lehet bízni a külsősre is akár. De ez is csak egy megközelítés.

--
Coding for fun. ;)

Igen, csakhogz a parse_template fuggveny nem resze a PHP runtime-nak, kovetkezeskeppen a kezdok ilyen peldakat ki sem fognak tudni probalni. Kezdo peldakent mindig olyat kell adni, ami a nyelv adott eszkozkeszletevel elerheto, es a legegyszerubben bemutathato.

Raadasul, nagyon sok keretrendszer hasznalja az in-place PHP kod beirast, ilyen peldaul a Drupal es a WordPress is, raadasul nem elrugaszkodott feltetelezes arra szamitani, hogy a kezdok elso komolyabb munkajukat valoszinuleg ezzel a ket keretrendszerrel fogjak elvegezni, es nem jo, ha idegenkedve nyulnak az embedded PHP kodhoz, csak azert, mert valaki szerint ez nem szep. A PHP nyelv resze, raadasul integrans resze (belegondoltal mar, miert kell minden PHP fajlt <?php szoveggel kezdeni?), szoval en csak azert nem belyegeznem meg, mert sokan rosszul hasznaljak, hanem mar eleve a jo hasznalatot tuntetnem fel.

Szepek a nagy fenyes elvek, de ha kezdoknek irsz tutorialt, akkor le kell ereszkedned a szintjukre, es el kell felejtened a nagy es magasztos elveket amiket a munkad soran rutinszeruen kovetsz, mert azok szamukra nem allnak rendelkezesre, ott allnak egy szem felkinlodott XAMPP-pal a kezukben, es csodat szeretnenek latni. Es akkor fogjak vegigkoveti a sorozatodat, ha minden reszben adsz nekik egy-egy kisebb csodat.
--
Blog | @hron84
Üzemeltető macik

Jogos, amit mondasz, és nagyon nehéz megtalálni a helyes módszert. Őszintén elgondolkodtam azon, hogy mi a célravezetőbb: cli megközelítésben mutatni be a nyelvet, vagy az inkább használatos webes oldalról. Mivel a cli-vel elég gyorsan sarokba szorulnék (kevésbé látványos, és némely része teljesen ki is esik), ezért nem egészen járható út. A blogon levő példa inkább abból az irányból közelít, hogy a tanuló - feltételezhetően - valamilyen IDE-ben (ha máshol nem) már látott html markupot (sokan "webdizájner"ből akarnak átképződni fejlesztővé), így érthetőbb lesz számára az átjárás. Meglátjuk, hova vezet. Valójában ezzel a bloggal per pillanat egy totál kezdő srácot tanítok is, majd az eredmények igazolnak, vagy cáfolnak - elválik.
(Amíg a nyelv alapvető funkcióit nem ismeri, teljesen érdektelen, hogy a stringek mit tartalmaznak. - Majd a megfelelő időben inkább az (s)printf irányába küldöm, azzal is elég elegáns megoldásokat lehet összehozni.)
--
Coding for fun. ;)

A típusoknál írnék az == és === közötti különbségről, a phpban is sok előnye van annak, ha típusosan van összehasonlítva az egyenlőség.

A define('PI_ERTEK', '3.141592...'); szándékosan string? A const pedig float? + az osztályon belüli konstanst azon a ponton én egyáltalán nem említeném, mert lóg a levegőben. Osztályokról még szó sem volt, és a változók hatóköre sem világos még ezen a ponton (szerintem) nemhogy a konstansoké. Ráadásul ez a mondat:

"Csak osztályon belüli létrehozás" nem igaz, mert egy osztályon belüli konstans simán elérhető kívülről, példány nélkül, csak ki kell hozzá írni az osztály nevét, és kész.

Jó lenne, ha lehetne kommentezni. Egyébként abszolút támogatom a projektedet, nyilván a problémás részekre reagálok, ahogy mások is arra fognak, nem arra, ami úgy jó, ahogy van. :) Így tovább :)

A műveletek következő leckében lesznek. A define példa elírás volt, javítva, valamint kommentelés engedélyezve. A kifogásolt mondat valójában a szintaxisra vonatkozott. Másképp deklarálunk osztályon belül egy konstanst, és máshogy kívül. Legalábbis így tanultam.
--
Coding for fun. ;)

Én úgy gondolom, hogy vagy ez vagy az. Elfogadhatónak tartok egy olyan kódot, ami php de tényleg templateként van használva alap php függvényekkel megszakítva a folyamatosan "kiíratást", vagy triviális if ekkel, ciklusokkal. Ahol komolyabb kód van, függvények, stb. ott nevetségesen néz ki (szerintem) a php lezárásával kiíratni.

( sz332 v | 2015. 06. 15., h – 13:28 )

Esetleg nem ártana a megjelenítést elválasztani az adatbázis turkálástól...

( dblaci | 2015. 06. 16., k – 21:15 )

Egykét szerintem lényeges apróság:

<p> ből 5, mintha sortörésnek használnád. (??) a html logikája szerint ezeket a tageket le kell zárni. Vagy ott a <br/>

A selecten belüli whileben mintha az üres optionből annyi lenne, ahánynak értéke is van. Ha ez formázási dolog, akkor nagyon nem szép.

Én egy tanácsot adok, hogy a legbonyolultabb dolgokat se használd úgy, hogy megelégedsz azzal, hogy működik. Ez a pokolba vezető út, ha programozásról van szó. Nincs ok nélkül semmi. Ha egy kód hibás, addig keresed a hibát, amíg jó nem lesz. De ha a kód helyes, de egy ponton nem érted, hogy miért, akkor is addig keresd ezt, amíg meg nincs. Meglesz! De ha ezt kihagyod, akkor belezuhansz a semmibe, és a dolgok csak történni fognak veled, akaratodon kívül.

( dblaci | 2015. 06. 15., h – 22:24 )

+1: a mysql kapcsolat siekrtelensége esetén die megoldás, de akkor legalább a kiíratások előtt illik dieolni. Így elméletileg félig kiírt kódnál lehet a die, ami ugye elvileg rossz.

A tábla struktúráját nem látom, de ha van ilyen oszlop, hogy "tipusok" ami egy tipus (hiszen a tábla minden sora egy-egy típust tartalmaz), akkor ez az oszlop név NAGYON rossz. Ez egy ponton neked is nyilvánvaló volt, ezt biztosra veszem, csak nem nevezted át visszamenőleg, mert jó az úgy. Minden ilyen esetben visszamenőleg kell átnevezni, vagy újragondolni valamit, különben a káosz elhatalmasodik.

Figyelj mar, az egyel feljebbi hozzaszolasban nem latszanak a HTML kodok, mert a Drupal elnyeli a nem engedelyezetteket. Az &lt; es &gt; kodokkal ha lecsereled a kacsacsoroket, akkor meg latszodni is fog, amit irsz neki :-)

"Minden ilyen esetben visszamenőleg kell átnevezni, vagy újragondolni valamit, különben a káosz elhatalmasodik."

Hat, kodnal talan, de azert megneznem, hogy egy production kodban visszamenolegesen hogy irsz at egy adatbazissemat. Aztan az is lehet, hogy kulso forrasbol dolgozik.
--
Blog | @hron84
Üzemeltető macik

Kösz az észrevételt, nem tűnt fel, hogy hiányzik a lényeg az előzőből :D

A hozzáállásra akartam helyezni a hangsúlyt, milliószor látom, hogy az elejétől kerülgetik az emberek a sz*rt, amikor még triviális lenne refaktorálni, vagy tábla sémát változtatni. Aztán ahogy nő a projekt, egyre többször esnek hasra ugyanabban a szemétben. Persze minden ponton elhangzik az, hogy "hát, most már túl sok helyen kellene átírni", pedig visszagondolva egy "kicsivel korábban jó lett volna". :D

Konkrétan, amikor írta a tábla sémát, akkor logikusnak tűnt neki, aztán a kódnál egy ponton már biztos nem. Na akkor simán átírta volna a sémát, és kész. Én csak ennyiről beszéltem, nem a másik végletről, hogy egy lényegtelen elnevezés módosítás miatt az istent is újra kelljen tesztelni.

( Stryker | 2015. 06. 16., k – 10:43 )

Sikerült megcsinálnom nemsokára publikálom is, de előtte rendbe szedem :)