- gban: Ingyen kellene, de tegnapra
- Kempingezés és sátrazás
- Gurulunk, WAZE?!
- Magga: PLEX: multimédia az egész lakásban
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Parci: Milyen mosógépet vegyek?
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
Új hozzászólás Aktív témák
-
coco2
őstag
Már semmiért sem. Elgondolkodtam rajta, merre megy a világ megy ezekkel a laravel meg hasonló framework-ökkel. Hátha tudnak valamit. De beleástam magam, és azt találtam, nem tudnak semmit. Üres a varázsló bácsi cilindere. Csak az illúzió van. Valakiknek jó lehet ügyfelet, vagy főnököt, vagy akárkit hitegetni, de ha objektíve egy feladatot akarok stabilan megoldani saját magamnak, akkor az a sok hóbelebanc konkrétan semmire kell. Szóval mindenki másnak jó szórakozást hozzá. Én eleresztettem.
-
Atos23
senior tag
Halihó!
Elég hülye voltam mindig is a webprogramozáshoz, és ez így is marad, de sajnos egy öregeknek szóló villamosmérnöki levelező képzésen kitalálták, hogy weblapot kell készítenünk.
Reggel óta próbálom megoldani ezt az elméletileg tök egyszerű feladatrészt a komplett weblapomhoz, de sajnos nem megy, pedig a stackoverflowt már rongyosra olvastam.A feladat ezen részében egy php oldalon be kellene kérnem néhány text adatot, majd ezzel machinálnom MySQL-ben.
Sikerült is megoldanom, egészen addig tök jól működik, amíg egy darab adattal variálok, pl. az elsődleges kulcs alapján ki akarom törölni az egész rekordot.HTML:
<form name="form" action="" method="POST">
<input type='number' name="torlesid" id="torlesid" value="">
</form>PHP:
$torlesid = $_POST['torlesid'];
$sql = "DELETE FROM lista WHERE id = '$torlesid'";A feladat későbbi részében már több text adatot kellene bekérnem, és ezekkel az adatokkal feltölteni a rekordot. Na itt azt gondoltam, hogy okés, akkor legyen több input, és több változó, és már készen is vagyunk. Na ekkor dőlt össze minden, mert kizárólag az első változó működik, a többi már nem.
Hogyan tudom megoldani, hogy több HTML textboxból csináljak változókat, és azokat beadjam az SQL parancsnak? Stackoverflown csak olyan példát láttam, ahol egy textbox adatait adjuk át.Ez a nem működő próbálkozásom:
HTML:
<form name="form" action="" method="POST">
<input type="text" name="adid" id="adid" value="id">
</form><form name="form" action="" method="POST">
<input type='text' name="adhelyszin" id="adhelyszin" value="Helyszin">
</form><form name="form" action="" method="POST">
<input type='text' name="adfajta" id="adfajta" value="Fajta">
</form>PHP:
$adid = $_POST['adid'];
$adhelyszin = $_POST['adhelyszin'];
$adfafajta = $_POST['adfajta'];$sql = "INSERT INTO lista (id, helyszin, fajta) VALUES ('$adid', '$adhelyszin', '$adfajta'); ";
Előre is köszi minden ötletet, hogy mit ronthatok el a változók átadása terén!
-
Taci
addikt
Köszönöm a tanácsot és a segítő szándékot, de sztanozs "unszolására" (jó értelemben véve persze
) átnéztem újra, és meglett, hogy az SQL-es Update miatt volt lassú, amúgy nagyon gyors a logikai/ellenörzős rész.
A lassúság oka az volt, hogy egyesével futtattam rekordonként az Update-et... - de most már átírtam arra, hogy csak egyszer a végén, az összeset bind_param-mal átadva, egy lépésben futassa, és így már repül.
(Érdekes volt így kilogoltatni, hogy hogyan is néz ki egy darab, 23e rekord adataiból összerakott lekérdezés. )Köszönöm azért így is a tanácsot!
-
Taci
addikt
UTF-8-ban van minden, és direkt úgy csináltam meg, hogy amit nem abban kapok, először azt is átalakítom azzá. Amúgy azóta minden más linknél jól működik (normálisan adták meg, normál ékezetekkel -amiben épp van-, szóval az egy egyszeri "valaminek" tűnik csak), plusz módosítottam is a függvényen:
1. FILTER_VALIDATE_URL-rel teszt. Ha false, akkor
2. a header-ös ellenőrzéses teszt (200 OK). Ha ezen is megbukna, akkor kuka.Plusz így átgondolva ha még 3. lépésnek bevonnám az ékezetes betűk ellenőrzését, (hogy ha az van benne, akkor jóhiszeműen átengedem, mert biztos csak amiatt nem volt jó az első 2 teszt), akkor igazából ha a link annyi lenne csak, hogy "é", azt is átengedné.
Szóval jó ez így, nem is ér további energiaráfordítást.
Köszi azért, hogy írtál.
-
#20746
Prog-Szerv
csendes tag
Mike
#20739
Prog-Szerv
csendes tag
"az adatbázisban engedd hogy null lehessen a mező"
Igen ezzel kezdtem. Le is teszteltem, ha beinsertelek valamit akkor null az érték.
"SET
mezo = :ertek
akkor megeszi a php nullt is"
Igen, csak ezt nem tudom, hogy pontosan hogyan csináljam...mindenképpen meg akarom tartani a jelenlegi dinamikáját a dolognak. -
lanszelot
addikt
Elérni mind a kettő eléri, csak más könyvtárban vannak.
De egyik se root -ban van.
Root-ba tenni se tudom, és nem is akarom.
Ez az egész project egy könyvtárban van.
Azon belül is vannak könyvtárak /pl a zoom/
login.php a project alap könyvtárában van, ott van a css is
login.php -ban így hivatkozok rá:<link rel="stylesheet" href="login.css">mivel mellette van
zoom.php a loginra így hivatkozik:require __DIR__ . '/../login.php';
mivel az egy könyvtárral beljebb vanDe a require sem működik, ha csak beírom a zoom.php-t nem kéri a jelszót, beenged.
Ha kiveszem a könyvtárból, és a login.php mellé rakomrequire __DIR__ . '/login.php';így viszont jól működik
Tehát valami a elérési linkkel lesz rossz. De mi?project/login.php
project/login.css
project/zoom/zoom.php -
#20737
Prog-Szerv
csendes tag
Mike
#20736
Prog-Szerv
csendes tag
Igen, ez majdnem jó, csak ebben az esetben nem NULL szerepel az adatbázis táblájában miután lefut az update hanem üres mező (empty) Majdnem jó, de az lenne a legjobb ha adatbázis szerinti NULL értékem lenne. Abban az esetben ha nem sorolom fel a mezőt, pl unset-tel kiszedem akkor is ugyan ez a helyzet...
Erről már olvastam korábban hogy a PHP null és az SQL NULL nem ugyan az, és hogy a php null-t az SQL emptynek veszi. Úgy tudom az SQL NULL-t így lehetne neki megadni pl: SET valami=NULL <-aposztrófok nélkül, viszont a kód dinamikussága miatt abban az esetben ha valós adatom van kell az aposztróf....ezt leszámítva ez a dinamikus kód eddig nagyon jól bevált. -
Taci
addikt
Mármint hogy ne legyen paraméterezés? Vagy nem értem. Pont a paraméterezés lenne a lényeg, mert így ha valahogy az egyik érték helyére bejuttatnak egy kártékony kódrészletet, akkor bajban leszek. (a pár hozzászólással ezelőtt tárgyalt SQL injection-támadhatóság)
Azt látom itt problémának, hogy ugye mivel dinamikusan változik a változók száma, nem tudom ráhúzni a sémát, és simán beírni, hogy
$stmt = $mysqli->prepare("... WHERE id NOT IN (?,?,?)");$stmt->bind_param('iii', 0,1,2);(vagy változókkal, most mindegy, csak példa)És így ha valamelyik érték helyett bekerül egy "rossz kód", akkor általa támadva lehetek.
Ugye erre lenne védelem a paraméterezés, csak mivel változó, hogy mennyi elem van ennél a résznél átadva, nem tudom, hogyan lehet paraméterezni. -
Mike
veterán
na megvan a select is
if($node->tagName == 'select') {$options = $node->getElementsByTagName('option');foreach($options as $tag) {$tag->removeAttribute('selected');$tag_value = $tag->getAttribute('value');if($tag_value == $be[$name])$tag->setAttribute('selected', true);}}elnézést ha valakinek ebben semmilyen új információtartalom nem volt, de hátha lesz olyan akinek meg jól jön
-
-
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.
-
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)... -
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)
-
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)
-
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== -
Exian
addikt
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
Beleraktam hibakezelést, ahogy írtad:
if (curl_errno($ch)) {$error_msg = curl_error($ch);echo "ERROR: " . $error_msg;}
Így viszont minden linknél ezt írja ki:ERROR: <url> malformedDe passz, hogy miért, minden url rendben van - legalábbis 100%, hogy ha van is hibás közte, nem mind az.
Ja, és amúgy meg gond nélkül dolgozik a linkek tartalmával.
Szóval így nem sokat ér ez a hibajelzés. -
Taci
addikt
Köszönöm, találtam sok cikket, fórumbejegyzést róla, amint a szolgáltatónál leszek, ki is próbálom, hogyan lesz a legjobb.
Azflockparamétereit is megtaláltam (néhol "-n", máshol "-w 1" volt, nem volt tiszta, de így már értem):
[link]ha kézzel indítod írhatna más logba is, hivd paraméterrel
Ezt hogy érted? A kézzel indítást úgy értem, hogy magát a cron job-ot kézzel triggerelem.De így már nem piszkálom szerintem, a tesztfázisra így már rendben van, nem fog duplikálni.
Ésflock-kal pedig ez a (korábban megírt) ellenörzős rész pedig nem fog már kelleni.Köszi a tippet.
-
Taci
addikt
Ezt találtam, de "csak" stackoverflow-ról így hirtelen:
"Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions."Amúgy nekem gond nélkül kiírja amit eddig kellett, a 300-as határt csak azért húztam, mert utána egyszerűen már túl sok, rengeteg helyet elfoglal a szöveg.
Illetve ezt találtam még:
VARCHAR(65535)
However, note that the limit is lower if you use a multi-byte character set:
VARCHAR(21844) CHARACTER SET utf8For CHARSET=utf8mb4 use VARCHAR(16383)
-
Taci
addikt
Köszönöm, már át is írtam, és valóban volt különbség.
VARCHAR(300)-ra van beállítva az egyik mező, és az egyik bejegyzésnél a korábbi "sima" strlen-es módszerrel szólt, hogy túl hosszú (~330), ezért levágta a túlcsorduló részt.
Azonban most megnéztem a forrássztringet, és valójában csak 298 karakter hosszú.
Átírtam a kódot mb_strlen-re, és így már nem bántotta, egyben volt kijelezve, hisz' elfért.Köszönöm.
-
Taci
addikt
ha UTF-8-at használsz akkor a multibyte extension legyen a php-ra felrakva, és strlen helyett mb_strlen-t kell használnii
SQL mezőben a
VARCHAR(255)-ben a 255 ugye karakterszámot jelöl? Ezek szerint ha azt akarom vizsgálni, hogy egy beadott sztring ne lehessen hosszabb ennél, akkor eddig rosszul használtam?if (strlen($title) > 254){$title = substr_replace($title, "[...]",249);}Mert akkor ezek szerint az strlen a karakterek által elfoglalt byte-okat számolja, míg az mb_strlen magát a karakterek számát?
Tehát akkor ezek szerint nekem így kellene használnom:
if (mb_strlen($title) > 254){$title = substr_replace($title, "[...]",249);}Köszi.
-
Taci
addikt
SQL topikba tartozna így, off-ba is raktam, de annyira rossz a szemnek, hogy alig tudtam visszaolvasni, úgyhogy inkább kiszedtem off-ból.
Ez egyelőre csak egy lokál desktop server, és ami "vele együtt jött":
Kiszolgáló típusa: MariaDB
Kiszolgáló verziója: 10.1.37-MariaDB
A kiszolgáló karakterkódolása: UTF-8 Unicode (utf8)Hozzáadva a lekérdezéshez a collate-részt, phpMyAdmin konzolon belül a várt eredményeket adja.
COLLATE utf8mb4_binViszont amikor az oldalon keresztül hívom meg (már ha jól használom egyáltalán), akkor hibára fut.
Ezt hívom meg:
SELECT * FROM table1WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))UNION ALLSELECT * FROM table2WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))UNION ALLSELECT * FROM table3WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))ORDER BY time DESCLIMIT 4Ránézésre találtok esetleg valami hibát?
Megnéztem egy online SQL code checker-ben, azt írta, rendben van, csak nem optimalizált.Köszi.
-
sztanozs
veterán
Nincs ezzel mit csinálni - nézd csak meg a hivatalos oldalt...
Note: To combat unwanted pop-ups, some browsers don't display prompts created in beforeunload event handlers unless the page has been interacted with. Moreover, some don't display them at all.
...
Note also, that various browsers ignore the result of the event and do not ask the user for confirmation at all. In such cases, the document will always be unloaded automatically. Firefox has a switch named dom.disable_beforeunload in about:config to enable this behavior. As of Chrome 60, the confirmation will be skipped if the user has not performed a gesture in the frame or page since it was loaded. Pressing F5 in the page seems to count as user interaction, whereas mouse-clicking the refresh arrow or pressing F5 with Chrome DevTools focused does not count as user interaction (as of Chrome 81). -
Bzozoo
tag
"user ha sikeresen belépett kap egy sessionben tárolt user azonosítót, amit minden egyes adathiváskor ellenőrzöl, enélkül nem küldesz adatokat"
Igen, természetesen ezt értem. Session_id nélkül nincs semmilyen adatkiszolgálás, ez teljesen tiszta sor. Talán tényleg jobb is, ha a front a többit nem tudja, csak lekéri, bár egy user tokent még mellékelek majd a PHPSESSION mellé, ami ugyanúgy fog viselkedni, mint a PHP session, egyfajta dupla védelem lesz. Adatot csak ennek a kettőnek a birtokában lesz lehetséges.
Készítettem egy új frontend mintakódot és ehhez némileg módosított backendet, egy beléptető rendszert, ami csak a PHP session id-jét kapja meg és ebből dolgozik. A teszt kedvéért nem használ adatbázist és mindenkit beenged jelszó nélkül is, a lényege, amúgy is a sessionban való tárolás és az abból való adatvisszanyerés prezentálása.
-
don_peter
senior tag
"Az Önt kiszolgáló szerveren az éjszaka folyamán elvégeztük a kötelező mysql 5.6-ról 5.7-re való váltást, mivel a mysql 5.6 támogatása megszünt a cPanel hivatalosan minimum az 5.7-es verziót támogatja már csak."
Ezt a választ kaptam, hogy volt e valami kavarás a szervereken. -
don_peter
senior tag
Ezen a képen a régi állapot látható, és sajnos nem jól listáz, nem veszi figyelembe a bejegyzések dátumát. Pár nappal a frissítés előtt még jól listázott.
Ez pedig a módosított állapot, amikor már jól listáz.
Itt a szubselect-be egy plusz csoportosítást kellett elhelyeznem, így helyre állt a régi és jó listázási állapot.
Kérdés az, hogy lehet e ezt jobban és szebben megoldani? -
#20243
instantwater
addikt
Mike
#20242
-
#20198
instantwater
addikt
Mike
#20190
-
Azért lenne jobb "máshogy" megoldani. De végső soron az ismerős marad, igen.
Reggel óta próbálom megoldani ezt az elméletileg tök egyszerű feladatrészt a komplett weblapomhoz, de sajnos nem megy, pedig a stackoverflowt már rongyosra olvastam.
Erről már olvastam korábban hogy a PHP null és az SQL NULL nem ugyan az, és hogy a php null-t az SQL emptynek veszi. Úgy tudom az SQL NULL-t így lehetne neki megadni pl: SET valami=NULL <-aposztrófok nélkül, viszont a kód dinamikussága miatt abban az esetben ha valós adatom van kell az aposztróf....ezt leszámítva ez a dinamikus kód eddig nagyon jól bevált.
Új hozzászólás Aktív témák
Hirdetés
- AKCIÓ! VALVE INDEX virtuális valóság szemüveg garanciával hibátlan működéssel
- HP Rack szerverek és tartozékok egyben vagy külön-külön
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- DELL Universal Dock D6000 docking station (452-BCYH) (DisplayLink)
- Bomba ár! Fujitsu LifeBook U757 - i3-7GEN I 16GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest