- Samsung Galaxy S25 - végre van kicsi!
- Apple iPhone 17 Pro Max – fennsík
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Samsung Galaxy Fit 3 - keveset, de jól
- Okosóra és okoskiegészítő topik
- Google Pixel 10 és 10 Pro összehasonlító gyorsteszt
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Apple iPhone 16 - ígéretek földje
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- iPhone topik
Új hozzászólás Aktív témák
-
#5918
fordfairlane
veterán
Brown ügynök
#5916
fordfairlane
veterán
válasz
Brown ügynök
#5916
üzenetére
A PHP-nak mindenképp le kell futnia a PHP értelmezőn, mert preprocesszált nyelv. Vagy publikus szerverre rakod, és URL-t adsz a validátornak, vagy te privátban futtatod a PHP-t, és a HTML kimenetet a böngészőből fájlba mented, vagy pedig vágólapon keresztül bemásolod a validátor "Direct Input" ablakába. Ha ez így macerás, esetleg az előbb ajánlott a Firefox plugin egyszerűsítheti a dolgot.
-
#5915
fordfairlane
veterán
Brown ügynök
#5912
fordfairlane
veterán
válasz
Brown ügynök
#5912
üzenetére
A validatornak azt kell kapnia, amit a böngésző kap a szerveredtől a php fájl futtatásakor. Ha a validatornál fájlfeltöltést használsz, akkor a php szkript által előállított html kimenetet kell produkálnod a validátor felé fájl formájában, nem magát a szkriptet.
-
#5519
fordfairlane
veterán
fordfairlane
veterán
Tényleg, jut eszembe, ki milyen editort használ mostanában PHP-hoz?
Én bár 10 éve Homesite-ot használok, és már nagyon megszoktam, kezdek megbarátkozni az Aptana studioval. -
#5517
fordfairlane
veterán
Sk8erPeter
#5516
fordfairlane
veterán
válasz
Sk8erPeter
#5516
üzenetére
Akkor viszont az általános, valóban érzékelhető, eme bolygón született weblapkészítők számára hasznos gyakorlati jelentőségével még mindig nem vagyok tisztában.
Ezzel én sem. A View egy lekérdezés szerveroldali prezentációban, virtuális tábla formájában, de mivel lekérdezéseket kliensoldalon is lehet eszközölni (kliensoldalként a megjelenítőréteg nyelvét értem, PHP vagy más), most már akár mysql-ben is akár több query-t is lehet egymásba ágyazni, sok értelmét nem látom. Anno régen, mikor SQL-t tanultam, akkor a példa a View-k használatára olyan eset volt, amikor az adatbázis adminisztrátor olyan szinten akarta korlátozni a hozzáférést az adatok és az adatszerkezetekhez, amit a beépített jogosultságkezeléssel nem lehet megoldani.
Előfordulhat, hogy view-k segítségével átláthatóbbá tehető bonyolult program- és adatszerkezet, és csak én nem használtam még eleget, nem ismerem a módszertant, mindenesetre egyszerűbb szituációk esetén nem hinném, hogy bármi haszna volna.
-
#5515
fordfairlane
veterán
Sk8erPeter
#5506
fordfairlane
veterán
válasz
Sk8erPeter
#5506
üzenetére
"Ez elég jól hangzik, ezek szerint biztonsági szempontok is közrejátszhatnak abban, hogy view-t használjunk."
Amennyiben el akarod rejteni a táblaszerkezetet a lekérdező elől, akkor számíthat, de egyébként fölöslegesnek tartom. Egy plusz absztrakciós szintet visz be. Esetleg még akkor lehet hasznos, ha elképesztően bonyolult táblaszerkezet van, de csak néhány jellemző nézetre van szükség a program több részén, egyébként csak fölöslegesen bonyolítja a dolgokat.
-
#5330
fordfairlane
veterán
Speeedfire
#5329
fordfairlane
veterán
válasz
Speeedfire
#5329
üzenetére
Escape van, már a legelején, ez csak egy kódrészlet volt.
Hát az totál rossz, ebben a formában nem escapel semmit. Ha már mindenáron a $_POST tömböt előre kiescapelni akarod:
$_POST = array_map('mysql_real_escape_string',$_POST);
-
#5328
fordfairlane
veterán
Speeedfire
#5325
fordfairlane
veterán
válasz
Speeedfire
#5325
üzenetére
$sqlJelszo = mysql_query("select jelszo from szapar_felhasznalo where fnev='".$_POST['fnev']."' jelszo='".$_POST['jelszo']."' ");
if (!$sqlJelszo) {
die('Hiba: ' . mysql_error());
}Nagyon csúnya ez így. Először is használj saját függvényt, amelyik lefuttatja a query-t, és kiírja az sql hibát.
function sql_query($q) {
$res = mysql_query($q);
if (mysql_errno()) {
die('Hiba: ' . mysql_error());
}
return $res;
}Másrészt pedig nem használsz escapelést a szöveges tartalomnál, ami súlyos hiba.
$query = 'select jelszo from szapar_felhasznalo';
$query .= ' where fnev="'.mysql_real_escape_string($_POST['fnev']).'"';
$query .= ' AND jelszo="'.mysql_real_escape_string$_POST['jelszo']).'"';
$jelszo_res = sql_query($query);Harmadrészt, és ez csak egy javaslat: Már most szedd szét az action mappinget magától az actionöktől. Tehát az if-elseif-else ág csak függvényeket hívogasson, mást ne csináljon, és külön függvényekbe rakd az egyes funkciók implementációját, különben makaróniként fog tekeregni nemsokára a kód a rengeteg globális változójával, amik egymást írják felül.
Szerk: Ja igen, kimaradt az " AND ", tényleg. Javítom én is
-
#5028
fordfairlane
veterán
Sk8erPeter
#5027
fordfairlane
veterán
válasz
Sk8erPeter
#5027
üzenetére
A belinkelt oldalon a felhasználói kommentekben ott vannak a példák. A stripslashes-t akkor kell meghívni, ha ez az opció be van kapcsolva. Ezt le lehet kérdezni a get_magic_quotes_gpc()-vel.
Itt egy példa:
<?php
if (get_magic_quotes_gpc()) {
function stripslashes_gpc(&$value)
{
$value = stripslashes($value);
}
array_walk_recursive($_GET, 'stripslashes_gpc');
array_walk_recursive($_POST, 'stripslashes_gpc');
array_walk_recursive($_COOKIE, 'stripslashes_gpc');
array_walk_recursive($_REQUEST, 'stripslashes_gpc');
}
?> -
#5026
fordfairlane
veterán
Sk8erPeter
#5025
fordfairlane
veterán
válasz
Sk8erPeter
#5025
üzenetére
Akkor magyarul ilyen esetben csak az a megoldás, hogy ha automatikusan escape-elődik pl. az összes $_POST érték, és ezzel tisztában vagyunk, akkor először alkalmazzuk a stripslashes() fv.-t, majd a mysql_real_escape_string() fv.-t az adatbázisba való feltöltéshez (amit amúgy is kellene, csak a stripslashes() nélkül már duplán lenne escape-elve)?
A megoldás az lesz, hogy PHP 6-ban már eleve nem is lesz ilyen opció, végleg eltűnik, akárcsak a register_globals.
Csak mert nálam is van egy hasonló probléma, de a mysql_real_escape_string() fv.-t nem szeretném elhagyni, mert ki tudja, később nem lesz-e PHP-verzió-váltás vagy egyéb módosítás (pl. az általad említett opció kikapcsolása).
Annak idején mikor a PHP-ba belekerült ez az automatizmus, az egyszerű használhatóság volt a jelszóé s a biztosnág, mivel a kiescapeletlen stringek együtt a register_globalssal azt eredményezte, hogy tömegével készültek a könnyen feltörhető PHP oldalak. Azonban az alapelv eleve hibás. Azt feltételezi, hogy ha kapsz egy stringértéket $_GET, $_POST vagy $_COOKIES-en keresztül, azt te szinte minden esetben adatbázisműveletre használod fel. Régebben talán igaz lehetett ez, amikor a PHP kezdetleges volt, egyetlen előnye az egyszerű használhatóság volt, de ma már a PHP rengeteg dolgot tud, ami nem adatbáziskezeléssel kapcsolatos.
Egyébként sajnos így van, ha van rá esély, hogy a magic_quotes_gpc be lesz kapcsolva a scripted felhasználása helyén, akkor a stripslashes-t kell feltételes módban és tömbre rekurzívan meghívni, mielőtt bármi műveletet hajtasz végre a stringparaméterekkel.
-
#5021
fordfairlane
veterán
Speeedfire
#5020
fordfairlane
veterán
válasz
Speeedfire
#5020
üzenetére
Ilyen akkor történik, ha a PHP-ban be van kapcsolva a magic_quotes_gpc opció. Ilyenkor a PHP az összes $_GET, $_POST, $_COOKIES értéket magától kiescaspeli. Érdemes kikapcsolni, illetve ha ez nem járható út, akkor eltávolítani az automatikusan bekerülő backslasheket, mert nem biztos, hogy egyből adatbázisba kerülnek ezek az értékek, hiszen sokszor van form esetében a bevitt adatok kiírása még adatbázisba írás előtt, hiba vagy adatmegerősítés esetén pl..
Itt van egy példa, hogyan lehet eltávolítani, de a felhasználói kommentekben is akadnak hasznos tanácsok:
http://www.php.net/manual/en/security.magicquotes.disabling.php
-
#5019
fordfairlane
veterán
Speeedfire
#5017
fordfairlane
veterán
válasz
Speeedfire
#5017
üzenetére
A mysql_real_escape_string-et adatbázisba beírásnál kell használni, de magába az adatmezőbe backslashek nélkül kell, hogy bekerüljön a tartalom. Ha kiolvasásnál plussz backslash karakterek kerülnek elő, akkor eleve nem jól lett beírva.
-
#4951
fordfairlane
veterán
whYz
#4944
fordfairlane
veterán
-
#4908
fordfairlane
veterán
PazsitZ
#4904
fordfairlane
veterán
válasz
PazsitZ
#4904
üzenetére
A mysql_real_escape_string semmit nem szűr ki. Azokat a karaktereket alakítja át (escapeli), amelyek az SQL-ben speciális jelentéssel bírnak, vezérlőkarakterek. Ezeket megjelöli úgy, hogy ne vezérlőkaraktereknek, hanem a tartalom részeként kerüljenek felhasználásra a queryben. Nem feltétlenül támadást jelent a dolog, hisz ilyen karakter az idézőjel is, ami lezárja a stringet, de ilyen karakter szöveges tartalomban előfordulhat.
-
#4892
fordfairlane
veterán
Speeedfire
#4890
fordfairlane
veterán
válasz
Speeedfire
#4890
üzenetére
"fordfairlane: ennyire ronda lenne a forrás?
"Legalábbis az én szememnek az.
-
#4889
fordfairlane
veterán
Speeedfire
#4885
fordfairlane
veterán
válasz
Speeedfire
#4885
üzenetére
Atyavilág, ezt a spagettikódot.
-
#4837
fordfairlane
veterán
zeix
#4832
fordfairlane
veterán
if(is_uploaded_file($_FILES['userfile']['tmp_name']))
-
#4150
fordfairlane
veterán
cucka
#4140
fordfairlane
veterán
Egy egész jó adatbáziskezelő réteg. Nekem egyrészt a hibakezelése tetszik, másrészt pedig az, hogy a query paramétereket lehet bindparam-sszal hozzárendelni magához a query stringhez (mint az Oraclenál, egész könnyű átállítani az egészet Oraclera utólag a fejlesztéseket). Mezőket pl. nem kell escapelni idézőjellel, mysql_escape függvényekkel sem, ezt automatikusan elvégzi a string típusoknál.
Már írtunk is egy komplett adatbáziskezelő osztályt, ami a PDO-ra épül rá, új fejlesztéshez egy éve csak ezt használjuk.
-
#4137
fordfairlane
veterán
Sk8erPeter
#4136
fordfairlane
veterán
válasz
Sk8erPeter
#4136
üzenetére
Érdemes PDO-t használni, mostanában szinte teljesen rászoktam. Kapcsolódásnál meg lehet adni neki, hogy query hibánál exceptiont dobjon, amit aztán lehet kezelni egy globális exception handlerben.
-
#3617
fordfairlane
veterán
Tele von Zsinór
#3616
fordfairlane
veterán
válasz
Tele von Zsinór
#3616
üzenetére
Még egy kis info: html-ben valid, ha nincs idézőjelben, xhtml-ben viszont invalid.
Tudtommal a HTML4 szerint az attribútumértéket akkor nem kell idézőjelbe tenni, ha numerikus, egyébként igen, XHTML esetén mindig kötelező. Én mindig idézőjelek közé rakom, nem érdemes spórolni vele.
-
#3614
fordfairlane
veterán
Odiepapa
#3613
fordfairlane
veterán
válasz
Odiepapa
#3613
üzenetére
Cucka, megtenned, hogy gyorsan felvazolod ennek a megoldasat?
Bizonyára valami olyan megoldásra gondolt, hogy belépésnél eltárolod a kliensgép IP címét és/vagy user agent stringjét ($_SERVER["REMOTE_ADDR"] , $_SERVER["HTTP_USER_AGENT"]) , amit minden oldallekérésnél ellenőrzöl, hogy stimmel-e. Ha nem stimmel, az az esetek praktikusan 100 százalékában session hijack próbálkozást jelent.
-
#3595
fordfairlane
veterán
Sk8erPeter
#3593
fordfairlane
veterán
válasz
Sk8erPeter
#3593
üzenetére
$headers .= "From: =?ISO-8859-2?Q?".base64_encode($felado_neve)."?= <$felado>" . "\r\n";
Q betű azt jelzi, hogy a szöveg Quoted enkódolású. Ha base64-et használsz, akkor =?ISO-8859-2?B?".
-
#3590
fordfairlane
veterán
Sk8erPeter
#3587
fordfairlane
veterán
válasz
Sk8erPeter
#3587
üzenetére
A quoted_printable_encode() csak 5.3.0-nál vagy afelett elérhető, ennél sajnos pont eggyel régebbi van, így más megoldáshoz kell folyamodnom.
A PHP function reference oldalon a felhasználói kommentek közül az elsőben ott van implementálva régebbi verziókhoz.
$headers .= "From: $sender_name <$sender_name>" . "\r\n";
A relációjelek közé az emailcím megy, nem a neve.
$headers .= "From: =?ISO-8859-2?Q?".base64_encode($sender_name)."?= <$sender_name>" . "\r\n";
Ez azért nem jó, mert szintén a név kerül az emailcím helyére, ezen kívül a kódlapdefiniálás után következik az átvitel kódolás jele, ami Q, ha Q enkódolt, vagy B, ha base64-es. Tehát jelen példa helyesen:
$headers .= "From: =?ISO-8859-2?B?".base64_encode($sender_name)."?= <$sender_address>" . "\r\n";
-
#3586
fordfairlane
veterán
Sk8erPeter
#3583
fordfairlane
veterán
válasz
Sk8erPeter
#3583
üzenetére
Az lehet a probléma, hogy nem szabályosan van megformázva a From mező, ezért kapsz különféle eredményeket a különféle mail kliensekben. Azért is érdemes erre jobban odafigyelni, mert a spam figyelő szoftvereken is könnyebben fennakadhatnak az ilyen hibákkal tarkított mailek.
A From mező így néz ki: "From: email@cim.com\r\n" vagy "From: nev <email@cim.com>\r\n"
Ha a névben szerepelnek nem ASCII karakterek, akkor pedig base64 vagy Q encode-ot kell használni, de ez minden fejlécmezőre vonatkozik, függyetlenül attól, hogy from subject vagy más.
RFC2047 a "8. Examples" részt érdemes megnézni.
-
#3582
fordfairlane
veterán
Sk8erPeter
#3580
fordfairlane
veterán
válasz
Sk8erPeter
#3580
üzenetére
Érdemes kipróbálni a quoted_printable_encoding-ot.
$mime_subject = "=?UTF-8?Q?".quoted_printable_encode($subject)."?=";
-
#3496
fordfairlane
veterán
meone
#3494
fordfairlane
veterán
Fogsz egy változót, amit minden sor kiírásakor növelsz eggyel.
$i = 0;
while ($sor = mysql_fetch_array($eredmeny,MYSQL_ASSOC)) {
$i++;
echo "<tr><td>${sor['evf']}</td><td>${sor['szak']}</td>.......<td>${sor['k6']}</td></tr>";
}Ezután megvizsgálod, hogy páros, vagy páratlan-e, ezt a maradékos osztással (% operátor) a legegyszerűbb:
$i = 0;
while ($sor = mysql_fetch_array($eredmeny,MYSQL_ASSOC)) {
$i++;
if($i%2) echo "<tr class='zold'>";
else echo "<tr class='sarga'>";
echo "<td>${sor['evf']}</td><td>${sor['szak']}</td>.......<td>${sor['k6']}</td></tr>";
}Ezután minden sor felváltva 'zold' és 'sarga' nevű style class azonosítót fog kapni, amit aztán úgy formázol, ahogy jólesik.
<style type="text/css">
.zold {
background-color: green;
}
.sarga {
background-color: yellow;
}
</style> -
#3428
fordfairlane
veterán
Sk8erPeter
#3426
fordfairlane
veterán
válasz
Sk8erPeter
#3426
üzenetére
Remélem érthető, mire akarok kilyukadni
Mi a kérdés?
Hash-t tárolsz, azt veted össze loginnál, oké. Nincs további teendő ezzel szerintem. -
#3420
fordfairlane
veterán
Sk8erPeter
#3416
fordfairlane
veterán
válasz
Sk8erPeter
#3416
üzenetére
Most akkor kissé már össze vagyok zavarodva, akkor lényegében azt is mondhatnánk, hogy tök feleslegesek a titkosítások, mert úgyis mindent meg lehet kerülni.
A hash algoritmus egy titkosítási módszer. A lényege, hogy az eredeti adatfolyamot helyettesítjük egy lenyomattal, ezt hívják hash kódnak. Miért jó az, ha a hash kód van meg az eredeti adatfolyam helyett? Mert a hash kód ismerete, kiszivárgása sem jelent problémát, elvileg a kódból nem lehet egyszerű eszközökkel "kinyerni", visszafejteni az eredeti adatokat. A hash kódokat több helyütt is használják. Ami nem mindegy, hogy mire használjuk, mit akarunk vele meggátolni.
Gyakorlatilag miért nincs ebben a konkrét esetben jelentősége? Mert a hash kód a leírt rendszerből nem szivároghat ki. Abban az esetben juthat hozzá a hash kódhoz a támadó, ha az adatbázis tartalmát ki tudja elolvasni. Mikor tudja a támadó kiolvasni az adatbázis tartalmát, akár hash kód van benne, akár a plain text jelszavak? Hát elvileg csakis akkor, ha már van közvetlen hozzáférése hozzá. Ha pedig már közvetlenül hozzáfér az adatbázishoz, a jelszavakhoz, akkor valószínűleg egy egyszerűbb site-nál hozzáfér minden adathoz közvetlenül, akár írási joggal. Ebben az esetben a jelszavaknak meg már nincs jelentősége.
Persze egy olyan rendszernél, ahol a jelszavakat ismerve további járulékos károkat lehet okozni (ugyanazzal a név:jelszó párossal más helyre is be lehet lépni pl.), akkor érdemes inkább hash kódot tárolni, úgy egyébként is ez a korrekt megoldás, de nem érdemes csak emiatt elbonyolítani egy egyszerűbb rendszert.
-
#3414
fordfairlane
veterán
cucka
#3413
fordfairlane
veterán
Igazából ez egy elméleti téma, gyakorlatilag meglehetősen haszontalan, tehát ha nem muszáj, akkor nem kell foglalkozni vele, az egyszerű md5 vagy sha1 bőven megfelelő erre a célra.
Sok év tapasztalata odáig vezetett nálam, hogy a webes alkalmazásaimnál plaintextben tárolom a jelszavakat
, mert a felhasználók elfelejtik, és ha a támadó megszerzi az adatbázist, akkor annak a rendszernek már egyébként is régen lőttek, úgyhogy az a legkisebb gond. -
#3412
fordfairlane
veterán
Sk8erPeter
#3411
fordfairlane
veterán
válasz
Sk8erPeter
#3411
üzenetére
Ha már itt tartunk, van esetleg valami hiteles cikk, amit tudnál a témával kapcsolatban ajánlani?
Melyik témával kapcsolatban? Az MD5-ről elég annyit tudni, hogy egyirányú kódolás, 32 karakteren lehet tárolni, a többit a beépített md5 függvény elintézi. Persze ha valakit érdekelnek a részletek, az megtalálja az algoritmust is, fent van a Wikipédián.
-
#3407
fordfairlane
veterán
Sk8erPeter
#3396
fordfairlane
veterán
válasz
Sk8erPeter
#3396
üzenetére
"Az MD5 ellenőrző számok az angol ábc betűiből (26) és számokból (10) állnak. Ez ugye 32 felvehető érték, 32 karakternél (32 karakteresek az MD5 ellenőrző számok). Tehát összesen 3632 [kb. 1,46 * 1048] lehetséges MD5 ellenőrző szám van."
Ezt a baromságot... az MD5 egy 128 bites hash, akkor lesznek benne "angol betűk", ha hexadecimális formában írja le valaki, de ugye akkor sem az angol abc betűi, hanem csak 0-9 és a-f-ig. Ilyen pocsék leírásokat nem kéne linkelni.
-
#3320
fordfairlane
veterán
Sk8erPeter
#3317
fordfairlane
veterán
válasz
Sk8erPeter
#3317
üzenetére
Ez a része működik, átlátható, de F5-ös frissítésnél a legtöbb böngésző (Opera 9.64 pl. NEM) megkérdezi, ismét el szeretnénk-e küldeni a POST adatokat. És az elég gáz, ha még egyszer feltölti az adatbázist ugyanazokkal az adatokkal. Ezért is ajánlotta lezso6 a SESSION-ös trükköt. De az gond, hogy nem unsettelem sehol ezt a SESSION-be eltárolt értéket, pedig azt kéne, csak nem tudom, hol.
Nem biztos, hogy teljesen átlátom a dolgot, de ha jól értem, itt egy egyszerű képfeltöltésről van szó, járulékos adatokkal, és az bonyolítja meg a helyzetet, hogy előnézeti képet is akarsz a felhasználónak produkálni. Én ezt úgy szoktam megoldani, hogy feltöltésnél létrehozok egy átmeneti adatbázis rekordot, amit véglegesítek, ha minden jó, és a felhasználó is leokézza. Ha Mégsem-et nyom,akkor törlök mindent. Másik megoldás, hogy jóváhagyásig sessionben tárolod az adatokat. Ennek tkp. nincs sok köze ahhoz, hogy hogyan strukturálod a kódodat, ez technikai kérdés. POST után ha az adatokat feldogozod, csinálni kell egy átirányítást.
-
#3316
fordfairlane
veterán
Sk8erPeter
#3314
fordfairlane
veterán
válasz
Sk8erPeter
#3314
üzenetére
Nem tudom, érdemes-e az MVC elméleti részét boncolgatni első programnál. Mi a probléma a programoddal? Ha strukturálatalnul is működik jól, és kezelhetőek a hibák, módosítások, akkor fölösleges sokat agyalni magán a struktúrán. A struktúra szerkezete akkor kezd érdekessé válni, amikor enélkül már átláthatatlan az egész program.
-
#3306
fordfairlane
veterán
lezso6
#3304
fordfairlane
veterán
-
#3182
fordfairlane
veterán
sonar
#3174
fordfairlane
veterán
Különféle biztonsági okok miatt a szerver a kapott paramétereket manapság már nem globális változókba, hanem a $_GET, $_POST, $_REQUEST, $_COOKIE, $_FILES, $_SERVER ... egyéb asszociatív tömbökbe tárolja el, részletekbe nem akarok belemenni. Elég az hozzá, hogy a legtöbb webszerveren mára már ki van kapcsolva a register_globals, és a 6-os PHP-ból, a PHP következő verziójából teljesen ki fogják szedni. Már csak ezért is jobb meg sem szokni ezt a fajta programozási stílust.
-
#3171
fordfairlane
veterán
sonar
#3170
fordfairlane
veterán
Azért nem működik, mert rossz a kód. A form submitje után nem fogod megkapni $tipp változóban a "tipp" inputmező értékét, hanem jelen esetben a $_POST['tipp']-ben lesz benne. Kábé 4-5 éve már így szokás php kódban a formmezőket kezelni. Egyébként a formnak nincs submit gombja, ez meg van oldva?
-
#3169
fordfairlane
veterán
ReJim
#3167
fordfairlane
veterán
Én a mágikus url nevű függvényemet használom erre a célra.
<?
function url() {
$req = array();
$url = "";
if(func_num_args()) {
$arglist = func_get_args();
foreach($arglist as $arg) {
if(is_array($arg)) {
$req = array_merge($req,$arg);
}
}
if(is_array($req)) {
foreach($req as $key => $value) {
if($value) {
if(strlen($url)) $url .= "&"; else $url = "?";
$url .= $key."=".urlencode($value);
}
}
}
}
return $url;
}
?><a href="<?=url($_GET,array('beta' => 'víziló'))?>">link</a><?
?><a href="<?=url($_GET,array('beta' => 1))?>">link</a><?
?><a href="<?=url($_GET,array('beta' => ''))?>">link</a><?
?>N darab asszociatív tömböt fogad el paraméterként, összekombinálja őket balról jobbra, majd gyárt egy url stringet. Az alsó sorba írtam három példát, szerintem önmagáért beszél.
-
#3018
fordfairlane
veterán
tildy
#3013
fordfairlane
veterán
Ennyit találtam ki hirtelen:
$query = '
SELECT DISTINCT id,title FROM ((SELECT id,title,1 AS sorrend FROM cikkek WHERE title LIKE "%tes%")
UNION
(SELECT id,title,2 AS sorrend FROM cikkek WHERE keywords LIKE "%tes%")
UNION
(SELECT id,title,3 AS sorrend FROM cikkek WHERE lead LIKE "%tes%")
UNION
(SELECT id,title,4 AS sorrend FROM cikkek WHERE content LIKE "%tes%")
ORDER BY sorrend, id) AS result
'; -
#2933
fordfairlane
veterán
Gyomman
#2932
fordfairlane
veterán
válasz
Gyomman
#2932
üzenetére
Egyetlen oldal esetében a legegyszerűbben így:
<?
if($joajelszo) {
readfile('nagyontitkos.html');
}
?>Persze ez nem túl profi megoldás, hiszen ha valaki rájön a html fájl nevére, akkor hozzáférhet. Ez ellen annyit lehet tenni, hogy a webszerver root könyvtárán kívülre kel tenni az elrejtendő fájlt, így az közvetlenül nem lesz elérhető, csak ennek a php programnak a segítségével. Több oldal esetén érdemes valami profibb/bonyolultabb módszert használni, pl. session-t.
-
#2926
fordfairlane
veterán
eziskamu
#2923
fordfairlane
veterán
válasz
eziskamu
#2923
üzenetére
Ez az index.html-ben működőképes?
Így önmagában nem, csak ha <script></script> tagok közé rakod az általad bemásolt kódot, vagy .js fájlba, amire egy html oldal hivatkozik.
Van fent kettő is, mert két oldal van egy tárhelyen, az egyikben az oldalon megjelent szövegként, a másikon meg nem. A másikban aktív lehetett?
Bocs, ezt most nem értem.
-
#2921
fordfairlane
veterán
eziskamu
#2920
fordfairlane
veterán
válasz
eziskamu
#2920
üzenetére
Ez javascript genyóság, időm most nincs tesztelni, hogy pontosan mit is csinál, valamit a böngészővel kavar, talán átirányítja máshova. Ha egy html fájlban találtad az azt jelenti, hogy a támadó fájlokat tud írni a szerveren. Ez két módon lehetséges:
Név/Jelszót szerzett, és valami fájlátviteli protokollal (FTP, SCP, SFTP) képes felülírni a szerveren.
Van egy webes script, amiben van valamiféle bug, amit kihasználva fájlokat lehet felülírni.Érdemes kinyomozni, melyikről lehet szó, illetve jelszót változtatni nem árt.
-
#2915
fordfairlane
veterán
Balint133
#2914
fordfairlane
veterán
válasz
Balint133
#2914
üzenetére
Ha lehet, próbáld meg elkerülni a konvertálást. Ha az egész oldal ISO 8859-2-ben van, és az adatbázis is erre van beállítva, akkor használd azt, ha UTF-8, akkor inkább maradj annál. A böngészőknek nem jelent problémát az UTF-8 kezelése, és meg van az az előnye, hogy mindenféle idegen nyelvek karaktereit is jól kezeli.
-
#2912
fordfairlane
veterán
Balint133
#2911
fordfairlane
veterán
válasz
Balint133
#2911
üzenetére
Böngésző és szerverbeállítástól is függ, hogy alapból milyen kódlapot használ a böngésző a megjelenítéshez, ezért inkább érdemes megadni azzal a meta taggal. Egyébként az utf8_decode-t nem ajánlom, ha jól rémlik iso8859-1-re konvertál, és emiatt az "ő - ű" karaktereknél probléma lehet. Használj UTF-8-at.
-
#2827
fordfairlane
veterán
biker
#2826
-
#2580
fordfairlane
veterán
marcias
#2579
fordfairlane
veterán
válasz
marcias
#2579
üzenetére
Fogadni mernék, hogy a PHP beállítások változtak meg, és a register_globals opció lett kikapcsolva, de biztosat csak akkor tudnék mondani, ha látnám azt a minimális PHP kódrészt. Ha a PHP részen $oldal nevű változóban várod az "oldal" nevű paraméter tartalmát, akkor szinte 100%, hogy ez a gond. Ebben az esetben $oldal helyett $_GET["oldal"] néven kell használni, és működni fog.
-
#2566
fordfairlane
veterán
Drizzt
#2549
fordfairlane
veterán
A profi azt jelenti, hogy szakmai tapasztalata van, tehát nem egyszerűen megtanulta, beseggelte a manualt, hanem gyakorlati feladatokat oldott meg. Általában erre van szükség a cégeknél, problémákat kell megoldani, a módszer másodlagos. Az Objektum Orientált programozás egy módszer, vagy használod, vagy nem, de nem feltétlenül szükséges, azonban bonyolult rendszer esetén segíthet abban , hogy kezelhető maradjon a program. Igazából ez nem "web - nem web" kérdése.
-
#2516
fordfairlane
veterán
Bici
#2510
fordfairlane
veterán
(#2506) fordfairlane: Köszi, de még nem sikerült működésre bírnom.
Van egy olyan függvény, hogy headers_sent(), ami jelzi, ha már ki lett küldve a fejléc, és a további header() függvények, mint az átirányításos példád, már nem fognak működni.
if(headers_sent()) echo "Redirecthez tul keso, vilageges";
-
#2306
fordfairlane
veterán
emitter
#2305
fordfairlane
veterán
válasz
emitter
#2305
üzenetére
...a submit gomb neve konkrétan zavar,...
Ahogy írtam, ne adj neki name attribútumot:
<input type="submit" value="Keresés" />
Én nem szoktam eltüntetni, ebből tudom, hogy keresést kell indítani, mikor GET metódust használok. Az üres mezőket eltávolítani az első oldalról csak úgy lehet, ha csinálsz egy oldalt, ami átválogatja a paramétereket, kiszedi az üreseket, generál egy új kereső URL-t, és utána redirect a találati oldalra ezzel a szűrt URL-lel. Szerintem teljesen felesleges ezeket eltávolítani, fölöslegesen bonyolítja a programot.
-
#2304
fordfairlane
veterán
emitter
#2303
fordfairlane
veterán
válasz
emitter
#2303
üzenetére
Submitnál az url-t a böngésző generálja. Ha nem adsz name-t a submit gombnak, akkor talán nem fog benne szerepelni, de egyszerű eszközökkel, script-es hackelés nélkül nem tudod megoldani azt, hogy az üres mezőknek még a neve se szerepeljen benne. Miért akarod ezeket eltávolítani?
-
#2300
fordfairlane
veterán
fordfairlane
#2298
fordfairlane
veterán
válasz
fordfairlane
#2298
üzenetére
pages osztály:
/* class: pages
* oldalszámok osztály
* függőség: <url>
*/
class pages {
var $total;
var $params;
function pages($tot = 20) {
$this->total = $tot;
}
function get($first,$per,$max,$params="") {
if($per < $max) {
$this->params = $params;
$maxp = ceil($max/$per);
$actp = ceil($first/$per) + 1;
$fpage = $actp - floor(($this->total)/2);
if($fpage<1) $fpage = 1;
$topage = $fpage + $this->total;
if($topage>$maxp) $topage = $maxp;
if(($topage - $fpage) < $this->total) $fpage = $topage - $this->total;
if($fpage<1) $fpage = 1;
$str = '<table class="pages"><tr><td>';
// <<
$link = '<<';
if($fpage>1) {
$str .= $this->clink(0,$link);
}
else {
$str .= $link;
}
$str .= '</td>';
// <<
// <
$str .= '<td>';
$link = '<';
if($first>0) {
$f = $first - $per;
if($f < 0) $f = 0;
$str .= $this->clink($f,$link);
}
else {
$str .= $link;
}
$str .= '</td>';
// >
for($i=$fpage;$i<=$topage;$i++) {
$str .= '<td>';
if($i != $actp) {
$f = (($i-1)*$per);
$str .= $this->clink($f,$i);
}
else {
$str .= "<strong>".$i."</strong>";
}
$str .= '</td>';
}
// >
$link = '>';
$str .= '<td>';
if(($first + $per)<$max) {
$f = ($first + $per);
$str .= $this->clink($f,$link);
}
else {
$str .= $link;
}
$str .= '</td>';
// >
// >>
$link = '>>';
$str .= '<td>';
if($topage < $maxp) {
$f = (($maxp-1)*$per);
$str .= $this->clink($f,$link);
}
else {
$str .= $link;
}
$str .= '</td>';
// >>
$str .= '</tr></table>';
return $str;
}
}
function clink($first,$link) {
$str = '<a href="'.$_SERVER['SCRIPT_NAME'];
if(is_array($this->params)) {
$url = new url($this->params);
}
else {
$url = new url();
}
$url->set("f",$first);
$str .= $url->get();
$str .= '">'.$link.'</a>';
return $str;
}
} -
#2299
fordfairlane
veterán
fordfairlane
#2298
fordfairlane
veterán
válasz
fordfairlane
#2298
üzenetére
url osztály:
/* class: url
* url kreáló osztály
*/
class url {
var $params;
function url($url = "") {
if(is_array($url)) {
$this->params = $url;
}
else {
$this->params = array();
}
}
function set($p1,$p2 = "") {
if(is_array($p1)) {
foreach($p1 as $key => $value) {
$this->params[$key] = $value;
}
}
elseif(is_string($p1)) {
$this->params[$p1] = $p2;
}
}
function remove($p1) {
if(is_string($p1)) {
unset($this->params[$p1]);
}
}
function get() {
foreach($this->params as $key => $value) {
if(is_array($value)) {
foreach($value as $inkey => $invalue) {
if($url_uj) $url_uj .= "&"; else $url_uj = "?";
$url_uj .= urlencode($key."[".$inkey."]")."=".urlencode($invalue);
}
}
else {
if($url_uj) $url_uj .= "&"; else $url_uj = "?";
$url_uj .= $key."=".urlencode($value);
}
}
return $url_uj;
}
} -
#2298
fordfairlane
veterán
emitter
#2297
fordfairlane
veterán
válasz
emitter
#2297
üzenetére
Mivel ez nem triviális, és sok helyen volt szükségem erre, csináltam rá két osztályt, <url> és <pages>.
Így kell használni őket:
define(PERPAGE,20); // 20 elem egy oldalon
$f = (int)$_REQUEST['f']; // $f változóba kerül az aktuális oldal száma
/* Ebbe kerül bele az összes találatok száma, ebből tudjuk kiszámolni, hány oldal. Ide egy adatbázis lekérdezés jön általában. */
$sum = 200
/* Ha megadsz a konstruktornak egy számot, akkor max ennyi oldalszámot jelenít meg, hogy a lapozó ne legyen túl hosszú, ha esetleg többszáz oldal van. Alapból 20 az értéke */
$pages = new pages();
echo $pages->get($f,PERPAGE,$sum,$_GET);Az utolsó sornban a $_GET helyére $_REQUEST kerül a te esetedben, mivel hol GET, hol POST metódusban kapja az oldal a paramétereket.
-
#2294
fordfairlane
veterán
emitter
#2293
fordfairlane
veterán
válasz
emitter
#2293
üzenetére
Pár száz karakternyi adatot simán bele lehet passzírozni urlbe.
<?
$page = (int)$_GET['page'];
$url = $_SERVER['SCRIPT_NAME'].'?page='.$page;
foreach($_POST as $key => $value) {
$url .= '&'.$key.'='.urlencode($value);
}
echo $url;
?>Ha nagyon sok adat van, akkor meg session-ben célszerű eltárolni.
-
#2284
fordfairlane
veterán
Wizardmon
#2283
fordfairlane
veterán
válasz
Wizardmon
#2283
üzenetére
A $GLOBALS egész más. A környezeti változók a $_SERVER-ben vannak. Régebben a te általad leírt globális formában is elérhetőek voltak, sok más adattal egyetemben, de erről fokozatosan átálltak arra, hogy a különféle adatokat típusuktól függően különféle asszociatív tömbben tették elérhetővé, $_GET, $_POST, $_SESSION, $_SERVER, stb, stb....
-
#1983
fordfairlane
veterán
fordfairlane
veterán
// Eredményhalmaz felszabadítása
Eredményhalmaz, ez jó, még soha nem láttam így lefordítva. 8-)
-
#1939
fordfairlane
veterán
csimav
#1936
fordfairlane
veterán
Bedobtak a mélyvízbe, "itt a probléma, old meg" jelleggel. A neten rengeteg infó, tipp, tutorial, fórum van PHP-s témában, egész nap ezeket bújtam. Aztán később a fehér foltokat pótolni vettem egy könyvet is. Eltelt 8 év, és már elég tapasztalat összegyűlt. A PHP tipikusan olyan nyelv, hogy minimális programozási ismeretekkel és képességgel azonnal neki lehet fogni.
-
#1779
fordfairlane
veterán
drShaman
#1778
fordfairlane
veterán
-
#1776
fordfairlane
veterán
foosmaster
#1775
fordfairlane
veterán
válasz
foosmaster
#1775
üzenetére
while ( $sor = mysql_fetch_row( $beolvas ) ) {
echo $sor[2];
$osszeg += $sor[2];
}
echo $osszeg; -
#1746
fordfairlane
veterán
drShaman
#1745
-
#1268
fordfairlane
veterán
fordfairlane
veterán
A Kirowski 2008 év eleji felmérése a böngészőkről, operációs rendszerek részesedéséről:
-
#1257
fordfairlane
veterán
retes
#1256
fordfairlane
veterán
Ez egy komplett csomag, van benne webszerver is (Apache). Kezdőként ez a legegyszerűbb megoldás. Persze megvan a lehetőség, hogy külön telepítsd fel az IIS-t, és a PHP-t, de ahhoz ismerni kell jobban a konfigurálását. A PHP installere már sok konfigurációs dolgot meg tud oldani, de ha mégsm működik jól, akkor muszáj jobban elmélyedni a konfigurációs fájlokban.
-
#1212
fordfairlane
veterán
vakondka
#1210
fordfairlane
veterán
válasz
vakondka
#1210
üzenetére
Most olvasom a felhasználók kommentjeit, és vannak köztük érdekesek:
"Remember to slash underscores (_) and percent signs (%), too, if you're going use the LIKE operator on the variable or you'll get some unexpected results."
Úgy tűnik, hogyha nagyon precízek akarunk lenni, akkor saját escape függvényt kell csinálni, mert ez a példa csak a LIKE paraméterre vonatkozik.
-
#1211
fordfairlane
veterán
vakondka
#1210
fordfairlane
veterán
válasz
vakondka
#1210
üzenetére
Én nem szoktam ezeket a függvényeket használni. A mysql_real_escape_string leírása szerint backslash-t szúr a következő karaterek elé:
\x00, \n, \r, \, ', " és \x1aAz addslashes pedig a következők elé: \, ', ". Nem tudom, hogy szükség van-e a mysql_real_escape_string-re, ezen még nem gondolkodtam el, de lehetséges.
Ami a sprintf-et illeti, a haszna abban van, hogy típuskonverziót is kikényszerít, így egy numerikusnak várt érték, ami valami hiba vagy hack miatt nem numerikus, nem fog query hibát okozni. Én nem szoktam használni a sprinf-et, integernél általában a query-be beszúráskor explicit típuskonverziót adok meg, ha tudom, hogy csakis az adott típus lehet, pl. jelen esetben integert várok:
$query .= 'tipus='.(int)$p['tipus'];
Ez már inkább programozási stílus kérdése, hogy ki melyiket használja.
-
#1209
fordfairlane
veterán
vakondka
#1208
fordfairlane
veterán
válasz
vakondka
#1208
üzenetére
Bizonyára ez történt. A magic_quotes_gpc szerverenként változó, jellemzően a PHP 5-ben nincs bekapcsolva, így ide a bevitel során kell az addslashes, régebbieknél PHP 3 - 4 pedig általában be van kapcsolva, így ide fölösleges. Kiírásnál levő felesleges stripslashes (tehát addslashes bevitelnél, stripslashes kiírásnál, magic_quotes_gpc off) nem feltűnő, csak akkor okoz problémát, ha a szövegben szerepel backslash, például elérési út, ilyenkor eltűnik a backslash a tartalomból.
Ha portábilis kódra törekszem, akkor én így szoktam csinálni:
Mivel a form submit adatai nem feltétlenül kerül bele egyből az adattáblába, mert pl. nincs kitöltve egy kötelezően kitöltendő mező, ezért én úgy szoktam kezdeni, hogy a $_POST tömböt átmásolom egy másik tömbbe, és ha a magic_quotes_gpc be van kapcsolva, akkor kiszedem az általa beillesztett backslasheket.function n_slashes($p) {
foreach($p as $pkey => $pvalue) {
if(get_magic_quotes_gpc()) $post[$pkey] = stripslashes($p[$pkey]);
else $post[$pkey] = $p[$pkey];
}
return $post;
}
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$p = n_slashes($_POST);
...
}Form submit esetén meghívom ezt a függvényt, azután eldöntöm, hogy beleírom-e az adattáblába vagy sem. Ha beleírom, mert minden adat megfelelő, akkor minden mezőre egyenként addslashes-t alkalmazok, ha nem, akkor kirakom újra a formot, és visszaírom a bevitt adatokat. Ez a módszer mindenféle beállítással működik.
-
#1205
fordfairlane
veterán
vakondka
#1204
fordfairlane
veterán
válasz
vakondka
#1204
üzenetére
Nem értem, de mindegy, nem feszegetem a témát. Én úgy látom, hogy teljesen felesleges addslashest használni, mert látszik, hogy backslashek kerülnek az adatbázisban elmenetett stringekbe, amit persze kiíráskor ki kell szedni. De akkor már egyszerűbb bele sem rakni. Szerintem egyszerű a helyzet, a magic_quotes_gpc be van kapcsolva, az addslashes pedig megduplázza a backslasheket, ezt korrigálja a stripslash. Vizuális editor ide vagy oda.
-
#1203
fordfairlane
veterán
vakondka
#1200
fordfairlane
veterán
válasz
vakondka
#1200
üzenetére
Nem értem, miért kell használni a stripslashest kiíráskor? Az adatbázisba bevitelkor, mivel idézőjelek közt adsz meg stringértékeket, amik idézőjeleket is tartalmazhatnak, ezért a stringváltozók tartalmát escape-lni kell a backslash karakterrel.
Két eset van: Vagy a PHP megcsinálja automatikusan, ha a magic_quotes_gpc opció be van kapcsolva, ebben az esetben semmit nem kell csinálni beíráskor, vagy pedig, ha kikapcsolva van, akkor kell az addslashest használni. Kiíráskor már sehol nem lesz felesleges backslash karakter, azt kapod, amit submittal elküdtél a szervernek, amit beírt az adatbázisba.
"
Új hozzászólás Aktív témák
- HP Pavilion Plus 14-ey0155ng Ryzen 5-7540 / 16GB / 512GB FHD+
- Szuper áron eladó 2az1-ben HP Pavilion x360 /14" i5-1335U, 16GB ram, 512 GB SSD, FHD, IPS,
- Lenovo IdeaPad Slim 5 16IAH8 16 col 12.gen i5 / 16GB / 1TB új 1 napot ment eddig összesen.
- Acer Aspire 5 A517-58GM-78AT i7 / 32GB RAM / 1TB SSD / RTX 2050 17,3
- Remek áron eladó dobozos új ACER NITRO V15 /R7-7735HS/16GB 1000 GB SSD NVIDIA RTX 4060 8 GB 144Hz
- Apple Watch Ultra GPS + Cellular 49mm, Újszerű, 1 Év Garanciával
- BESZÁMÍTÁS! ASUS ROG STRIX SCAR 15 Gamer notebook - i9 12900H 16GB DDR5 1TB SSD RTX 3070Ti 8GB WIN11
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Microsoft Windows, Office & Vírusirtók: Akciók, Azonnali Szállítás, Garantált Minőség, Garancia!
- Samsung Galaxy S22+ 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest