Két web szerver közötti kommunikáció

Web, mail, IRC, IM, hálózatok

Sziasztok!

Adott A szerver (LAMP), ahova a felhasználó belép, teszi a dolgát. Adott B szerver (LAMP), másik szolgáltatással. Azt szeretném, hogy az A szerverre belépett felhasználó egy adott ugrópontot megkattintva átléphessen a B szerverre úgy, hogy a B szerver megkapja A szervertől a felhasználói profil néhány változóját.

Ezt nem tudom pillanatnyilag, hogyan lehetne úgy megvalósítani, hogy minél biztonságosabb legyen az ügy. Nyilván kihagynám azt, amikor a böngésző küld a B szerverre POST-tal adatot, mert kíváncsi felhasználók akkor próbálkozhatnak más adatainak elküldésével, stb.

Nézem a Google-t is, de egyelőre nem akar a barátom lenni.

Hogy lehetne megoldani a tárgybeli helyzetet?

Köszönöm, Cözi

  • 2806 megtekintés

( blr v | 2016. 06. 30., cs – 17:18 )

Ha nem akarsz OAUTH-ot vagy egyéb single-sign-on megoldást implementálni, akkor egyszerűen így:
A-n generálsz egy jó hosszú tokent, ezt küldöd át a böngészőből B-nek, aki a token alapján elkéri A-tól, amit az odaad neki.
A token érvényességét természetesen A határozza meg.

+1 a tokenre, ha csak ennyi a cél, és nem kell session megosztás, nem lesz A és B szerveren is aktív munka párhuzamosan, és a változók száma relative kicsi. De mai napig vannak cURL-el szerver oldalról post-olt formok, több bankkártyás kapu így működik. (Gondolom a közös adatbázis kizárt, és a változók tartalma nem juthat a user fennhatósága alá.)

( nxu | 2016. 06. 30., cs – 20:28 )

OAuth2 lesz a baratod, ahogy felettem is irjak.

Nem tudom, milyen webalkalmazas fut egyebkent a szervereken, de vannak erre kesz megoldasok, amikkel relative gyorsan megvan az egesz.

( sj | 2016. 06. 30., cs – 20:56 )

kuki?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Cookie domainhez van, nem lesz olvasható a másik által.

Adott a 2 gep: a1.yourdomnain.kom es b1.yourdomain.kom. Ha a cookie domain parameteret yourdomain.kom-ra allitod, maris latni fogja a masik...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

a kerdezo eseteben mindossze 2 geprol volt szo. De a te esetedben lehet {a1,b1}.subdom.yourdomain.kom csak annak a 2 gepnek. Mindegy, a cookie-s verzio egy lehetseges megoldas a feladatnak...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( dotnetlinux | 2016. 06. 30., cs – 21:13 )

Mennyire vannak "messze" a LAMP-ok? Egy közös/félúton lévő memcache/bármilyen-más-közös-tároló alkalmas lehet adat cserére.

Mindkét helyen megvannak az "User adatok és csak az ID-t kell átküldeni" vagy komplett infót kell?

( Cozi v | 2016. 07. 01., p – 10:43 )

Most úgy tűnik, hogy tokeneket használok majd. Az A szerver beír a B szerver adattáblájába, ami majd a felhasználót azonosítja, amikor a böngészővel átlép a B szerver honlapjára. B szerver ekkor összeveti a böngészőből kapott tokent a saját adatbázisával.

Egyelőre ezt dolgozom ki, meglátjuk :-)

Köszönöm az ötleteket, ha akad jobb, szívesen veszem!

Cözi

( Dacr (nem ellenőrzött) | 2016. 07. 01., p – 14:26 )

Esetleg Redis master-slave felállás és abban tárolni a sessiont/tokent?
És akkor nincs POST-al mozgatás, nincs elkérés, hanem mindkettőn ott leledzik majd a kérdéses infó, a webalkalmazás meg Redisből szedi ki az adott user adatait.
Nyilván le kell tenni valami azonosítót HTML5 storage-ba, ami alapján a webalkalmazás azonosít.

Két okot látok: van aki sok lépéssel előre gondolkozik, milyen jó lesz az a nagy izé később, amikor több mindenre is tudjuk használni (kérdéses de megtörténhet), és van aki szeretné végre kipróbálni azt a valamit, amiről sokat hallott, jó esetben tesztelte is már, de még nem volt éles munkában hasznosítva.

(Félreértés elkerülése végett: szerintem a Redis nem rossz megoldás, ha indokoltá válhat közeljövőben, és van vele tapasztalata a fejlesztőnek, ha viszont nincs, akkor szerintem is felesleges és költséges.)

van aki szeretné végre kipróbálni azt a valamit, amiről sokat hallott

azert ez sem feltetlen egy eletbiztositas, hacsak nem illeszkedik a keep it simple elvhez...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

A kulcs a skálázhatóság. Elég sok nagyon egyszerű feladatból lesz a végén olyan rendszer, ami tele van gányolással, majd mikor még egy nodeot be kell iktatni, csak kamilláznak, hogy ezt a foshalom "mindent megoldunk PHP-ből" valamit hogyan fogják bővíteni. Ilyenkor jön a teljes refaktor.
Ehelyett előre gondolkodva be lehet iktatni egy olyan eszközt, ami lerendezi az egészet és nincs keresztbe-kasul kérdezősködés. A Redis nem egy vagány technológia, kb. egy kibővített memcached. Ez azért nem egy űrtechnika és nem kell neki Paks erőforrásnak.

"A kulcs a skálázhatóság. Elég sok nagyon egyszerű feladatból lesz a végén olyan rendszer, ami tele van gányolással, majd mikor még egy nodeot be kell iktatni, csak kamilláznak, hogy ezt a foshalom "mindent megoldunk PHP-ből" valamit hogyan fogják bővíteni. Ilyenkor jön a teljes refaktor."

Szóval az hogy égre földre replikálsz akár több, távoli szerver között, mindent, aminek csak egy nagyon kis részére (ha a módosításokat is számba veszem, akkor pedig százalékosan is nehezen kifejezhető mennyiségű) van szükség, ahelyett hogy ha nagy ritkán szükség van rá, egy request-el lekérdezed az éppen aktuális adatokat, szerinted egy jó megoldás egy faék egyszerű problémára. Mert ez előbbi egyébként nem skálázódik...

// Happy debugging, suckers
#define true (rand() > 10)

Ekkor szoktak a project vezetők vérszemet kapni, hogy ha ez működik, akkor xyz funkciókat is adjuk át a B szervernek. Az esetek 90%-ában így szokott lenni. Nyilván jelen pillanatban ez egy nudli probléma, térjünk vissza rá egy év múlva, mert gyaníthatólag nem áll le a fejlesztés ezen műveletük után sem.

Vagyis az kevésbé funkcionális hogy teljesen feleslegesen zabáljuk a memóriát, fogyasztjuk a sávszelet hogy mindent minden időpillanatban replikáljunk távoli szerverek között, az összes változtatással és kutyafülével úgy hogy azokra nincs szükség. Ha pedig mindezt megtesszük, az bizony előremutató, mert még többet replikálhatunk majd feleslegesen ha szükség van rá. Ne haragudj, de ez nem így van. És akkor még arról nem is beszéltünk amikor a replikáció széthullik és lehet vele szöszölni

Én is használok redis-t, pl cache-nek / session tárolásra / queue kezelésre, több szerver között is, de ezekre minden szervernek szüksége van, mindig, a működésükhöz.

Skálázhatóság != továbbfejleszthetőség, habár van némi kapcsolat, illetve teljesen felkészülni előre minden váratlan dologra úgysem lehet. Marad az igényes kódolás, aminek mindig alapnak kéne lennie, és megkönnyíti a továbblépést, de ez csak szükséges és nem elégséges feltétel.

--

Nem fogalmaztam pontosan, ez tény. Mind a fejleszthetőség és a skálázhatóság szerepet játszik. Felkészülni nem lehet, de számítani rá igen, így sok esetben kifizetődőbb plusz egy apt-get parancs, mint később (amikor már a 4. ilyen van akár igényesen is lekódolva) újratervezni az egészet.

Nem. Nem gondolkodsz elore. Nem teszel bele olyat, ami _majd_ jol jon. Nem. Mert aztan ugyan erre szukseg volt tenyleg, arra meg nem, szoval a masikat el kell tavolitani a kodbazisbol, de arra sincs mindig ido, szoval halott kod es halott megoldasok taszitjak az egesz projectet a legacy temetobe.

Ehelyett modularisan epited fel a szoftvert, es az eppen aktualis igenyeknek megfeleloen implementalod az adott funkciot. Ez onmagaban foglalja a microarhitekturalitasra torekvest, ami nem jelent azonnali szetbontast egyebkent, hanem szinten best practice-k hadaval felvertezve ugy kell az alkalmazast felepiteni, hogy szukseg eseten konnyeden bonthato legyen.

Szoval gondolkozni kell alapvetoen, nem mindent belehanyni a kodbazisba es az infrastrukturaba, "egyszer majd jo lesz az, bela batyam" alapon.

+1, ezt írtam le: "van aki sok lépéssel előre gondolkozik, milyen jó lesz az a nagy izé később, amikor több mindenre is tudjuk használni (kérdéses de megtörténhet)", ugyan azt nem írtam hozzá, hogy ez nem jó döntés, mert nagyon nagy kérdés, hogy megtörténik-e

Nekem magyarázták már, hogy a "keep it simple" azt jelenti, hogy olyan elemekből építkezzünk, amik kész vannak, azok egyszerűbben fenntarthatóak, mint egy saját fejlesztés, és persze az, hogy ezek az elemek adott esetben többezer ismeretlen részből állnak nem növeli a komplexitást, de nem ám hittem el.

Viszont abban van valami, hogy a vérszemet kapó manager kérheti, hogy na akkor teljes szinkronitás a két rendszer között...de lehet, hogy ez a fejlesztés is már csak "nyűg", vagy próba, vagy akármi, ha nem tudom én nem tippelném meg, hogy vajon megéri-e odarakni a Redis-t. Hangsúlyozom, főleg, ha nincs használva másra, nincs a fejlesztőnek tapasztalata vele, nincs már most is üzemkészen, ...

Feladat: egy tokent eljuttatni egy browseren keresztül egy másik szervernek, hogy az adatokat kérdezzen le az elsőtől.
Megoldás: egy köztes adatbázis, amely az eredeti adatbázison túl egy tokent is tartalmaz, folyamatosan szinkronizálva ez első szerver adatbázisával, illetve a távoli szerverrel.
Ez semmilyen körülmények között nem értelmezhető megoldásként.

Nekem magyarázták már,

a keep it simple azt jelenti, hogy a vegtermek a leheto legegyszerubb...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

dacr informatikai szakerto kft egy napja:
ugyfel: - hallo szeretnek egy single sign-ont az oldalamra
ceg: - rendben redist rakja fel osszekokanyolunk melle valami phptot majd az jo lesz skalazhato lesz meg ujra felhasznalhato
ugyfel: - koszi.

ugyfel: - hallo szeretnem ha menne facebookkal is a funkcio
ceg: - rendben ha mar ugyis van redis felhivjuk a facebookot es replikaljuk userdbjuket

ugyfel: - hallo szeretnem ha a formoknal csrf token lenne
ceg: - nem baj, van redis azert vezettuk be, hogy sokmindenre hasznaljuk total ertelmetlen es indokolatlan esetekben is, jo lesz az. oda phpzunk neked valmi redises csrf token funkciot, mert DB nelkul tul gyors lenne es ugy meg nem kihivas az elet.

ugyfel: - secure download kellene tobb static serveremre is
ceg: - Haaut aze lett redis, hogy hasznaljuk, es meg replikaja is van, tehat szuperstabilbiztonsagot meg gyors is!!! Majd akkor bekotjuk hogy php szolgalja ki fileokat es redisbol ellenorzi secure tokent es minden lekeresre generalunk egyet.

A beszelgetesekbol kihagytam, de valoszinuleg elokerult nodejs es socketio, webrtc, localStorage, webgl es cassandra es elasticsearch is mint megoldasok. De nem mint opcionalitas, hanem mint tovabbi layerek a stabilitas es a skalazhatosag fokozasa miatt444!!