Sziasztok!
Az a kérdésem, hogy ha URL-ben paramétert adok át, amelyet a $_GET[] hozzáférésével érek majd el, s több paramétert szeretnék egyszerre átadni, akkor a base64_encode() vagy az urlencode() függvényt használjam? Nekem a base64 áll közelebb az elképzelésemhez, csak nem tudom, van-e valamilyen akadálya annak, hogy URL-ben használjam.
Biztonság most nem igazán számít, a szerver localhost-on fut. Lényegében egy webes alkalmazásról van szó, s a böngészőt használom GUI-nak. Ettől függetlenül biztonsággal kapcsolatos érveket is meghallgatok, pusztán jeleztem, ez itt most nem igazán szempont.
Esetleg kerülendő az URL-be valami oda nem illő karaktert, legyen mondjuk urlencode(base64_encode($string)) a megoldás?
- 7881 megtekintés
Hozzászólások
A bongeszod gondoskodni fog a parameterek kodolasarol, szerver oldalon meg automatikusan dekodolodnak, nem ertem a problemat.
"Nekem a base64 áll közelebb az elképzelésemhez"
Miert..?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
- A hozzászóláshoz be kell jelentkezni
Én biztos hogy nem bíznám a böngészőre! Ó istenem hány helyen láttam már olyat hogy ékezetes betűk, szünet, stb.. voltak benne, aztán csodálkoztak hogy mi az a %20 az adatbázisban :D
- A hozzászóláshoz be kell jelentkezni
azert az csunya lenne, ha egybol a $_GET-bol tolnal adatokat a db-be.
t
- A hozzászóláshoz be kell jelentkezni
+1. Ráadásul az ilyen adatküldésre a POST való.
- A hozzászóláshoz be kell jelentkezni
Azért egy pillanatra elbizonytalanodtam. Mi van, ha a stringemben van :, /, ?, & és efféle vidámságok, ékezetes betűk, netán cirill, görög betűk? Ezek mind közvetlenül mehetnek az URL-be? Erőst kétlem, hiszen az első 4-nek van különleges jelentése.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Escapeli, vagyis urlencodolja automatikusan, próbáld ki.
Szerk.: Az más kérdés, hogy az érkezési oldalon ezek a vidámságok mit művelnek, de odáig simán eljutnak.
Szerk.2: Itt meg tudod nézni.
openSUSE 12.2, vagy ami éppen jön.- A hozzászóláshoz be kell jelentkezni
Ird le, hogy mi a pontos use-case, sokfele megoldast lehet ajanlani. Peldaul, ha nagyon sok parametert akarsz atadni, akkor lehet, hogy jobban jarsz a JSON+Base64 komboval.
A masik kerdes pedig az, hogy biztos, hogy GET-et szeretnel? Szvsz a POST neha jobb.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ki kell választani menüből valamit. Ezen valamihez generálódik egy oldal, vannak input mezői. Ezeket POST-tal fogom elküldeni, a szerver számítások alapján kiköpi a végeredményt táblázatos formában. Ugyanakkor van két mező, amit nem kellene elfelejtsen akkor sem, ha új menüpontban új típusú méretezendő feladatot választ a felhasználó. Ez a két paraméter a megrendelő neve és a munka megnevezése. Ezeket vacak dolog minden méretezendő valaminél újra beírni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Én az ilyeneket sessionben szoktam tárolni, nem szeretek utaztatni semmit az url-ben.
openSUSE 12.2, vagy ami éppen jön.- A hozzászóláshoz be kell jelentkezni
Az sem kizárt, hogy magam is így csináltam volna, ha tudom, mi az a session. ;) Lehet, utánaolvasok. Ugyan már készen van, de nem árt, ha tudom, valaki felfedezte már előttem a langyos vizet. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Vagy sutiben tarolod.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Abban a sütiben, ami tiltva van a böngészőmben?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nezd, en ugy vagyok vele, hogy a latogato vagy engedelyezi a sutiket a site-omhoz, vagy nem akarja hasznalni a site-t. A suti a bongeszok beepitett funkcioja, MINDEN bongeszo tudja, meg egy nyuves cURL is, emiatt bizton szamithatok ra. A paranoiasok meg kezeltessek magukat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ha a suti tiltva van, akkor nem tudsz normalisan sessiont kezelni. Mert URL-be megsem rakunk session ID-t, hiszen akkor egy copypaste utan barki mas is a mi sessionunkben tudna garazdalkodni.
- A hozzászóláshoz be kell jelentkezni
OFF:
két oka van annak, hogy query paramétereket használunk, pontosabban egy, két gyakorlati következménnyel.
Az egyik a "linkelhetőség": például egy keresés eredménylistája tipikusan az, amit el szeretnék tárolni linkként, esetleg el akarom küldeni, stb. Ezért hívják a HTTP alkotói query paraméternek, ugyanis erre találták ki: egy keresési eredményt ugyan már tudj tárolni.
A másik pedig a history megfelelő működése, ami POST esetén nem érvényes.
Tehát alapvetően a query paraméter jelentősége az, hogy az alkalmazás egy állapotát vissza tudom állítani, arra "shortcut"-om van, és ezzel én tulajdonképpen egy undo-redo funkcionalitást is megvalósítok. Ez az állapot lehet, hogy részleges állapot, lehet, hogy tartozik hozzá egy köztes állapot (pl. bejelentkezés), de alapvetően az a cél, hogy az alkalmazás állapotát vissza tudjam hozni, ne kelljen újra keresni, ne kelljen újra elnavigálni, stb.
Design Patternileg ez egy memento.
Erről szól az URL-ben utaztatás. Hogy aztán ez értelmezhető-e emberileg avagy base64 encode-olt, az más kérdés.
Rengetegszer van az, hogy valamilyen alkalmazásból ezt a programozók, mindenféle ökölszabályt, framework convention-t, esetleg felhasználó hülyének nézést (a felhasználó egyszerre butább és okosabb mint hisszük) betartva kifelejtik, és nagyon nehéz visszavarázsolni.
Szóval egy keresés esetén, vagy oldalak, modulok közti navigáció esetén én azt javasolnám, utaztasson URLben, hogy a felhasználó ott tudja magát találni ahol akarja, ne kelljen valami előzetes állapotból visszamásznia.
- A hozzászóláshoz be kell jelentkezni
A keresesben egyetertek, a modulok kozti navigacioban csak reszlegesen. Peldaul egy varazslo eseteben a kovetkezo lepes utazzon az URL-ben - az elozo lepes adatai viszont lehetoleg ne. Egy adatbazisjelszot peldaul akkor sem akarnek URL-ben latni, ha az egy varazslo resze.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Röviden: a GET idempotens, a POST meg nem :)
- A hozzászóláshoz be kell jelentkezni
De szep is lenne, ha igy lenne.
Gondolj bele, ennek a topiknak az URL-jere adott GET sem idempotens, hiszen maga a mogottes dokumentum valtozik.
Akkor idempotens valami, ha minden meghivasa ugyanazt az eredmenyt adja, amennyiben a parameterek megegyeznek.
Inkabb ugy mondanam, hogy a GET nemmodosito muvelet.
- A hozzászóláshoz be kell jelentkezni
De nem a "GET" által átvitt információ változtatja meg az oldalt, hanem az időközben "POST"-tal betolt adatok.
- A hozzászóláshoz be kell jelentkezni
Az, hogy az URL-ben vannak query parameterek (ami a $_GET tombben lesz PHP-ban) teljesen fuggetlen a HTTP verbtol, azaz POST keresnek is lehetnek "GET parameterei"
- A hozzászóláshoz be kell jelentkezni
Nem hosszú a cucc, két megnevezés, gyakorlatilag néhány tíz karakteres stringből 2 db.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
akkor miért akarod kódolni?:o
- A hozzászóláshoz be kell jelentkezni
Azért, mert ha egy stringet beteszek egy linkbe, amelyben van mondjuk egy & jel, akkor abból felfordulás lesz, továbbá azért is, mert nem vagyok meggyőződve arról, hogy URL-ben bármilyen ámokfutást el lehet követni. Már abból erre következtetek, hogy létezik urlencode() függvény.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
ha formban adod át a paramétereket, akkor nem fog olyat tudni elkövetni, ami szétgyalázza az url-t.
Javascriptből már tudsz galádságokat, de ott meg urlencode-olni kell, mert szegény nem tudja hogy a programozó hülye-e vagy sem.
Egyébként, ha utána postolni akarsz, ott is base64 -el kódolj mindent, mert ott is key=value&key2=value2 a formátum!:D
- A hozzászóláshoz be kell jelentkezni
Értelek, csak amit eddig csináltam, azt nem szeretném széttúrni. Ezért az oldalsó menüket hagyom linknek, s nem lesz belőle form. Egyelőre nem látom okát annak, hogy ne úgy csináljam, ahogy csináltam.
A derültséged okát nem értem. Legyen mondjuk ez a string, amit át szeretnék vinni:
$m = 'malac&leguan=zold';
echo ("<a href=\"index.php?m={$m}\">Ide kattints!</a>\n");
Ezután a $_GET['m'] értéke szerintem nagyon nem az lesz, mint amit a fenti stringben megadtam, hanem 'malac' lesz. Éppen ezért érzem úgy, hogy használnom volna jó az urlencode() függvényt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Vessetek a mókusok elé, így csináltam:
$mm = urlencode (base64_encode (serialize (array ($_POST['megrendelo'], $_POST['munka']))));
Aztán ezt a $mm-et szépen beraktam a linkbe, &mm={$mm} formában.
Működik pont úgy, ahogy szerettem volna. Az meg nem izgat, ha gány. Én hardware-es vagyok. ;)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
így már értem...:)
- A hozzászóláshoz be kell jelentkezni
Tegyük hozzá, csak mentegetőzésként írtam, hiszen nem vagyok programozó. A megoldásom legfeljebb nem elegáns, nem gyors, kicsit terjengős, ám szerintem jó. És itt a jóság alatt azt értem, hogy bármi átvihető így gond nélkül. Talán a binary safe a helyes kifejezés.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
[Feliratkozás]
- A hozzászóláshoz be kell jelentkezni