Ú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 ]
-
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
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?)
[ 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 ]
-
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
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 OK
Ezt meg csak ugy megosztom, ha mar tenyleg API-t epitesz, tessek dokumentalni is az interface-t
[ Szerkesztve ]
-
coco2
őstag
válasz
Bzozoo
#20411
üzenetére
Egy json nagyon komplex is tud lenni. Minden bele tud férni. A szolgáltatás címzése, az alszolgáltatás, a kért kiszolgálók, a paraméterek, minden.
Ha közös webszerver pontra dobálod az összes api kérést, és nem 100 felé, később karbantarthatóbb lesz az api szervered.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
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.
-
sztanozs
veterán
jsonben átadni mindent szvsz antipattern, tessék használni inkább URI paraméterezést, HTTP Verb-öket és status code-okat: [link]
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...
-
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é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 ]
-
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.
[ 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 ]
-
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
-
-
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).
[ 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 -
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[ Szerkesztve ]
-
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.
-
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.
Rally against apathy draws small crowd
-
nevemfel
senior tag
-
-
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[ Szerkesztve ]
-
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).[ 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...
-
-
-
a hiba meg mindig legyen 500
Új hozzászólás Aktív témák
- A gyerekem "tartalmat gyárt". Mit tegyek?
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen RAM-ot vegyek?
- Xiaomi Mi 9 - egy híján
- AMD Navi Radeon™ RX 6xxx sorozat
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- "A homoszexualitás természetellenes" 😠
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Szólánc.
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest