- [K2]: A vagyonvédelmi rendszerszerelővé válás rögös útja
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Lalikiraly: Astra kalandok @Harmadik rész
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sh4d0w: Árnyékos sarok
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- Mr Dini: Mindent a StreamSharkról!
Új hozzászólás Aktív témák
-
-
Taci
addikt
Tegnap este (vagy ma hajnalban, már nem emlékszem, összefolynak az órák) a PHP egyszer csak "elfelejtett magyarul", nem kezeli az ékezetes betűket.
Korábban tökéletesen működött, de mostanra megkergült. Adatbázisba is rosszul (csúnyán, ékezetek nélkül) ír be, és a logot is teljesen elrontja.
Nem változtattam semmit a kódnak ezen a részén. Ami pl. eddig fixen bele volt égetve a kódba, hogy írja a logba azt, hogyKiválasztott elem, az mostKiválasztott elem.
Kategória --> KategĂłria
kép --> kĂ©pPHP version 7.3.1
A gyakorló teszt szerveren ez van. Lehet ez a régebbi verzió az oka? Bár nem tudom, akkor eddig miért működött, és most miért nem.
Óraátállítás? Más nem jut eszembe.Hátha nektek van ötletetek.
Köszi. -
coco2
őstag
Valami tapasztalt tanácsnak örülnék session timerek beállítására.
A szerver a session létrehozásakor felvés egy időkorlátot session változóba. Folyamatosan ellenőrzi a session használatakor. Legkésőbb 1 nap múlva a session garantáltan lesz kinyírva. De az az 1 nap egy végső korlát, amit nem kellene elérni. Extra cookie-kat / local storage időpont felvésést nem szívesen használnék. Jó lenne egyedül session cookie-val oldani meg.
Van kettő timer php.ini-ben. Az egyik a szerver oldali session storage timere (session.gc_maxlifetime), a másik a cookie file timere (session.cookie_lifetime), ami kliens oldalra kerül.
A cél az lenne, hogy a felhasználónak naponta legalább egyszer újra kelljen loginolnia. Alkalmasint ha naponta 2-3 újra loginol, az még nem nagy gáz. Sokkal többször ne kelljen neki olyat tennie.
Van valakinek ilyen esetre kitapasztalt megszokása, hány órára érdemes állítani azokat a timereket?
-
coco2
őstag
Phpmyadmin topic évtizednél régebbi. Inkább írom ide. Php myadmin hibába futottam. Ezt kapom képernyőre:
Notice in ./libraries/classes/Display/Results.php#4468Trying to access array offset on value of type nullBacktrace./libraries/classes/Display/Results.php#4175: PhpMyAdmin\Display\Results->_getSortedColumnMessage(,string '`autoid`',)./libraries/classes/Sql.php#1759: PhpMyAdmin\Display\Results->getTable(,array,array,boolean true,)./libraries/classes/Sql.php#1533: PhpMyAdmin\Sql->getHtmlForSqlQueryResultsTable(<class:phpmyadmin\display\results>,string './themes/pmahomme/img/',NULL,array,boolean false,integer 0,integer 0,boolean true,,array,boolean true,)./libraries/classes/Sql.php#2260: PhpMyAdmin\Sql->getQueryResponseForNoResultsReturned(array,string 'kittenstars',string 'user_input',NULL,integer 0,<class:phpmyadmin\display\results>,NULL,string './themes/pmahomme/img/',NULL,,string 'SELECT * FROM `user_input` ORDER BY `autoid` ASC ',NULL,)./libraries/classes/Sql.php#2137: PhpMyAdmin\Sql->executeQueryAndGetQueryResponse(array,boolean true,string 'kittenstars',string 'user_input',NULL,NULL,NULL,NULL,NULL,NULL,string '',string './themes/pmahomme/img/',NULL,NULL,NULL,string 'SELECT * FROM `user_input` ORDER BY `autoid` ASC ',NULL,NULL,)./sql.php#220: PhpMyAdmin\Sql->executeQueryAndSendQueryResponse(array,boolean true,string 'kittenstars',string 'user_input',NULL,NULL,NULL,NULL,NULL,NULL,string '',string './themes/pmahomme/img/',NULL,NULL,NULL,string 'SELECT * FROM `user_input`',NULL,NULL,)</class:phpmyadmin\display\results></class:phpmyadmin\display\results>Database server:
Server: Localhost via UNIX socketServer type: MySQLServer version: 8.0.23-0ubuntu0.20.04.1 - (Ubuntu)Protocol version: 10Web server:
Apache/2.4.41 (Ubuntu)Database client version: libmysql - mysqlnd 7.4.3phpMyAdmin:
Version information: 4.9.5deb2Az a user_input egy memória tábla. Furcsa, hogy éppen arra miért panaszkodik, a többire meg miért nem. Szaladt bele valaki hasonlóba? Tisztán a phpmyadmin a gagyi, vagy tényleg sáros a mysql is valamivel?
-
"A php a szerver oldali szkript, ami legyártja neked stringben a html oldalt, és azt küldi le kliens oldalra."
Akkor én valamit rosszul csinálok mert JSON resource-kat küldök vissza a kliensnek ami egy JavaScriptben kérszül SPA alkalmazás.
Köszi, ezt nem tudtam a 10+ év PHP-s tapasztalatommal..."Bármit is tölt be az a frame, azt te írtad elő neki, miközben pakoltad össze a dokumentumot."
Számomra nem triviális a frame jelentése. Szerintem itt a kolléga iframe-re gondolt. Erős a gyanúm, és első blikkre disy68 is ezt feltételezte, majd teljesen jogosan javasolta, hogy ha valóban iframe akkor ne használja."Vagy beleírtad közvetlenül, vagy javascript formájában, esetleg forrás címet írtál bele, ahonnét kérdezősködjön, vagy bármi."
OK.
"Szóval ha php-d van és arra vagy kíváncsi, mit művelt a kliens oldal, esetleg nézd meg, hogy mire utasítottad."
Ez egy általánosan nem igaz kijelentés. -
coco2
őstag
A php a szerver oldali szkript, ami legyártja neked stringben a html oldalt, és azt küldi le kliens oldalra. Amit a böngészőben látsz megjelenítve, az egy hosszú bla-bla szöveg html-ként értelmezve. Bármit is tölt be az a frame, azt te írtad elő neki, miközben pakoltad össze a dokumentumot. Vagy beleírtad közvetlenül, vagy javascript formájában, esetleg forrás címet írtál bele, ahonnét kérdezősködjön, vagy bármi.
Szóval ha php-d van és arra vagy kíváncsi, mit művelt a kliens oldal, esetleg nézd meg, hogy mire utasítottad.
-
sztanozs
veterán
Ja, elnéztem az entity-t, ez kell neked: [link]
$str = preg_replace_callback('/\\\\u([0-9a-fA-F]{4})/', function ($match) {
return mb_convert_encoding(pack('H*', $match[1]), 'UTF-8', 'UCS-2BE');
}, $str);vagy
$str = preg_replace_callback('/\\\\u([0-9a-fA-F]{4})/', function ($match) {
return mb_convert_encoding(pack('H*', $match[1]), 'UTF-8', 'UTF-16BE');
}, $str); -
coco2
őstag
válasz
sztanozs
#20483
üzenetére
Bekoppantottam az általad idézett kódpéldát és kicseréltem az $input stringet a #20476-ban megadott-ra. Ezt dobta ki:
&fields=privacy\u00252Cname\u00252Clink&limit=1
ehelyett:&fields=privacy%2Cname%2Clink&limit=1A kódpélda nem működik. Próbáld ki, és meglátod. Azért van rá szükség.
-
coco2
őstag
Eddig a legegyszerűbb, amit találtam:
iconv("UTF-16", "UTF-8", hex2bin("0025"))->%
Ez legalább támogatott mód utf16 átalakítására, ami nem gányolás. De ehhez szét kell nyiszogálnom a bemeneti stringet darabokra, és cserélgetnem benne.Működni éppen működik, de ha tud valaki egyszerűbb megoldást bemenetet (#20476) egy lépésben dolgozni fel, segítség lenne tisztább kódot gyártani. Kicsit furcsa, hogy a php 7-8 henceg mindenfélével, és akkor egy mezei utf16 kódolás már kifog rajta?
-
coco2
őstag
Összetalálkoztam ilyesmi url részlettel:
&fields=privacy\u00252Cname\u00252Clink&limit=1Hosszú url pici darabja. Azok ott utf 16 karakterek benne. Kellene ilyesmi végeredmény:
&fields=privacy%2Cname%2Clink&limit=1Például ez az oldal csinál hasonlót.
Van rá valami egyszerűbb mód php-ban mint bináris alapon byte-onként játszadozni vele?
-
Bocs, de kiforratlannak találod a Guzzle-t és még debuggert sem használsz. Ez nálam ellentmondás. Nem akarok flamelni - és be is fejezem a témát de ezzel az állítással pont magad szivatod meg.
Nem kell mindent leimplementálni ha van jó megoldás. A guzzle nem fog megszűnni, ugyanis szerves résza a Laravel keretrendszernek is ami a mai minőségi PHP fejlesztés egyik esszenciája.
De csak hogy más szemszögből is lásd a dolgot: ha most Guzzle-val nekiállnál dolgozni és valamilyen csoda folytán megszűnnek akkor az általad használt keretrendszer segítségével kihúzol egy új service-t, leimplementálod az új logikát amit kivezetsz egy v2-es API-ra és idővel kivezeted. A jó lib kiválasztása fontos, és a te esetedben a Guzzle jó mert:
- könnyen használható
- számodra minden fontos információt tartalmaz
- telepítést sem igényelÉn javaslom neked a használatát.
Xdebug telepítése (os ismeretének hiányában nem tudok segíteni), pedig pl. VSCode esetén egy PHP Debugger kiegészítőre van szükséged és PHP verzió függvényében egy plugin engedélyezésre. PHPStorm esetén ha jól tudom csak engedélyezni kell a debugot.
A logolással óvatosan, mert hatalmas log fájlok generálására képes (több 10 akár 100 giga).
-
pelyib
tag
http://xdebug.org Telepiteshez, beallitashoz van egy halom leiras (kb extension telepitese, minimal config, editor konfiguralas)
lépésenkénti végrehajtás
Ezt nem tudom, sose kellett. Tobbit tudja amit soroltal.php cli debugger (grafikus)
PHPStorm adja, legtobb editorhoz van pluginje. -
coco2
őstag
Általában nem használok debuggereket, de most nagyon hasznos segítség lenne időben.
Win10-es gépre kellene valami handy php cli debugger (grafikus). Google feldobál párat, egyiket sem ismerem, útmutató jó lenne.
Alap szolgáltatások elégségesek, de legalább azok kellenének hibamentesen (ha valamelyik debugger rigolyás is pár dologra, legalább ne az alap dolgok legyenek hibásak). A forrás halom sok file-t húz be helyben, sok darabban van, tudnia kell mappában megtalálnia őket. A forrás hajt végre https letöltést netről és dolgozik helyben lévő mysql db-ből / db-be. Kell lépésenkénti végrehajtás, végrehajtás töréspontig, regisztrált változók listája, és értékek kijelzése. Néhány tömbben több mélységű struktúra van, örülnék normális gui-nak áttekinthető kijelzéssel.
Melyiket nézzem a debuggerek közül?
-
-
pelyib
tag
Ha 10 év múlva még mindig létezik a project, majd akkor megnézem.
Ha jol ertem, akkor nalad csak a 20 eves projectek a megbizhatoak, ertem.
Meg gondolom az a ~250millio letoltes valoban azt jelzi, h ez egy kiforratlan valami.Nem verremeno vitat akarok inditani. Ertem sot! reszben osztom is a velemenyed, h nem minden v0.0.1 libre feltetlen kell epiteni, de a Guzzle nagyon nem ebbe a kategoria esik.
-
coco2
őstag
válasz
pelyib
#20467
üzenetére
A linkelt oldalon nem másabb a példa, mint amit használok. 5.x php alatt még minden okés, 7.x alatt ugyan az a kód ugyan arra a feladatra nem működik. Az az ssl tiltás security hole, abból nem kérek. Php ini változók rendben. Azt a mini kódot behajítottam a szerveren php-ba, a kimenete rendben (sor tördeltem):
openssl: yeshttp wrapper: yeshttps wrapper: yeswrappers: array (0 => 'https', 1 => 'ftps', 2 => 'compress.zlib', 3 => 'php',4 => 'file', 5 => 'glob', 6 => 'data', 7 => 'http', 8 => 'ftp',9 => 'compress.bzip2', 10 => 'phar', 11 => 'zip', )Kicsit kotorásztam a curl körül, egyenlőre nem tűnik problémamentes kerülőútnak. Szóval most gyűröm a file_get_contents hibakeresését meg a curl doksikat is.
Ha véletlenül tud valaki valahol egy nagyon tutin összeszedett migrációs doksit php 5->7 file_get_contents() problémákkal, örülnék annak is.
A curl-el kapcsolatos problémám lásd fentebb.
A guzzle-t a magam részéről nem soroltam a megbízhatóan kiforrott libek közé. Az ilyen projectek miatt az ifjú-titán-flame szokott lenni, aztán egyik pillanatról a másikra elhagyatottá válik, és kukás lesz minden, amit arra építettek, és jelen esetben túl sokat kellene rá építenem. Nem kérek ilyesmiből, bocsi. Ha 10 év múlva még mindig létezik a project, majd akkor megnézem.
-
coco2
őstag
válasz
SUPREME7
#20466
üzenetére
Nem találtam lehetőséget ezekre:
-Bináris file letöltés változóba. Csak filesystem-en keresztüli példákat találtam. Nem tudom azokat használni. Változóba kell a bináris tartalom.
-Teljes header visszaadása string / array formában. Nekem a header-ben csomagolt változók jönnek vissza. Azokra szükségem van.
-
SUPREME7
őstag
Alapvetően semmi extra nem kell neki, PHPnet sample kód elég, ha szimpla GET:
<?php
// create curl resource
$ch = curl_init();
// set url
curl_setopt($ch, CURLOPT_URL, "example.com");
//return the transfer as a string
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// $output contains the output string
$output = curl_exec($ch);
// close curl resource to free up system resources
curl_close($ch);
?>Ha esetleg kell részletes infó akkor:
$info = curl_getinfo($ch); -
coco2
őstag
Utána kotortam kicsit a curl-nek. Temérdek sok beállítás, amikről nem találom a default értékeket. Ha mindet állítgatom, kilométer hosszú lesz
Példák amiket találok egyik sem jelenkori php verzió.Le kellene szedni https lapot (domain, oldal, halom sok paraméter) + header-t. Ha valaki tud rá jó példa blogot, url-nek örülnék.
Köszönöm
-
coco2
őstag
válasz
supercow
#20463
üzenetére
Ellenőriztem. Be van kapcsolva. Php 7.4 és default On. A kódrészletet wamp3 alatt teszteltem, onnét copy / paste át 7.4 alá. 5-ös alatt nem volt baja. Ellenőriztem az url-t, amit a 7.4 script megkap. Bekoppantottam böngészőbe. Normál lefutott.
Valami beállítási nyavaja lesz a háttérben. Utána kotrok a curl-nek, hátha kevesebbet kell vele erőlködni.
-
coco2
őstag
file_get_contents()-hez hogyan szokás részletes hiba információt beszerezni?
Kódrészlet:
$t_opt= array( "http"=>array("method"=>"GET") );$t_context= stream_context_create($t_opt);$http_result= file_get_contents($t_url, false, $t_context);$http_header_save= $http_response_header;var_dump($http_response_header);Kimenete:
NULLA fenti kódrészlet egy framework aljában van. Http get hívást készítek elő, ráhívok az url-re, és tapasztalom a problémát. Elvileg vissza kellene adjon header-t is. Ha mást nem 200/ok-ot. De null van ott. Jó lenne valahonnét részletes hibakódot vadászni, hogy kutakodhassak, mi történt. Hogyan szokás azt csinálni?
Előre is köszönöm.
-
coco2
őstag
GET paraméter átvételen töröm a buksit. Van egy ilyesmi formázott behívásom (széttagoltam space-ekkel, hogy átláthatóbb legyen):
http://enyem.hu/lap.php ? param1=alma & param2=citrom # _=_Azzal az anchor izével a legvégén tudok valamit kezdeni? Érzékelni tudom azt valahol / valahogy?
-
Sziasztok!
A weboldalamra csináltam még annak idején egy rövid PHP programot, ami egy számláló. Lényegében rejtett, csak számomra ad tájékoztatást, lényege, hogy minden betöltésnél egyel növel egy értéket (egyébként programozási segédletnek készült).
Namost, ez a számláló egy txt fájlba dolgozik, mindig behívja, egyel növeli az értéket és bezárja. Az elérési út eddig úgy volt megadva, hogy pl az oldal szerkezet ilyen,
.aloldal (mappa)
.aloldal aloldala (mappa)
tartalom.php
index.php
egyéb.php
style.css
hakell.js
counter.txtakkor ha tartalom.php-ben van a kód, úgy
../../counter.txt.Így működik is. Viszont, ha úgy akarom elérni, hogy
https://weboldal.hu/counter.txt, akkor csak egyszer frissül, a továbbiakban pedig nem. Ennek mi lehet az oka? -
-
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). -
Mike
veterán
belefutottam az onbeforunload problémába
a jelenség az, hogy az onbeforunload működése teljesen esetlegestöbb scriptet is kipróbáltam, végül meglepő módon a MDN-n lévő tűnik úgy, hogy működik, uyganakkor a felugró ablak csak akkor jelenik meg egészen biztosan ha a vizsgáló ki van nyitva
var ua = navigator.userAgent;window.addEventListener('beforeunload', function (e) {$.post( "log.php", { p:ua }).done(function(valasz) {console.log(valasz);});e.preventDefault();e.returnValue = '';});
igaz ez nem php, de gondolom más is futott már bele ebbeigazából az a kérdés, hogy talált-e már valaki erre normális megoldást -
Ez hibátlan a feladatra.
-
-
nevemfel
senior tag
válasz
Bzozoo
#20431
üzenetére
Tokennek nem sok értelmét látom. Ha valaki lehallgatja a kliens-szerver kommunikációt, és így megszerzi a session azonosítót, akkor a tokent is ugyanúgy le tudja menteni, és fel tudja használni. Erre a fajta man in middle hekkelésre a hálózati végpontok közti kommunikáció titkosítása a megoldás, jelen esetben a https protokoll.
-
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.
-
Mike
veterán
válasz
Bzozoo
#20429
üzenetére
akkor azt vedd figyelembe, hogy minden kommunikáció kényelmesen, akár böngésző vizsgálójával olvasható, másrészt mindenféle backend kiszolgálás vmilyen authentikálással történik, és tök mindegy hogy az session vagy token. a kérésekre nem adsz ki bármit. ugyanis a frontend hívásait bárki le tudja szimulálni. a szervert ez nem terheli.
a böngésző nem olvassa be a session tartalmát, ő nem fér hozzá, csak egy session azonosítót hozza létre, amit fenntart ameddig a böngészőt be nem zárod (alapesetben). a tartalmához csak szerver oldalon lehet hozzáférni, pl a PHP tudja olvasni, és véletlenül sem adja oda senkinek mert magának dugdossa.
azt is értsd meg, hogy a PHP nem standalone, vagyis az egyes PHP k nem tudnak egymásról
tehát 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. a user azonosítót nem küldöd el még véletlenül sem, azt a front nem is tudja, a session azonosítót a böngésző elküldi automatikusan, és te a backenden megnézed van e ebben sessionben olyan user azonosító, amit elfogadsz, és aszerint szolgálod ki.
pl a belepes.php létrehoz egy userid-t amit a sessionben tárol (a sessiont a böngésző hozza létre) és amikor jön a statisztika.php hoz egy kérés, akkor az megnézi van e sessionben userid, van e joga statisztikai adatokhoz, annak melyik köréhez, stb
tehát, igen, legtöbbször ez bizony adatbázis művelettel jár, de ez milisec, általános esetben ezt bírja a szerver -
Bzozoo
tag
Arra jöttem rá, hogy session esetén az történik, hogyha megnyitok egy PHP oldalt (természetesen session_start()-os oldalt), akkor a frontenden tárolt session cookie alapján a PHP kiolvassa a szerveren letárolt az ID-hez társított session fájlból az értékeket, legalább is azokat, amiket igénylek a $_SESSION[key]-el.
Amire pedig a te hozzászólásod alapján jöttem rá, illetve értettem meg, hogy ez a kiolvasási folyamat nem feltétlenül a frontenden a domainhez kapcsolódó cookie alapján történhet, hanem egy $_POST metódusban be tudok neki "POST-olni" egy adott session_id-t és akkor abból fog dolgozni, a session_start után.
Ezeket az session_id-ket sima mezei cookie-ben is le tudom tárolni a frontenden, így a sessionhoz sem kell nyúlni mindig, illetve a PHP-t sem kell zaklatni minden egyes lekérésnél, ezzel a szerver terhelése csökken, valamilyen szinten a biztonság is, ezt gondolom. Sőt a frontenden létezik sessionStorage is. Ide is le tudom tárolni a PHP session_id-t.
Tehát ha a felhasználó validálása alatt azt értjük, hogy a felhasználó által bármilyen módon visszaküldött session_id alapján kiolvassuk a szerveren tárolt és a session_id-hez társított session fájlt, akkor igen. Nagyjából körvonalazódott hogy mi is történik a háttérben -
Bzozoo
tag
"a backend legyen ami a frontot kiszolgálja és ne a front tárolja az adatokat"
Nekem az is fontos, hogyha az azonosítás megtörtént, akkor felesleges minden egyes lapbetöltés esetén újra validálni és újra lekérni az adatokat. Persze biztos vagyok benne, hogy állandó validálás mellett biztonságosabb a rendszer, viszont a szerverrel való kommunikációt is szeretném minimalizálni.
#20425 Mike
"a session id a serveren van, a php fér csak hozzá, nem kell utaztatni a front és a back között
amelyik php filet session_starttal kezded az hozzáfér a sessionhöz és az abban tárolt adatokhoz, tehát a postba már nem kell beletenni"Már rájöttem hogy a session a php-ben van, de a böngésző egy session cookie-val olvassa be az aktuális session tartalmát a phpből. Én nem php fájlon szeretném megkapni az adatokat és nem is a szerveren, hanem egy php mentes frontenden, ami akár a localhoston vagy másik domainen van. Ehhez viszont elkerülhetetlen a session_id utaztatása és adott esetbe $_POST-ban történő visszaküldése, legalábbis ebben a rendszerben.
"session_id("most_éppen_itt_repül_a_kismadár_a_session_id");
session_start();"
"Küldhet viszont session id-t post vagy get üzenet formájában (én a post-ot szeretem)"Ohhhh. Ez az amit kerestem . Végre leesett
Sikerült is alkotnom egy kis frontendet, amivel lehet generálni sessiont, azt lementi magának a kis sütijébe és ha kell neki valami a sessionból, akkor csak $_POST-ban vissza küldi a backendnek a session_id-t és az erre JSON választ ad az $_POST-ban küldött session_id szerint.
A backend forráskód fájlok itt érhetők el:
Ez ami generál egy sessiont és ez, ami megnyitja a postban küldött sessiont.
Frontend forráskód -
coco2
őstag
válasz
Bzozoo
#20423
üzenetére
Ha jól értem, a session kezelése az, ami nem tiszta. Az egyik probléma tipikusan az szokott lenni kezdőkkel, hogy csak annyit látnak "php", és nem azt, hogy ott egy apache szerver, annak van konfigja (port, virtual szerver, defaul root file), aztán a php az apache alá van telepítve, annak is van egy konfigja (csomó beállítás session-re), és az egy nagy csomó mechanizmus, ami mind végig zajlik, még mielőtt az index.php scripted elindulna.
Vélhetőleg nem a megfelelő blogokat olvasod a kérdésben, linkelek olvasnivalót én:
https://www.php.net/manual/en/session.configuration.phpAzon az oldalon nagy halom php.ini változót találsz a default értékeikkel, aztán egyesével a hatásaik leírásai. Végig kellene olvasni. Mókás kérdésekre találhatod ott meg a választ.
"Ez az amire nem jöttem rá még hogy kell."
session_id("most_éppen_itt_repül_a_kismadár_a_session_id");
session_start();Ha azt beírod, fixen mindig az "most_éppen_itt_repül_a_kismadár_a_session_id" session fog futni. Ha csak ennyit írsz be:
session_start();
Akkor a függvény leírásánál leírt események fognak történni: https://www.php.net/manual/en/function.session-start.php
Ha bármi mást olvastál, lehetségesen nem a legjobb minőségű blogokat találtad. A php.net-et kellene olvasgatni a hozzászólásokkal együtt. Temérdek sok példát is találsz ott a függvények használatára.
"De jobb lenne tényleg csak egy sessionID-t átadni frontendre, a többit az elindított sessionból visszahozni, ez megy is abban az esetben, ha egy domainen van a front és a backend."
A session_id() függvény pont arra van, hogy bármilyen domain-ról rá tudj indítani a kérdéses session-re. A kliens oldali xhr például nem küld session cookie-t. Küldhet viszont session id-t post vagy get üzenet formájában (én a post-ot szeretem).
-
-
Mike
veterán
válasz
Bzozoo
#20423
üzenetére
mert abban mi a necces?
a backend legyen ami a frontot kiszolgálja és ne a front tárolja az adatokat, arra ott a backend
a php nem angular, minden egyes php használatkor validálni kell a felhasználót erre meg a session tökéletes, ezt nem a front kezelia különböző apk-kat mind lehet egy backenden kezelni, de erre inkább tokent használj. akár belépésenként újat akár kommunikációnként
ha nem ismered még, nézd meg a Postmant is
-
Bzozoo
tag
"az átdobott session id-t elindítsd az xhr kiszolgálóban."
Ez az amire nem jöttem rá még hogy kell. Olvasgattam PHP.net-en minden ezzel kapcsolatosan, de nem vitt előrébb, persze elolvasom mégegyszer.
Amikor a felhasználó elküldi a login.php-nek a jelszavát, akkor szépen lekér mindent fontos adatot a PHP-től, amiből sütiket tudok csinálni a kliens oldalon. Na most akkor gondolom a sütiben eltárolt session ID-t POST-ban kéne visszaküldenem és ezt session_start() - al megnyitnom?"Kipakolni mindent nem éppen biztonságtechnikai bravúr"
Most csak tesztként jelenik meg minden a dashboardon, hogy látható legyen minden, amit sikerült lekérni a szerver től.
Olyan alkalmazásokhoz akarom használni ezt, amik külön domainen futnak vagy apk-ba csomagolt mobilalkalmazások, tehát függetlenek a PHP backendtől, ezért vagyok kénytelen átadni userId-t, UserSecret-et, UserToken-t, UserName-t és a PHP sessionID-t frontendnek.
De jobb lenne tényleg csak egy sessionID-t átadni frontendre, a többit az elindított sessionból visszahozni, ez megy is abban az esetben, ha egy domainen van a front és a backend.Az md5 password tárolást is meg fogom változtatni, mert tudom, hogy az is necces a kódban.
-
coco2
őstag
válasz
Bzozoo
#20420
üzenetére
"Más domainen nem érvényes a session cookie"
Igen mert az olyat cross site request forgery-nek hívják, és hálózati támadásként van számon tartva. Nem mintha xhr-en keresztül bármi megtiltaná neked, hogy az átdobott session id-t elindítsd az xhr kiszolgálóban. Php.net-en kukucs session_id() és session_start() függvényekre.Apropó kliens oldalra kipakolni mindent nem éppen biztonságtechnikai bravúr, ha csak nem a negatív rekordok egyikét akarod megdönteni. Maximum egy darab session token.
-
Bzozoo
tag
Végül sikerült összetákolnom egy működő rendszert. Rájöttem, hogy a php sessionnal nem sokra megyek. Más domainen nem érvényes a session cookie (csak ha a backend és a frontend is egy domain alatt megy), ezért a sütiket a frontend oldalon hoztam létre, persze egy sütibe beraktam a PHP session ID-t is, hátha a későbbiekben tudok kezdeni vele valamit.
A dolog úgy működik, hogy a frontend a loginformon keresztül beírt felhasználónevet és jelszót egy fetchel Post-ban elküldi a PHP backendnek, az visszaad bizonyos válaszokat, ha a Login adatok hibásak, akkor minden fail, ha nem akkor mindent visszaad az userről. Ha jó a Login akkor UserID, UserName, UserSecret, UserToken (ez majd a későbbiekben időközönként változik, hogy biztosan ellenőrizhető legyen az user) értékeket kap json kimenetben. A JavaScript ezeket letárolja sütikben és kész. A felhasználó be van lépve. Később ezek a sütik mindig össze lesznek vetve az adatbázisban lévő adatokkal, amolyan user Check folyamat.
A back- és a frontend kódjai itt érhetők el a Githubon
[link]Itt lehet tesztelni
[link]Teszt felhasználó nevek. TesztUser, TesztUser2, TesztUser4, Valaki
Jelszó mindegyiknél 12345678Ha van valami nagyon kirívó Security hiba, azt nyugodtan írjátok meg. Azt szeretném ha a rendszer mindenféleképpen biztonságos lenne.
Később a regisztrációs lehetőséget is meg akarom majd oldani.
-
pelyib
tag
válasz
Bzozoo
#20413
üzenetére
Hol tudok találni ilyesmiket, teszteket, illetve mintakódokat?
packagist.org pl, Composer-rel eleg kenyelmesen lehet hasznalni. De itt az egesz internet, keresgelj, angolul.Tehát a PHP ne JSON választ adjon?
Arra gondoltam, h ne egy "succes": true | false alapjan dontsel. Maga a status code is sokat segit, az alapjan mar szet is lehet valasztani a valasz feldolgozasat. -
Bzozoo
tag
válasz
pelyib
#20410
üzenetére
"hasznalj egy mar jol kiprobalt, tesztekkel validalt libet"
Hol tudok találni ilyesmiket, teszteket, illetve mintakódokat?
"En az oauth-t ajanlanam, ha valamit tanulni szeretnel ebben a temakorben"
Egyelőre egy kicsit magas labdának tűnik ez az Oauth, mondjuk nem rég még a PHP API készítés ötlete is mágiának tűnt (féligmeddig még most is az 😂)
"Ajanlom helyette a megfelelo HTTP status code-kat"
Tehát a PHP ne JSON választ adjon? Természetesen lesz benne hibakezelés is, ha a szerver nem tud válaszolni, akkor se legyen gond a frontenden.
"tessek dokumentalni is az interface-t"
Fogom dokumentálni a cuccot, csak még kb sehol nem tartok az egésszel, még félig-negyedig sincs kész, azt pedig nem tudom mennyire érdemes dokumentálni
Azthiszem értem, hogy mire gondolsz. Hogy használjak egy url endpointet az egészhez. És a lekéréseket is Jsonból vegyem. Majd utána nézek, hogy mit lehet etéren alkotni.
-
coco2
őstag
-
pelyib
tag
válasz
Bzozoo
#20408
üzenetére
Csak h tisztan lassunk: authentication es authorization amirol beszelsz. Mindketto eleg nagy tema, erdemes olvasgatni a temaba.
En az oauth-t ajanlanam, ha valamit tanulni szeretnel ebben a temakorben. Bar mar letezik jopar implementacioja.A lényeg az lenne, hogy egy minél biztonságosabb rendszert alkossak
Ha biztosagosat akarsz, akkor ne akard magad ezeket fejleszteni, hasznalj egy mar jol kiprobalt, tesztekkel validalt libet.
(tudom kezdokent minden erdekes, de en inkabb arra az otletre koncentralnek amit eredetileg kitalaltal, ezek csak mellekes dolgok)PHP pedig JSON-nal válaszol
Ajanlom helyette a megfelelo HTTP status code-kat. Tessek oket helyesen hasznalni, es nem minden 200 OKEzt meg csak ugy megosztom, ha mar tenyleg API-t epitesz, tessek dokumentalni is az interface-t
-
coco2
őstag
válasz
Bzozoo
#20408
üzenetére
Egy api szerverben igazán semmi nincs, amit általánosság jelleggel bonyolítani lehetne. Kliens oldalon összeraksz egy json-t, és post felküldöd a szervernek. Ott szétkapod, használod, json megy vissza. Ha általános cuccot akarsz, felejtsd el a get paramétereket, meg a mindenféle oldal címeket, mert csak megbánás lesz belőle utólag.
A magam részéről csiszolgatok éppen egy projectet, ami második körben igényelni fog nagy teljesítményű api szervert. Emberi számítás szerint ansi c-ben fogom írni. Egyenlőre nem terveztem bármit publikálni belőle, de nem kizárt, hogy a végén open source project-ként végzi.
-
Bzozoo
tag
Az erőlködés oka főként a tanulás, de emellett valami hasznosat is létre akarok hozni, amit több projekthez fel tudok használni.
Egy általános user rendszer lenne, amit főképp SPA (AndroidApp) de sima web alkalmazásokhoz is fel lehet használni, ezzel való foglalkozás közben bővíteni az ismereteimet mint a PHP API és a Javascript terén.A lényeg az lenne, hogy egy minél biztonságosabb rendszert alkossak meg és a PHP-hez csak tényleg csak akkor forduljon a frontend rendszerem, amikor nagyon kell. Bejelentkezés esetén elkerülhetetlen, de profiloldal megnyitást például úgy szeretném, hogy a login idején betöltődött adatokkal dolgozzon.
De a nagyobb biztonság érdekében úgy gondolom, hogy kell a PHP session is a képbe.
Majd ha vállalható lesz a kód, akkor felrakom a Github linkjét ide is a PHP backendnek.Lassan haladok. Egyenlőre azt a verziót csináltam meg, hogy a login PHP-nek a Javascript elküldi az input mezőkből a felhasználónevet és a jelszót a PHP pedig JSON-nal válaszol.
{'Login': 'Failed'} vagy {'Login': 'Success'}Ezen a linken található a login-form. A devtools-ot a böngészőben megnyitva látható a JSON válasz a login gombra kattintáskor.
https://codepen.io/bzozoo/full/dyONmjNIlletve még készítettem egy scriptet, ami megjeleníti a felhasználók aktuális pontjait. Ezt a PHP API-n keresztül tölti be SQL-ből.
https://codepen.io/bzozoo/full/VwmKOVjAmúgy ha van valakinek hasonló elven működő (tehát frontend oldalon Fetch API-val dolgozó, backend oldalon PHP API-val dolgozó) user rendszere, az megoszthatná elemzés céljából. Persze csak ha publikus a kód.
-
DS39
nagyúr
php + oracle esetén nem találtam a mysqli_real_escape_string alternatíváját, de a php.net-en azt olvasom, hogy value binding esetén nincs szükség ilyenre sql injection ellen.
[oci_bind_by_name]mit érdemes még esetleg alkalmazni, hogy minél biztonságosabb legyen? (vagy elég ez?)
-
coco2
őstag
válasz
Bzozoo
#20403
üzenetére
Ha a kapcsolatod session alapú (felhasználó rendszeresen lapot töltöget), akkor a server oldalán a session-t nem igazán tudod megkerülni. Api helyett egy mezei form pont elég, a submit gomb beküldi a formot, a session-be rögzíted a user bejelentkezési állapotát.
Ha spa-t hegesztesz, a hagyományos session-t elhagyhatod - ha nagyon akarod - de lévén tokenekkel operálni sem sokkal másabb, nem biztos, hogy jobban jársz. Nagyobb szerver fürtön már megkerülhetetlen a session saját kézbe vétele. Egészen addig kényelmesebb a $_SESSION[]. Az xhr-ben ráhívsz a session_id()-ra a session_start() előtt. Ha azt teljesen saját kézbe vennéd, akkor is csak ugyan az a móka: van egy text tokened, és valahonnét háttértárolóról hívod / mented a user-hez tartozó dolgokat. Konkrétan a php saját session kezelését átveheted, de maga a koncepció aligha kikerülhető webes alkalmazásokban. Talán ha többet írsz az erőlködés okáról, érthetőbb, hogy mit is szeretnél.
-
Bzozoo
tag
PHP json login API-t szeretnék készíteni. (Első próbálkozásom ilyesmivel)
A felhasználó JavaScript Fetch API-val küldené be a felhasználónevét és jelszavát egy post metódusban. Ha a PHP login script ezt megkapja és sikeresen összehasonlította az adatbázisban található felhasználónévvel és jelszóval, akkor egy json kimenetet állítana elő például {"Login" :"Success" } Ezt megkapva a JavaScript intézkedne a Sessionstorage előálításáról kliensoldalon.
Azon gondolkodom, hogy kellene valami titkos kód is, amit a PHP visszaküld a JavaScriptnek, hogy később azonosítani tudja a felhasználót, például ha le akarja kérni vagy módosítani a profilját (adatait, avatarját, beállításait stb stb)
Vagy esetleg legyen $_SESSION a PHP oldalon és ha az user sikeresen bejelentkezik, akkor a login.php kimenete valami ilyesmi lenne: {"Login" :"Success", "UserName" : "A belépett felhasználó neve", "UserSecret" : "A belépett felhasználó titkos kódja" } Ebben az esetben csak simán a böngészőbe beírva a login.php-t is megjelenne ez a JSON adat, ha a felhasználó beküldte a belépési adatait a Fetch API-val, mivel nyitna egy sessiont a PHP oldalon a felhasználónak.
Tehát az első esetben a PHP nem csinálna sessiont csak átadná a login succes jsont a JavaScript oldalnak, esetleg az user titkos kódját
Második esetben a JavaScript nem csinálna Sessionstorage - t, hanem a PHP-hez nyúlna vissza, ha kell neki valami a PHP sessionból.
Szerintetek melyik biztonságosabb eljárás? Ti milyen alapelvek mentén csinálnátok meg egy PHP Json JavaScript Fetch API-s felhasználó beléptetést?
a hiba meg mindig legyen 500
Új hozzászólás Aktív témák
- Aoostar WTR pro nas eladó, 8c/16t Ryzen7 5825u, 16GB DDR4 ram, 512GB SSD, 2X 2.5G lan, 4 HDD slot
- Xiaomi Redmi Note 13 Pro+ 5G 12GB RAM / 512GB ROM (Garancia 2026.04.10-ig)
- Gamer gép - komphone -tól vásárolt
- Samsung Galaxy A23 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi Note 14 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Lenovo ThinkPad X270 - i5-6G I 8GB I 256GB SSD I 12,5" FHD I HDMI I Cam I W10 I Garancia!
- LG OLED Televíziók: KÉSZLETKISÖPRÉS -30%
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- Csere-Beszámítás! Asztali számítógép PC Játékra! I5 12400F / RTX 3070 / 32GB DDR4 / 500GB SSD
- Google Pixel 7 Pro 128GB
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest