- Bemutatkozott a Moto G32 4G
- Nothing Phone 2a - semmi nem drága
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Poco X6 Pro - ötös alá
- Véroxigénszintet is mér a Honor Band 5
- Vodafone-ra áttért Digi Mobilosok
- Google szolgáltatás (GMS) Huawei telefonokra
- Alcor e-Pad - van még remény
- Ennyibe kerülnek a Huawei Pura modellek Európában
- Telekom mobilszolgáltatások
Hirdetés
-
Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
it Az AI-t kiszolgáló adatközpontok olyan nagy energiaigénnyel bírnak, hogy egyre több atomenergiára van szükség.
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
-
Mozgásban az F1 24
gp A Forma 1 versenyek rajongói hamarosan végre belevethetik magukat az idei epizódba.
Új hozzászólás Aktív témák
-
RedHarlow
aktív tag
Sziasztok,
Tudnátok segíteni, hogy az alábbi db connect funkció, hogy néz ki helyesen oracle db esetén?
class DB {
public static $mysqli;
public static function Connect() {
DB::$mysqli = new mysqli(DB_HOST, DB_USERNAME, DB_PASSWORD, DB_DATABASE);
DB::$mysqli->set_charset("utf8");
DB::$mysqli->query("SET NAMES 'utf8'");
}
}
DB::Connect();
Az én átiratomban az alábbi hibákat kaptam:
class DB {
public static $oci;
public static function Connect() {
DB::$oci = oci_connect(DB_USERNAME, DB_PASSWORD, DB_DATABASE);
DB::$oci->set_charset("utf8");
DB::$oci->query("SET NAMES 'utf8'");
}
}
DB::Connect();
PHP Fatal error: Uncaught Error: Call to a member function set_charset() on resource in
PHP Fatal error: Uncaught Error: Call to a member function query() on resource in[ Szerkesztve ]
-
wis
tag
-
Taci
addikt
Adott egy hosszú XML fájl, abból egy részlet a következő:
<description><![CDATA[<p>Az eddig főként a rakétagyártásban jeleskedő Rocket Lab feladata az lesz, hogy két űreszközt is létrehozzon.</p> <p>The post <a href="https://ng.24.hu/tudomany/2021/06/17/maganvallalat-epithet-mars-szondakat-a-nasa-nak/" target="_blank">Magánvállalat építhet Mars-szondákat a NASA-nak</a> first appeared on <a href="https://ng.24.hu/" target="_blank">National Geographic</a>.</p>]]></description>
Magát a description-t így egyben szépen ki tudom szedni:
$description = $node->getElementsByTagName('description')->item(0)->nodeValue;
Viszont így jelenleg ezt tartalmazza ennél a példánál:
Az eddig főként a rakétagyártásban jeleskedő Rocket Lab feladata az lesz, hogy két űreszközt is létrehozzon.
The post Magánvállalat építhet Mars-szondákat a NASA-nak first appeared on National Geographic.
(Csak linkekkel, de azt most kiszedtem.)Nekem csak az első p-tagek közti rész kellene (Az eddig főként... létrehozzon.), az utána következő részek már nem.
Ezt hogyan tudom kiszedni, ugyanígy "szépen" (nem sztringekkel vágdosva)?
Tudnátok ebben segíteni?getElementsByTagName('p')
kellene valahogy valahova, csak nagyon nem találom, pedig biztosan egyszerű.Köszönöm.
-
sztanozs
veterán
Amennyiben megbízható a forrás, akkor gyártanék egy be nem mappelt DOM elemet és az innerHTML-be beleraknám a CDATA tartalmát. Onnantól már lehet rajta alkalmazni ezeket a DOM függvényeket.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz sztanozs #20655 üzenetére
De fura, teljesen meg voltam győződve róla, hogy egy sima getElementsByTagName lesz, nem gondoltam, hogy ez ennyire "lehetetlen" feladat php-ben, "szépen".
A forrás sajnos nem "megbízható", bármikor változtathatnak, ezért is szerettem volna a sztringek vágásánál egy "szebb" módot, mert ha ott változtatnak valami radikálisat (vagy akár kicsit is, de "rossz helyen"), akkor hibára futhat a kód.
De akkor maradok ennél. Köszönöm.
Neked is a választ, Mike. -
sztanozs
veterán
A megbízhatót úgy értem hogy ha lesz benne egy szkript tag akkor az szépen lefut amint bekerül az innerhtmlbe. Szóval ha biztonságilag megbízható…
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz nevemfel #20659 üzenetére
Ezt most amúgy én sem értem.
Ez működik, csak benne van pár p-tag a kinyert sztringben ($description):
$description = $node->getElementsByTagName('description')->item(0)->nodeValue;
Ezért akartam volna úgy, hogy "tovább bővítem" ezt a kódot, hogy az első p-tagek közti sztring részletet adja vissza, pl. így:
$description = $node->getElementsByTagName('description')->item(0)->nodeValue->getElementsByTagName('p')[0];
De ezt nem tudtam megoldani, mert csak vakon próbálkoztam, hogy hogyan kellene/lehetne folytatni.
Sztringvágással már megcsináltam, csak reméltem, lehet egyszerűbben/szebben is.
-
veterán
Sziasztok!
Laravelben igencsak kezdo vagyok, igy nezzetek el nekem ha marhasagot kerdezek/irok.
Projektemet Laravel 8/Jetstream/Laratrust komboval fejlesztem, es az RBAC megvalositasa kozben akadtam meg:A CreateNewUser.php-t igy modositottam:
$user = User::create([
'username' => $input['username'],
'email' => $input['email'],
'password' => Hash::make($input['password']),
]);
$user->attachRole('visitor');
return $user;
Lathato, hogy a jogot hozzaadja. Regisztracio utan a beepitett email kuldo automatizmussal egy megerosito emailt kuldok. Amikor rakattintok az emailben levo linkre, akkor a /dashboard-ra kerulok.
Aztan itt, a Profile-ban meg kell adnom tovabbi adataimat (migration-be raktam oket).
A UpdateUserProfileInformation vonatkozo sorai:
if ($input['email'] !== $user->email &&
$user instanceof MustVerifyEmail) {
$this->updateVerifiedUser($user, $input);
} else {
if ($user->first_login === false) {
$user->forceFill([
'first_login' => true,
])->save();
}
es$user->forceFill([
'firstname' => $input['firstname'],
'middlename' => $input['middlename'],
'lastname' => $input['lastname'],
'username' => $input['username'],
'email' => $input['email'],
'landlinetel' => $input['landlinetel'],
'mobiletel' => $input['mobiletel'],
'mandatory_fields_filled' => true,
])->save();
Auth::logout();
Session::flush();
redirect(route('login'));
Elmeletileg (ill. a dokumentacio alapjan is ugy tunik, hogy ezt igy illik csinalni errefele, illetve SO-n, meg egyeb forumokon is ezt talaltam: Az auth logout kijelentkeztet, utana eldobom/lezarom a session-t, hogy ne lehessen vele visszaelni, majd atiranyitok.
LoginResponse.php:
public function toResponse($request)
{
$user = auth()->user();
if ($user->mandatory_fields_filled && $user->hasRole('admin')) {
$home = '/admin';
return redirect()->intended($home);
} elseif ($user->mandatory_fields_filled && $user->hasRole('user')) {
$home = '/user';
return redirect()->intended($home);
} elseif ($user->hasRole('visitor')) {
if ($user->mandatory_fields_filled) {
$user->detachRole('visitor');
$user->attachRole('user');
}
$home = '/dashboard';
return redirect()->intended($home);
} else {
$home = '/';
return redirect()->intended($home);
}
}
Ha atirom a user_role-ban bejelentkezes elott a felhasznalohoz tartozo jogot (mondjuk visitorrol userre) akkor a bejelentkezesnel a /userre redirectel (ami 404, mivel meg nincs kesz), am ha nyomok egy visszat a bongeszoben, akkor a korabban bejelentkezett user sessionjebe dob vissza. Van Laravelnel erre valami szep megoldas, amivel normalisan meg lehet csinalni a bejelentkezeskori hitelesitest?
Eletem elso Laravel-es tanulo projektje ez, ugyhogy kerlek ne lojetek.
Koszi!
Udv.
[ Szerkesztve ]
-
laracroft
aktív tag
Sziasztok
POST-al kapok egy textmező tartalmat, melyben van pár darab \r\n.
E-mail-ben szeretném tovább küldeni tartalmát, de nem tudom lecserélni őket -mondjuk <br>-re.
Általam talált leírások ezeket a megoldást ajánlják, de nem jön össze, ugyanúgy benne marad:
preg_replace( "/\r|\n/", "", $text);
$text = str_replace("\n", "", $text);Nem tudok rájönni mit rontok el segítsetek légyszíves
köszi -
Exian
őstag
Sziasztok!
Egyik ismerősöm csinált az anyukájának egy egyszerű kis bemutatkozó weboldalt a vállalkozásának tevékenségéről. PHP+SQL+JS hármas a weboldal.
Felajánlottam nekik, hogy hosztolom a saját szerveremről (Linux).
Felraktam a weboldalt, meg az SQL adatbázis is el lett készítve, minden rendben is van, ám a probléma az, hogy Chrome böngésző alatt ugyan bejön az oldal, de egy kis idő múlva (pár perc) már nem tudja megnyitni és EZEN A KÉPEN LÁTHATÓ hibaüzenetet dob. A weboldal címét kiszedtem a képről, nem lényeges, illetve ilyen formán még nem is publikus.
De pl. Edge és Firefox böngészők alatt nincs ez a jelenség, ott folyamatosan megjelenik az oldal hibátlanul, minden része úgy működik, ahogy kell.
Van valakinek tippje, hogy mi a bánat miatt hülyül meg a Chrome egy idő után és miért dobja ezt az üzenetet?
Persze tök jó, mert a szerveren semmiféle hibaüzenet nincs a weboldalhoz tartozó error logban, tehát onnan nem tudok kiindulni.
Ha átrakom a szerveren egy másik aldomainre, akkor megint egy pár percig jó, aztán ugyanazon a címen egyszer csak a linkelt hibaüzenet jön.
Hátha valaki találkozott már ilyennel és van tippje.
A szerveremen fut még vagy 10-15 másik PHP alapú weboldal és semelyikkel sincs semmilyen hiba, ilyen meg aztán főleg nincs.
Sokkal egyértelműbb lenne a dolog, ha rögtön ezt dobná és be sem jönne az oldal, de nem, először bejön és minden okésnak tűnik, csak pár perc után dobja be és onnantól többet nem nyitható meg.
Köszönöm!
[ Szerkesztve ]
-
Exian
őstag
válasz pelyib #20665 üzenetére
Köszi!
Hát nem nagyon látok semmit, hiba nincs, egy warning van: crbug/1173575, non-JS module files deprecated.
SZERK.: mondjuk ahogy gyors utána olvastam, valakinek pont ugyanezt az ERR_CONNECTION_REFUSED hibaüzenetet dobta ugyanezzel a warninggal.
Amúgy egy pillanatra az Edge-ben is bejött egy "A lap nem jeleníthető meg" oldal, ott pont DNS problémát írt, de csak egy pillanatig volt az oldal, aztán ment tovább jól az oldal és Edge/Firefox alatt továbbra is megy jó, de Chrome-mal nem.
Nem tudok rájönni. Mondjuk egy olyan valaki csinálta, aki most végzett valamilyen tanfolyamot, tehát kezdő, de a PHP részét segített neki valaki összerakni. Én szintén nem vagyok perfekt PHP-ban, úgyhogy neki sem állok átnézni, felesleges, max. a nagyon szembetűnő hibákat veszem észre. De ez, hogy csak egy böngészőt érint és nincs semmi hibaüzenet szerveroldalról, így nagyon nehéz...
Az általam csinált weboldalak, meg amiket nem én csináltam, de az én szerveremen futnak, minden tökéletesen megy évek óta, szóval nem szerveroldali a hiba, ráadásul felraktam egy másik, otthoni szerveremre is, a helyzet azon is ugyan az, Chrome nem tudja megnyitni. De csak az.
[ Szerkesztve ]
-
Ez a kép, amit kaptál, a Chrome böngésző sajátja, nem is fogod megtalálni a forráskódban. Én arra tudnék gondolni, hogy kompatibilissé tettés Edge és FireFox böngészőkkel, de Chrome-ra nem. Ez okozhat talán ilyet. Ha van esetleg lehetőséged, nézd meg Safari-n mit mutat.
But who is watching the guardians?
-
Mike
veterán
volt már valakinek dolga iCalendar bejegyzésekkel? Lehet valahonann tudni, hogy ki jelez vissza, hogy eljön? Eddig olyat találtam, hogy a google calender apija meg tudja mondani, de ahhoz kell a google fióktól engedély.
-
disy68
aktív tag
az iCalendar tartalmazhat participation infót amennyiben a kiállítója ezt belegenerálja
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
Exian
őstag
Nem hiszem. Ez biztos, hogy csak az adott weboldalnál jelentkezik, minden más weboldal a szerveremen problémamentesen megy és nincs ez a jelenség. Kliensoldalról meg szintén nincs gond, próbáltam több gépről, több hálózatból, mobilnettel, stb, mindenhonnan érzékelhető a gond.
Most annyi változás van, hogy most már ilyen hibát ír a Chrome:
"ERR_TUNNEL_CONNECTION_FAILED"
De Edge alól továbbra is hibátlanul megjelenik.
-
Taci
addikt
Sziasztok!
Az
sqlsrv_query
és abind_param
használata "kizárja egymást"?Eredetileg így néz ki egy lekérdezésem előkészítése (példa):
$sql = "INSERT INTO " . $table . " (id, name, date) VALUES (?,?,?)";
$stmt = $conn->prepare($sql);
$stmt->bind_param("iss", $id, $name, $date);
De most, ahogy olvasgatom, hogy kell megvédeni egy PHP-alapú weboldalt, és rátaláltam az SQL Injection Attacks-re, tippnek a
sqlsrv_query
használatát látom.És ha jól látom, ez alapján a fenti példával ez így nézne ki:
$sql = "INSERT INTO " . $table . " (id, name, date) VALUES (?,?,?)";
$params = array($id, $name, $date);
$stmt = sqlsrv_query( $conn, $sql, $params);
- A bind_param az ugye akkor kell, ha gyakori a lekérdezés, mert így hatékonyabb. De akkor ezek szerint ezzel is kijátszható a kód (SQL Injection Attack)?
- Ha pedig átváltok az ajánlott sqlsrv_query-re, akkor bár védve leszek az injection-támadások ellen, de bukom a bind_param (prepared statement) általi hatékonyságot?Vagy hogy van ez? Lehet/kell ezeket "mixelni"? Vagy elég csak az egyik, hogy mindkét előnyt (hatékonyság + védelem) megtarthassam?
Köszi!
Amúgy próbáltam az itt említett példán keresztül "megtámadni" az adatbázis, de sehogy sem fogadta el a Drop Table kódrészt (saját adatbázisra szabva, persze). Szóval nem tudom kipróbálni, melyik a jó megoldás.
[ Szerkesztve ]
-
Taci
addikt
válasz sztanozs #20676 üzenetére
Tehát ha a user hiába ad meg a linkelt példában lévő kártékonynak szánt inputot a $name változóhoz (a linkelt példában ez volt email címhez: bswan@microsoft.com'; DROP TABLE CustomerTable; PRINT 'Gotcha!'--), mindkét verzióval "védve vagyok"?
Ha igen, miért? (Ha 1-2 mondatban, vagy akár csak 1 magyarázó linkkel el tudnád mondani. - közben lentebb azt hiszem, meg is találtam rá a választ)
Ha jól értem, azért "kellene" az sqlsrv_query, mert:
When you execute this query using parameterized values and the same user input , only the INSERT query is executed.Viszont a Prepared Statement-tel (bind_param) is paraméterezek. Ezért lenne az a fajta verzió is "védett"?
Úgy látom, ez lehet az oka, igen ( [link] ):
A prepared statement is a parameterized and reusable SQL query which forces the developer to write the SQL command and the user-provided data separately. The SQL command is executed safely, preventing SQL Injection vulnerabilities.Köszönöm!
-
disy68
aktív tag
"Ha igen, miért?"
mert ugyanaz a kettő csak más drivert használnak más DB-hez és más a syntaxsqlsrv_query ugyanaz, mint a prepare + bind + execute csak egy lépésben és az SQLSRV Driver-t használja
magyarul, ha MSSQL a DB, akkor használd az sqlsrv_query függvényt
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
Mike
veterán
tudomásom szerint a PDO véd az sql injection ellen. a php korábbi verziójában lévő mysql_query csak egy utasítást hajt végre, hiába, írkálsz bele pontosvesszőket. ezen felül a felhasználó inputjait szűrheted kulcsszavakra, de még egyszerűbb ha az összes inputot még az sql utasításba kerülése előtt base64-gyel kódolod. akkor kb azt ír be amit akar.
-
Taci
addikt
mysqli_real_escape_string
Characters encoded are NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.
Ezzel kiegészítve a user inputokra akkor jobb lenne?Csak mert ahogy nézem, a base64_encode-ot utána dekódolni is kell, és így gondolom, a lényege ugyanaz lenne, csak "bonyolítva" (ha nem, javíts ki, kérlek):
$str = 'This is an encoded string';
echo base64_encode($str);The above example will output:
VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw== -
disy68
aktív tag
"de még egyszerűbb ha az összes inputot még az sql utasításba kerülése előtt base64-gyel kódolod. akkor kb azt ír be amit akar"
nem egyszerűbb és értelme sincs, hacsak nem az a cél, hogy magaddal tolj ki
nem a PDO véd az sql injection ellen, hanem a prepared statement/parameterized query (amit persze a PDO is támogat), ami escape-eli a paramétereket és nem mellesleg a db motor ezeket előkészíti (execution plan), eltárolja és utána az adott paraméterekkel futtatja, ezáltal későbbi futáskor már csak előkapja és az új paraméterekkel futtatja (ezáltal gyorsítva a query futását)
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
disy68
aktív tag
"különösebben nem tolok ki magammal"
szóval minden egyes db műveletnél encode/decode? indexek, kereshetőség, performancia?
"a prepared statement/parameterized query minek a része? PDO? az 5-ös msq_query-ben volt ilyen? nem"
a prepared statement/parameterized query az adatbázis motor által támogatott mechanizmus, amit egyrészt kell támogatnia az adott nyelvhez/környezethez írt drivernek és az azt használó implementációnak
amennyiben elérhető, érdemes azt használni és nem kézzel mókolni (ez lett volna a mondandóm lényege)
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
nevemfel
senior tag
Használj paraméterezhető queryket, kész passz. A query stringbe csak placeholderek kerülnek, az értékeket külön adod át, akár sqlsrv_query-t használsz, akár sqlsrv_prepare-t és sqlsrv_execute-ot, akár PDO::prepare + (opcionális bind_) + execute-ot, vagy a mysqli hasonló metódusait.
Mindenféle mágikus escape-t használni amiatt, hogy az sql injectiont elkerüld: fundamentális hiba.
[ Szerkesztve ]
Forget your troubles, c'mon get happy
-
nevemfel
senior tag
Egyébként _minden_ query paramétert parametrizálni kell, vagy ha nincs más lehetőség (pl. az említett példádban a táblanévnél nem tudom, működik-e a dolog), akkor az adott driver escape/quote metódusával kell escapelni a változó értékét. Saját konfig változó is tartalmazhat olyan értéket, amit escapelni kell (', ", \, * satöbbi).
[ Szerkesztve ]
Forget your troubles, c'mon get happy
-
sztanozs
veterán
Mondjuk megnézem, hogy egy base64-encode-olt sztringben kogy keresel LIKE kulccsal...
Tablescan 4 president...
Amúgy nem értem ezt a JSON parát, simán lehet JSON mezőben még tagra is keresni, ráadásul még index is építhető rá (ha tudod, hogy pontosan mi alapján akarsz később keresni)...[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
Tök felesleges B64-elni, ha egyszer egy paraméterezett query-ben úgysem lehet injektálni. Más ellen (pl XSS) meg nem véd. Csak szivatod magad és égeted az erőforrásokat (+125% tárhely, +CPU igény).
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
nevemfel
senior tag
mint írtam, paraméteres query előtt is volt élet
Persze, hogy volt élet, tele óriási security hole-okkal. Nem véletlen az, hogy az sql injection a toplista élén van a biztonsági hibák listáján. Másrészt a prepared stmt max. a PHP-ban új. Mármint amennyiben a PHP 5.0 - 5.1 újnak számít.
[ Szerkesztve ]
Forget your troubles, c'mon get happy
-
nevemfel
senior tag
jaja, de azért még bőven vannak a neten akár 4-es php-val működő oldalak
Bizonyára, nem tudom, mennyi lehet az arányuk. Mindenesetre ha valaki saját, új kódot ír, (és nekem úgy tűnik, erről van szó) jobb nem követni ezeket a mintákat.
Forget your troubles, c'mon get happy
Új hozzászólás Aktív témák
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- World of Tanks - MMO
- Otthoni hálózat és internet megosztás
- Ukrajnai háború
- Stellar Blade
- AMD off topik: VGA, CPU, APU és minden, ami AMD
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Így építsd a billentyűzeted!
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen