- Linux kezdőknek
- Gmail
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Programozás topic
- Óriási trösztellenes botrány lenne, ha a Qualcomm megvenné az Intelt
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Microsoft Excel topic
- Crypto Trade
- Java programozás
Új hozzászólás Aktív témák
-
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?[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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.
-
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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[ Szerkesztve ]
-
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
"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.
-
Bzozoo
tag
Üdv!
Van egy PHP kódom, ami egy ciklust tartalmaz, ami kiírja a ciklus indexét+1 az aktuális dátumot + időt és azt, hogy OK. Ezt teszi meg 10-szer.
https://replit.com/@ZoltnBata/PHP-WEB-TESZT#tests/timeinterval.php<?php
$date = new DateTime("now", new DateTimeZone("Europe/Budapest"));
for($i=0; $i<10; $i++){
echo ($i + 1) ." - ". $date->format('Y-m-d H:i:s') . " OK <br />";
sleep(1);
}
PHP CLI Built-In server használata esetén minden úgy megy, ahogy szeretném. Szépen tölti be az adatokat a képernyőre a ciklus haladtával, aminek a sebességét sleep funkcióval 1 másodpercre korlátoztam, tehát a 10 cikluskör 10 másodperc alatt fut le
https://php-web-teszt.zoltnbata.repl.co/tests/timeinterval.php
Apache + PHP-FPM vagy FastCGI esetén csak a 10 másodperc ciklusidő után (a ciklus végeztével) írja ki az adatokat a képernyőre.
https://scriptteszt.mysqhost.ml/php/timeinterval/timeinterval.php
Készítettem egy videót is a probléma szemléltetésére
https://www.youtube.com/watch?v=GCbyXrheGLY -
Bzozoo
tag
Talán ismered te is a mondást, hogy bug vagy feature attól függ, hogy számodra megfelel e vagy sem.
Ezt az egyszeri ráhívást megérteném, ha minden esetben így lenne, de a videón láthatod, hogy az első esetben az általam elvárt működés történik. (Ekkor a PHP Built-In szerverét használom php -S 0.0.0.0:3001 paranccsal) A másodikban viszont nem. (Apache +PHP-FPM)
Oké lenne, hogy ez egy feature, ha ki lehetne kapcsolni, mert nekem nem kell ez a fajta működés.
A témában olvasgatva a neten sok helyen szintén az ajaxos megoldást ajánlották, de ez tényleg nagyon sokkal több munka. Mennyivel szebb lenne, ha az Apache is beállítható lenne ilyen működésre.
Egyelőre a kódot a Built-In webszerver működteti, amit nem ajánlanak éles production cuccok működtetésére -
Bzozoo
tag
válasz nevemfel #21135 üzenetére
Próbáltam már, a Stackoverflow-on bemutatott összes lehetséges verzióval.
Replit forráskód
Replit demo
Apache server demo
Látható, hogy a cikluson kívüli echo-t sem írja ki az egész PHP értelmezése végéig.
Ráadásul az Apache-on notice-t is kapok, hogy no buffer, nincs mit flush-olni.
Valamit az Apache-on kéne állítani, ha lehet egyáltalán. -
Bzozoo
tag
válasz #68216320 #21171 üzenetére
Én a helyedben valami nagyon könnyű framework-el kezdenék, főleg, ha a backend és API megvalósításról van szó, mint a Slim4 https://www.slimframework.com/
[ Szerkesztve ]
-
Bzozoo
tag
-
Bzozoo
tag
Nem akartam kódolni hétvégén (elég hétközben) , de milyen cucc kell? Filmcímek alapján megjelenít egy posztert?
[ Szerkesztve ]
-
Bzozoo
tag
-
Bzozoo
tag
válasz hiperFizikus #21542 üzenetére
Hatalmas ötlet. Én beadnám a szabadalmi hivatalnak. Ők is had nézzenek egy nagyot 🤣
Új hozzászólás Aktív témák
- Magisk
- Gaming notebook topik
- Samsung Galaxy A53 5G - kevesebbet többért
- Linux kezdőknek
- Teljesen AI-alapon jön a FidelityFX Super Resolution 4.0
- Cyberpunk 2077
- Android alkalmazások - szoftver kibeszélő topik
- Autós topik
- Milyen billentyűzetet vegyek?
- Fejhallgató erősítő és DAC topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen