ugrás a tartalomhoz

Query string érték kiírása a weblapra?

DaWe35 · 2014. Feb. 25. (K), 03.11
Üdv! Az lenne a kérdésem, hogy egy Query String értéket hogyan tudok PHP-val beilleszteni az oldalra?
pl: http://valami.hu/valami.php?asd=123

És az oldalra írja ki hogy 123

Köszönettel: DaWe
 
1

Alapok

Hidvégi Gábor · 2014. Feb. 25. (K), 09.00
Változók. Kiírásra én a print "függvényt" szoktam használni.
2

<?php // a teljes get

szabo.b.gabor · 2014. Feb. 25. (K), 09.16
<?php 
// a teljes get tomb
print_r($_GET);

//csak az asd
echo $_GET['asd']; 
?>
több info ezekről a dolgokról
16

Thanks

DaWe35 · 2014. Már. 2. (V), 21.48
Köszönöm, ezt kerestem, megy. Köszi!
3

_GET ['asd']

Vilmos · 2014. Feb. 25. (K), 09.18
A "valami.php" paraméterként megkapja az "asd" változót, így éred el:

echo '<html>'
...
echo $_GET['asd']
...
echo '</html>'
(Query-n általában sql kifejezés értendő, amit idéztél az egy link.)
Bevezető a PHP nyelv használatába:
http://php.webprog.biz/phptanfolyam/bevezeto
4

Query string. Amit "idézett",

Endyl · 2014. Feb. 25. (K), 09.38
Query string.
Amit "idézett", az pedig nem link, hanem URL.
6

Kösz.

Vilmos · 2014. Feb. 25. (K), 10.12
Ezt így nem ismertem.
5

Ha már mindenképpen oda

bamegakapa · 2014. Feb. 25. (K), 10.03
Ha már mindenképpen oda akarsz rakni valami HTML-t, akkor mutasd helyesen:
echo '<!DOCTYPE html>';
echo '<html>';
...  
echo htmlspecialchars($_GET['asd']);
...  
echo '</html>';
Doctype nélkül csak a szívás lesz ezerrel. A HTML5 doctype-ban viszont már akár ki is hagyhatod a html taget, opcionális.

Ha már úgyis itt vagyunk, érdemes megemlíteni, hogy direktbe sose iratunk ki query string változót, vagy bármi mást, ami kívülről jött. HTML esetén htmlspecialchars használata szükséges.

PHP-ban kötelező a pontosvessző.

A linkelt tutorialba belepillantottam, annyit láttam, hogy adatbáziskezelést az elavult mysql_ függvényekkel tanít, így ezt a részt legkevésbé sem javaslom. Valamint a hibarejtő operátorral (@) kapcsolatban rendkívül rossz tanácsokat ad.

Más bajom nincs :).
7

:)

Vilmos · 2014. Feb. 25. (K), 10.38
Például; itt is "elavult" adatbázis kezelés van, pedig igazán tekintélyes oldalnak mondható. http://nyelvek.inf.elte.hu/leirasok/PHP/index.php?chapter=16 Tud valaki haladó szellemű bevezetőt?

A "htmlspecialchars" használatával kapcsolatban a "mindig kötelező" erős túlzás. Az első oldal amibe belecsöppentem; ott mezőnként kellett válogatni, ez most védendő, vagy direktben kiírandó. Az admin felületen nem alkalmaztak sem bb-code, sem másmilyen támogatást. Kiemelés, soremelés, linkek, mind html-ben lettek feltöltve. Kívülről jött minden, csak nem direkt kiírás volt, hanem előbb átment adatbázisba a tartalom. Egy weblaboros form szerkesztőig eljutni, az mennyire gyakori?

Ui. Nem anyanyelvem a PHP. A "$" jel is lemarad a változók előtt pár nap kihagyás után.
8

Nem csesztetésből írtam, csak

bamegakapa · 2014. Feb. 25. (K), 11.42
Nem csesztetésből írtam, csak javítottam. PHP-t én se nagyon használtam mostanában.

Az elavult nem idézőjelbe való, mivel hivatalosan is deprekálva van a mysql_ csomag, azaz hamarosan kikerül a PHP-ből. Ráadásul a paraméterezett kverik nyújtják a legbiztosabb védelmet az SQL injekció ellen, arról nem is beszélve, hogy tisztább lesz a kód is. Ezt meg csak a mysqli és a PDO támogatja PHP-ben, a mysql_ nem. Nem ismertem az ELTE PHP tananyagát, de ezek szerint nem mondhatóak tekintélyesnek ebben a témában, valószínűleg jó rég frissítették az anyagukat (és ez a jobbik eset). Sajnos jó tutorialt nem ismerek (magyarul legalábbis), kezdőként én is beszoptam elég sok szörnyű tananyagot, tény, hogy jó lenne valami, ahová irányíthatnánk a kezdőket.

A "htmlspecialchars" használatával kapcsolatban a "mindig kötelező" erős túlzás.

Lehet félreérted, én azt írtam, "direktbe sose iratunk ki query string változót, vagy bármi mást, ami kívülről jött" (ebben benne van az is, hogy előtte elmented az adatbázisba, és onnan iratod ki). Természetesen helyzete válogatja, hogy milyen tisztítást/eszképelést használsz rajta. A htmlspecialchars akkor kötelező, ha HTML-be iratsz valamit, kivéve persze, ha HTML-t (és akarod, hogy az HTML maradjon), de ez esetben is érdemes a HTML Purifier-t végigtolni rajta. Persze bizonyos esetekben dönthetsz úgy, hogy ezt kihagyod, bizonyos okokból - de tudnod kell, hogy meghoztad ezt a döntést, a kezdők viszont nem tudják, ezért kell elmondani nekik. Majd ha megértik az ilyen szabályok okát, akkor felülírhatják őket, addig viszont jobb, ha a szabályokat követik.
9

Mysqli_, hibaelnyomó operátor @

Vilmos · 2014. Feb. 25. (K), 14.28
Htmspecialchars() tényleg jobb alapértelmezésnek, nagyságrendileg gyakrabban szükséges, mint például a "bb kódos" formázás.

Mysqli_; nem vagyok tőle feldobva. A paraméterezett kifejezés opció, figyelmen kívül hagyható. Viszlát biztonság.(PDO-t nem ismerem erről az oldaláról) Ja, és mit kezdesz az addigi munkáiddal? Mintha szándékosan úgy lenne megtervezve, hogy ne tudd átírni. Egy betű különbség a függvény nevekben, a paraméterek viszont mások. Ha időmilliomos vagy nem gond, ha sosem használtad direktben a függvény készletet mivel saját könyvtárad van, akkor sem.

(5) Korábbi téma, de nem értem ...
A hibaelnyomást szerintem jól magyarázza. Meggátolandó minden ötletszerű kiírkálás amit a futtató rendszer produkál, amennyiben hiba adódik azt elkapjuk, és saját hatáskörben kezeljük le.
http://php.webprog.biz/phptanfolyam/alapok/19-operatorok-III
Mi evvel a gond? Az alapelv, vagy a megvalósítás?
10

Ja, és mit kezdesz az addigi

bamegakapa · 2014. Feb. 25. (K), 15.02
Ja, és mit kezdesz az addigi munkáiddal?

Mindenhol el van mondva, mi a baj a spagettikóddal. Szerencsés esetben igen kevés tényleges mysql_ utasítás szerepel a kódodban, főleg azoknál a nagyobb projekteknél, ahol problémásabb lehet az átalakítás.

Ha már mysqli vagy PDO, csakis paraméterezett kverik. Hogy érted, hogy figyelmen kívül hagyható?

Ami a hibaelnyomást illeti, kezdőknek a létezését sem szabadna említeni :). Egyszerűen borzasztó ritka az olyan szituáció (én még nem találkoztam ilyennel, csak olvastam róla :D), ahol tényleg ez a legjobb megoldás. Fejlesztés közben az a jó, ha látod a hibákat, a hiba azért van, hogy tudj róla, élesben meg eleve ki kell kapcsolni a hibák megjelenítését (valahol eleve perverz, hogy a HTML-ben jelennek meg a hibák, van, aki fejlesztés közben is a logot használja helyette). Erről azonban nem írnak, sőt javasolják a @ használatát, újabb kezdőgenerációknak okozva többórás hibakeresési rémálmokat (és ráadásul rohadt lassú is). Bárcsak valaki annó elmondta volna nekem ezeket...

A többi részét nem néztem a tutorialnak, általában van 3-4 dolog amit elsőre megnézek egy ilyennél, ha ezeket bukja, akkor kuka :).
12

Figyelmen kívül hagyható

Vilmos · 2014. Feb. 25. (K), 23.20

$txt = "SELECT * FROM tabla $injection";
$res = mysqli_query( $link, $txt );
Lehet úgy használni a mysqli-t mint az elődjét. Semmi sem tiltja. A prepared statement (ha jól emlékszem), az egy opció.
Ráadásul, bonyolultabb kifejezést nem függvény paraméterként szokás összerakni, hanem külön sztringben. Akkor meg ott vagyunk ahonnan indultunk. Az előkészítés régről ismerős, dupla idézőjelen belüli bűvészkedés a változókkal, ugyanaz a minta. Szeretném ha többet tudna a javasolt felület, csak valahogy nem látszik rajta. Inkább a fegyelmen múlik a dolog.

A kukacos hibaelnyomást megvizsgáltam. Fogjuk rá, babona volt. Egyes függvények, ha van, ha nincs, mindenképp üzennek a képernyőre. Szerencsére az error_reporting() -ra hallgatnak.
13

Természetesen támogatja a nem

bamegakapa · 2014. Feb. 26. (Sze), 01.41
Természetesen támogatja a nem paraméteres kveriket is - elég nehéz lenne tiltani, hogy egy előre összefűzött sztringet adjál át kveriként, ha belegondolsz. Nem minden kverinek van paramétere eleve. (ráadásul így is baromi nehéz kivezetni a mysql_ családot, hát még ha nem lehetne simán kverizni :))

Paraméteres kverikkel nincs sztring-összefűzögetés (az olvashatatlanság netovábbja), meg rakás idézőjel megnyitva több szinten, legalábbis nem kéne, hogy legyen. Fegyelem lehet, hogy kell hozzá, de amióta átálltam (annó nagy morogva), nem is áll rá a kezem a régi módszerre (egyedül az IN() listákkal van egy kis kellemetlenség, de megoldható).
$stmt = $db->prepare("SELECT * FROM tabla WHERE x = ?");
$stmt->bind_param($injection);
$stmt->execute();
és pápá SQL injection.
14

Kis pontosítás

Vilmos · 2014. Feb. 26. (Sze), 16.00
Leírás szerint kérdőjelenként az adat típus meghatározandó.

$stmt->bind_param( 's',$injection );  
Találtam másik ELTE-s leírást, ez gyakorlatiasabb mint az előző. http://ade.web.elte.hu/wabp/lecke5_lap1.html
Legközelebb majd használom. Hasznos beszélgetés volt.
15

Eh, jól elszúrtam, kösz :).

bamegakapa · 2014. Feb. 26. (Sze), 16.12
Eh, jól elszúrtam, kösz :). Meg közben rájöttem arra is, hogy a prepared statementről beszéltem több helyen, de hülye fejjel magyarul akartam írni, aztán valahogy paraméterezett lett az előkészítettből. Örülök, ha így is átjött...

Ez a leírás egy fokkal jobb, de még mindig a mysql_-el kezd.

Nekem is hasznos volt a beszélgetés.
11

Ha egy ilyen alap dolgot nem

Kubi · 2014. Feb. 25. (K), 15.56
Ha egy ilyen alap dolgot nem tudsz megoldani, akkor a legjobb az ha veszel egy könyvet (nekem a "php 24 óra alatt" jött be annó nagyon, lehet van már újabb/jobb), és azt elolvasod, meg csinálod a példa kódokat.

Ez az alapozás minimum szükséges hogy nekikezdj a php-s világnak, utánna jöhet hogy escapelés, meg pdo (vagy mysqli) és az összes többi finomság amivel jó és biztonságos kódot írhatsz, addig ne is fárasszuk őt ilyenekkel.
17

10 évvel később

DaWe35 · Okt. 22. (K), 19.19
Nagyon durva, hogy ez az oldal még mindig működik, és visszanézhetem, hogy milyen hülye kérdéseket tettem fel 10 éve, amikor iskola mellett elkezdtem tanulni a programozást.
Azóta vagy 15 nyelven programoztam, rengeteg megrendelésen és saját projekten vagyok túl. A sok-sok év alatt egyetlen dolog változatlan, hogy nagyon odafigyelek az SQL injection-re