JSF - egy user egy időben egy helyről lehessen csak bejelentkezve

 ( bodnarj | 2019. szeptember 6., péntek - 8:42 )

Sziasztok!

Azt kellene valahogy elérnem, hogy egy user egy időben csak egy helyről lehessen bejelentkezve.

Tehát ha A eszközről be van jelentkezve a user majd átmegy a B eszközhöz és onnan bejelentkezik akkor A eszközről dobja ki. Természetesen a session lejárati időnek továbbra is meg kell maradnia.
Van erre valami gyári támogatás, vagy hogy lehet ezt megoldani?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Konkrétan hogy van megvalósítva a bejelentkezés? Valami standard komponenssel (melyikkel), vagy saját implementáció van?

Elvben nagyon egyszerű: a bejelentkezéseket menedzselő alrendszer nyilvántartja a httpsession<->user összekötéseket. A lényeg, hogy kétirányban kereshető legyen ez az összekötés, ne csak session->user irányba. Amikor egy user bejelentkezik, akkor lekérjük a meglévő session-jét, és ha találunk, akkor érvénytelenítjük. A probléma csak az, hogy ehhez fel kell deríteni, hogy jelenleg mi és hogyan működik, és abba hogyan lehet belepiszkálni.

Ilyenekre nincs gyári megoldás.

Azért nincs, mert anti-pattern, azt jelzi, hogy valami el van baszva valamelyik alsóbb rétegben és addig dobálják a forró krumplit egymásnak, amíg valaki bele nem kendácsolja valahova, ahol aztán n+1 egyéb problémát okoz.

--
https://iotguru.live

> Azért nincs, mert anti-pattern, azt jelzi, hogy valami el van baszva valamelyik alsóbb rétegben

Ezt kifejtenéd, hogy miért? Mert azért lenne a kizárás fontos, hogy a user egyik munkamenete technikailag zavarná a másikat? És nem azért mert ez valamilyen valós üzleti igényből adódó követelmény volna?

Mondjuk az az üzleti igény, ami ilyet támaszt, sosem látott még weblapot, és már ott el van baszva, hogy weben akarja megoldani a bármit.

Pl. fejlesztesz egy SaaS-t, amit per user licencelsz, es nem szeretned, ha a kedves vasarlo 1 db accounttal lefedne az egesz szervezetet, mint ahogy nagyon sok helyen egyebkent megprobaljak, pl. a ceges levlistan korbekuldott wincmd.key fajl, egesz ugyvedi iroda altal kozosen hasznalt Opten user, meg a tobbi hasonlo okossag.

Nem olyan elborult scenario ez.

"Nem olyan elborult scenario ez."

Hogyne lenne elborult... ennél sokkal egyszerűbb letenni audit táblába, hogy melyik user mikor és mennyit volt belépve, aztán mehet a levél a licencgazdának, hogy szopás lesz ebből öcsém, ha így megy tovább. Ha meg nem tudnak egymásról a példányok (lásd WinCmd), akkor meg úgyis mindegy, mert a egy user - egy session nem véd meg semmitől.

Persze, lehet mondani, hogy technikai meg üzleti oka van, de ilyenkor egyszerűen az a helyzet, hogy a balfaszok terveznek és építenek olyan rendszereket, amelyek meghaladják a kompetenciájukat.

--
https://iotguru.live

> ennél sokkal egyszerűbb letenni audit táblába

Ez mitol egyszerubb? :)

Ránézésre is sokkal egyszerűbb mint az, hogy keresztülhugyozod a rétegeket, hogy a stateless szolgáltatások garmadáján keresztül meg tudjad oldani egy clustered rendszerben, hogy kidobd a felhasználót, ha kapott egy másik session-t. Aztán meg kezeled a végtelen mennyiségű hibát, ami mindebből következik, terhelve a call-center-t és az it-support csapatot és végül már egy komplett rule engine dolgozik workflow menedzsmenttel, hogy mikor kell tényleg kidobni a felhasználót és mikor van az, hogy mégiscsak legális egy másik session, mert valamelyik legacy fos üzletileg annyira fontos, hogy annak mennie kell, de nincs már fejlesztője 13 éve és 7 hónapja, ezért mindenki ahhoz kell igazodjon.

Mindezt azért, mert 'Persze, Józsikám, meg lehet oldani, hogyne kérlek, holnapra? Igen, meglesz.'

--
https://iotguru.live

Ez jó, hogy onnan indulva hogy nincs ilyen mert nem kellene, hogy igény legyen rá eljutottunk oda, hogy ez annyira kurvára bonyolult, hogy meg sem lehet oldani :-). "Keresztül kell hugyozni a rétegeket" :-)

Gondolom amikor a megrendelőd kér valamit, akkor megmondod neki, hogy bocs, ez nem fog menni mert nem akarom keresztülhugyozni a rétegeket.

Mondjuk, amikor fasságot kér a megrendelő, akkor mondjuk minimum elmondom neki, hogy ez fasság, megpróbálom megérteni, mit akar, s valami rendes megoldást javasolni neki a problémájára.

Mert ilyen környezetidegen megoldások általában valami problémára megoldásként születnek meg a megrendelő fejében, de ezek seggfej megoldások, amiknél van jobb.

De egyébként talán az Optenben láttam ilyet, jogos, láttam már a weben OPben leírt dolgot. Ott is seggfej megoldásnak gondoltam, egy _Héló, te nem-e licenszt szegsz jelenleg, mert ha igen, seggbekúrunk_ üzenet valszeg sokkal hatásosabb lenne. :-/

> amikor fasságot kér a megrendelő, akkor mondjuk minimum elmondom neki, hogy ez fasság

Nem ertem, mi a baj azzal az uzleti (ertsd: nem technikai) igennyel, hogy egy adott szolgaltatast egy accounttal csak egy user hasznalhasson. Nem akarok behajtocegeket fizetni, nem akarom a NAV-nal felnyomni a potyautasokat, stb., csak annyit akarok, hogy ne tudjon egy egesz tetves ugyvedi iroda az adatbazisomon logni egy darab accounttal.

Mondjatok meg kerlek, hogy ez az igeny miert faszsag uzleti (!!!) (ertsd: nem technikai) ertelemben.

Btw emlekeim szerint itt a hupon is volt mar sivalkodas, amikor az Oracle/Microsoft/akarki bejelentkezett, hogy szeretne megszamolni a licenceket, ugyhogy el kene donteni, hogy jogi vagy tech oldalrol fogjuk meg a problemat, de az egyikre mindenkeppen szukseg van, es az ingyenelok mindket esetnel visitani fognak.

Az ingyenélők mindig visítani fognak xd
Aki meg nem olvassa el a szerződését, az is.

"Nem ertem, mi a baj azzal az uzleti (ertsd: nem technikai) igennyel, hogy egy adott szolgaltatast egy accounttal csak egy user hasznalhasson."

Nincs ezzel semmi baj. A probléma az, amikor nem egy üzleti problémát akarunk megoldani technikai eszközökkel, hanem amikor jön az üzlet és hoznak egy technikai megoldást, hogy azzal és csakis azzal lehet megoldani a problémát.

"Nem akarok behajtocegeket fizetni, nem akarom a NAV-nal felnyomni a potyautasokat, stb., csak annyit akarok, hogy ne tudjon egy egesz tetves ugyvedi iroda az adatbazisomon logni egy darab accounttal."

Semmi ilyen nem kell, túlkomplikálod. Annyi kell, hogy rendszeres időnként kapnak kimutatást arról a felhasználók, hogy mit vettek meg és amúgy hogyan használják. Ha egyszer-egyszer megsértik, azzal amúgy semmi baj nincs általában, senkinek nem fáj. És ezen felül nagyon gyakran van olyan, hogy ezekkel csak szopatod azokat, akik legális felhasználói a rendszernek, de a védelem rendszeresen kibaszik velük.

"Mondjatok meg kerlek, hogy ez az igeny miert faszsag uzleti (!!!) (ertsd: nem technikai) ertelemben."

Mert nem úgy kell kivitelezni, ahogy szeretnék. Egy csomó opció van, amelyek kényelmesebbek, könnyebben implementálhatóak, kevesebb káros mellékhatással járnak, érthetőbbek minden fél számára. De sokan megragadtak a múltban, illetve rágerjedtek egyetlen megoldásra és azt akarják keresztülvinni tűzön-vízen át, kerül, amibe kerül.

"Btw emlekeim szerint itt a hupon is volt mar sivalkodas, amikor az Oracle/Microsoft/akarki bejelentkezett, hogy szeretne megszamolni a licenceket, ugyhogy el kene donteni, hogy jogi vagy tech oldalrol fogjuk meg a problemat, de az egyikre mindenkeppen szukseg van, es az ingyenelok mindket esetnel visitani fognak."

Oszt? Visítsanak.

--
https://iotguru.live

> Semmi ilyen nem kell, túlkomplikálod. Annyi kell, hogy rendszeres időnként kapnak kimutatást arról a felhasználók, hogy mit vettek meg és amúgy hogyan használják.

Ezt nem gondolhatod komolyan. Ez kb olyan, mintha a kartyas telefonomra toltenek 2500-at, de ha akarnek, akkor telefonalgathatnek 5000Ft-ert is, maximum megdorgal a szolgaltato.
Es ha minden harmadik ugyfelem szarik ra, hogy mi van a szerzodesben akkor vehetek fel egy plusz embert, aki ezeket probalja terelgetni meg viszi jogi utra a dolgot ha muszaj, csak mert egyesek szerint az egy felhasznalo - egy session az anti-pattern. OK.

>Mert nem úgy kell kivitelezni, ahogy szeretnék. Egy csomó opció van,
Azt nem ketlem. Ha nekem lenne olyan uzleti modellem ahol az arum mertekegysege a felhasznalo szam, en is egybol az egy user - egy session megoldasra lonek mint elsodleges vedvonal. Tisztabb, szarazabb, biztonsagosabb erzes. Egyet vettel, egyet kapsz. Ezzel egybol megsporolok egy csomo kellemetlen helyzetet. pl mi van ha Dr Joska az ugyved belep a szolgaltatasba 3 kulonbozo bongeszobol a geperol, mert neki ugy kenyelmes? Te kuldod neki a felszolitast vagy az extra szamlat ho vegen, mert harom parhuzamos sessiont latsz, o meg nem erti hogy mi van. Nyilvan lehet tisztazni, el lehet neki magyarazni, meg az egesz irodajanak, meg a masik 30 irodanak is, hogy nem szabad belepni 2 kulon bongeszobol, mert azt illetektelen felhasznalasnak erzekeli a rendszer. Nincs a vilagon az a fejleszto, aki keresztulhugyozna akar egy betonfalat is ha kell (amugy nem kell, foleg nem JSF-fel ami minden, csak nem stateless), csak hogy ezt elkerulje.

De mindenki ugy csinalja, ahogy neki jobb...

A gitlab pl. per user számláz, és ott mondanék fel, ha nem tudnám egyszerre a desktopomról, a mobilomról és a tabletemről használni, és folyamatosan be kellene lépnem (lehetőleg 2FA-val) minden eszközön, majd ott kidobni a korábbi sessionjeimet.

Jó, de a GitLab ügyfélcentrikus, nyilván nem fog olyat kikényszeríteni, amivel ügyfeleket veszt... :)

Az ilyen felmerülő tárgybeli faszságok meg leginkább pár évtizede a piacon lévő mamutok agyából pattannak ki, ahol úgy gondolják, hogy a piaci helyzetük lehetővé teszi az ügyfelek szarrá szopatását. És amúgy igazuk van, mert a konkurenciájuk pont ilyen gondolkodásmóddal megáldott behemót zsíros seggű mamut, de azért a lófasznak is van vége, az embernek legyen egy kis szakmai önérzete.

--
https://iotguru.live

> Jó, de a GitLab ügyfélcentrikus, nyilván nem fog olyat kikényszeríteni, amivel ügyfeleket veszt... :)

Nyilvan ez az egyetlen kulonbseg, nem pedig az, hogy a gitlab egesz masra van kitalalva, mint mondjuk egy read-only adatbazis, amibol midegy, milyen accounttal query-zel, ugyanaz jon vissza.

Egyebkent sem aggodnek sokat az olyan ugyfelek elvesztese miatt, akik sajnalnak kifizetni <1 starbucks-os cappuccino arat havonta munkaeszkozre. Az ilyen majd talal a sajat szinvonalanak megfelelo szolgaltatot.

Es kiadnad barkinek a gitlab felhasznoli nevedet/jelszavadat? Nyilvan nem, mert semmi ertelme es semmilyen modon nem tudsz belole ertekelheto anyagi elonyt kovacsolni, igy vedekezni sincs ertelme ellene.
Ha valami adatlekeros szolgaltatasrol van szo (cegtar, tulajdoni lap, mittudomen) mindjart mas a leanyzo fekvese.

"Ha valami adatlekeros szolgaltatasrol van szo (cegtar, tulajdoni lap, mittudomen) mindjart mas a leanyzo fekvese."

Térjenek át per lekérdezés alapú számlázásra és tényleg mindjárt más a leányzó fekvése.

De szerintem is a legjobb, ha párhuzamos portra köthető hardverkulcsot osztogatnak, ami néha elbassza a nyomtatást, mert nagyjából abból a korból maradtak vissza ezekkel a remek ötletekkel.

--
https://iotguru.live

> Térjenek át per lekérdezés alapú számlázásra és tényleg mindjárt más a leányzó fekvése.

Miert? Mert a fejleszto urak azt mondtak? Az nem valid igeny, hogy a kis ugyfeleknek van lekerdezesenkenti arazas, a nagyobbaknak meg flatrate per user?

"Miert? Mert a fejleszto urak azt mondtak?"

Ahja, van ez így.

Egy építésznek is mondhatod, hogy nem kell olyan vastag betonfödém, az is ügyféligény, nem? Ha meg azt mondja, hogy azt úgy nem vállalja, akkor az építész a köcsög, mi? Ha meg egy másik elvállalja, megépül, aztán rád omlik egy szép napon, akkor meg az volt a köcsög, amelyik nem szólt, hogy nem lesz jó, ugye?

"Az nem valid igeny, hogy a kis ugyfeleknek van lekerdezesenkenti arazas, a nagyobbaknak meg flatrate per user?"

Dehogynem, valid. De még mindig ott tartunk, hogy ezt egy olyan keretrendszerbe akarjuk belekókányolni, ami erre alkalmatlan és a belekókányolás olyan mellékhatásokat okoz, amelyek sokkal többe kerülnek.

--
https://iotguru.live

> Egy építésznek is mondhatod, hogy nem kell olyan vastag betonfödém, az is ügyféligény, nem?

Nem, az nem ugyfeligeny. Az ugyfeligeny az, hogy hany szobat szeretnek, meg hogy legyen-e terasz. Ha mondom az epitesznek, hogy szeretnek egy teraszt, mert nyaron jo lenne kiulni egy pohar borral, erre az epitesz azt mondja, hogy bort inni hulyeseg, azzal nehez utana egyutt dolgozni.

A valóság igazából az, hogy az építész gondolkodás nélkül beteszi a vékony födémet, a statikus meg vakarja a fejét utána :)

"Nem, az nem ugyfeligeny."

Akkor az se ügyféligény, hogy egy informatikai architektúrát hol és hogyan gyengítünk meg.

"Ha mondom az epitesznek, hogy szeretnek egy teraszt, mert nyaron jo lenne kiulni egy pohar borral, erre az epitesz azt mondja, hogy bort inni hulyeseg, azzal nehez utana egyutt dolgozni."

Bocsánat, de nem arról beszélünk, hogy egy gomb milyen színű legyen vagy hogy egy form hogyan nézzen ki, hanem éppen az architektúra tartószerkezetét baszkuráljuk, hogy ne legyenek oszlopok a belső térben, de azért legyen a födém is olyan vékony, mintha oszlopok tartanák.

--
https://iotguru.live

> Akkor az se ügyféligény, hogy egy informatikai architektúrát hol és hogyan gyengítünk meg.
> éppen az architektúra tartószerkezetét baszkuráljuk, hogy ne legyenek oszlopok a belső térben, de azért legyen a födém is olyan vékony

Az ugyfeligeny az, hogy 1 db user egyszerre csak 1 db peldanyban lehet bejelentkezve. Nem beszel neked az architekturarol, JSF-rol, akarmirol, mert nem tudja, mit jelentenek ezek a szavak.

"Az ugyfeligeny az, hogy 1 db user egyszerre csak 1 db peldanyban lehet bejelentkezve."

Nem, ez nem ügyféligény, ez úgynevezett ügyfélmegoldás. Ilyenkor meg kell kérdezni, hogy miért akarja ezt így, mert meghozott egy architektúrát mélyen érintő döntést különösebb hozzáértés nélkül.

"Nem beszel neked az architekturarol, JSF-rol, akarmirol, mert nem tudja, mit jelentenek ezek a szavak."

Nem, csak jön, és egy megoldást javasol. Nyilván nem kell tudnia arról, hogy mit jelentenek ezek a szavak, de akkor had én döntsem el, hogy mi az, amit megvalósítunk egy adott architektúrában.

Leírom újra: ha az adott infrastruktúrában és architektúrában nincs erre bevált és széles körűen támogatott megoldás, akkor három opció közül lehet választani:
a, az üzlet átgondolja az igényét, hogy tényleg ennyire fontos-e
b, áttérünk egy olyan infrastruktúrára és/vagy architektúrára, amelyik támogatja ezt az üzleti igényt
c, felmondunk és az utódunk újra szembesül ezzel a döntéssel vagy jön egy mekkmester, amelyik belekókányolja

Mind a három opcióval találkoztam bőven, hosszú távon az "a" és a "b" járható, a "c" eleinte olcsó, aztán exponenciálisan kurva drága lesz a sok custom kókányolástól és/vagy attól, hogy a céghez értelmes ember már nem megy (olcsón) dolgozni.

--
https://iotguru.live

Nem ertem. Egy csomo site-on sikerult azt is megoldani, hogy lassam az osszes bejelentkezett eszkozomet, es egyesevel kijelentkeztethetem oket. Tenyleg sokkal bonyolultabb lenne ezt automatikusan megtenni bejelentkezeskor?

Oké, feladom, csináld így.

--
https://iotguru.live

De ott _eleve_ így lett tervezve a rendszer, te meg most egy rég kész, műgyantába öntött rendszerbe akarok belehekkelni ezt.

Ez mibol derult ki? OP eredeti posztja, es az 1 db kommentje nem ir ilyesmit.

+ Onnan indult a thread, hogy ertelmetlen-e az igeny az uzlet reszerol.

Mert az esetek nagyon nagy részében tényleg értelmetlen igény az üzlet részéről és teljesen más a kiinduló problémájuk, amire azt megoldást találják ki, hogy egyszerre egy user session legyen lehetséges.

És éppen ezért hangyafasznyi előnnyel nem járt sehol üzletileg egy ilyen korlátozás, nem dőlt hirtelen a többlet licencből a többlet lóvé, ahogy azt pörgő dollárszemekkel elképzelték; ellenben több lófasz került több seggbe, mert több lett az ügyfélpanasz és a mellékhatásokból következő hibák további kezelése is elvitt egy csomó erőforrást.

Olyan ez, mint a hardverkulcs volt anno: nem tudtál olyan hardverkulcsos szoftver mondani, amihez ne lett volna tört verzió, ezért még azok is a tört verziót használták, akiknek volt hardverkulcsuk, mert akkor nem baszakodott a legális szoftverük a lehető legváratlanabb időpontokban a hardverkulcs miatt, illetve nem baszta szét a nyomtatást, plotterezést, CNC vezérlést és egyebeket a hardverkulcs csuklása.

--
https://iotguru.live

Főleg amikor 2015-ben is párhuzamos portos kulcsot adnak egy szoftverhez.

Onnan, hogy kérdezi :D

JSF-fel elegansan megoldhato. Valami bongeszoben futo SPA-val meg JWT-n alapulo autentikacioval valoban lehetetlen lenne nem anti-pattern modon kivitelezni.

Azokkal is könnyen megoldható.

Azert gondolom, hogy JWT-vel nem oldhato meg normalisan, mert a JWT token nem visszavonhato. Amig le nem jar a token, addig be lehet lepni vele. Ezt kikuszobolendo szoktak azt csinalni, hogy szerver oldalon eltaroljak oket aztan kulonbozo map-ekben listazzak hogy melyik aktiv tokennel nem lehet mar belepni. Szerintem ez a JWT kiherelese.

"Ezt kikuszobolendo szoktak azt csinalni, hogy szerver oldalon eltaroljak oket aztan kulonbozo map-ekben listazzak hogy melyik aktiv tokennel nem lehet mar belepni. Szerintem ez a JWT kiherelese."

Miért gondolod úgy, hogy JWT-vel nem oldható meg normálisan, holott például némelyik SSO szerver kezel JWT token visszavonási listákat, de pár réteggel lejjebb már normálisan megoldható?

--
https://iotguru.live

Volt már olyan, hogy többen kaptunk egy Jira felhasználónevet, és mindig lehetett aláírni a posztokat név szerint, hogy akkor ki mit írt, meg ki mivel foglalkozik. Soha többet.

Egyébként meg egy adatlekérős szolgáltatásnál sem látom, mi akadályoz meg abban, hogy lekapjak ~20-30 tulajdoni lapot hirtelen, print screennel, vagy print to pdf-fel elrakjam magamnak offline, majd továbbpasszoljam az egy és egyetlen sessiont másnak, amíg én offline feldolgozom azt, amit akarok róla.

De ha kicsit jobban nem akarnék fizetni, valszeg meg lehetne azt is csinálni, hogy egy Chrome plugin megosztja a userek között a session infokat, és a backenden csak annyit látsz, hogy egy böngészőböl, de több tabból használom az oldalt. És akkor jöhet a ne lehessen több tabból se használni hack, ami meg keresztbecseszi azt, amit a user megszokott az interneten, mert a ctrl+click sem fog menni...

Az összes ilyen technikai hack kerülhető, és csak a usert szopatja, mert az adott platformon megszokott UXet cseszi keresztbe.

Sot, a user feltorheti a szolgaltatast futtato szervereket, es keszithet maganak DB dumpot, amit majd offline feldolgoz, de epp ezert nem is mondtam olyat, hogy tokeletes vedelem letezik.

Ha eleg korulmenyesse teszed a visszaeleseket ahhoz, hogy ne erje meg foglalkozni vele, akkor ennyi, mission accomplished.

jó, de az egy session / user az nem a feltörést teszi körülményesebbé, hanem a használatot.

A millió HUP plugin, meg a Neptunhoz írt Greasymonkey scriptek, az AdBlock, stb. meg azt mondatja velem, hogyha valamit körülményes használni, akkor a userek idővel megoldják, hogy ne legyen szar használni.

A user ebbol csak akkor lat barmit, ha a ceg okosban akarja elintezni a licencelest, egyebkent normalis hasznalat mellett sosem derulne ki, hogy korlatozva van a session darabszam.

A jatek kedveert rugaszkodjunk el a par dollaros gitlab accountoktol, boven van a piacon olyan szolgaltato, aminel az eves subscription per user millios tetel, ahol bizony a session korlatozas csak egy countermeasure a sokbol, pl. ott kezdodik a setup, hogy elkerik az IP tartomanyt, ahonnan megnyitva az oldalt egyaltalan megjelenik a login form.

> Egyébként meg egy adatlekérős szolgáltatásnál sem látom, mi akadályoz meg abban, hogy lekapjak ~20-30 tulajdoni lapot hirtelen
Nyilvan semmi. Ha egesz nap azt akarod hallgatni, hogy "MARIKA VEGEZTEL MAR?? IGYEKEZZ MER A JUCINAK IS SURGOS MEG RAM IS VARNAK MAR".

"Nyilvan semmi. Ha egesz nap azt akarod hallgatni, hogy "MARIKA VEGEZTEL MAR?? IGYEKEZZ MER A JUCINAK IS SURGOS MEG RAM IS VARNAK MAR"."

Pont ez történik akkor, ha csak egy user lehet benn és amúgy nincs pénzük kettő licencre. Meg fogják kerülni kreatívan a korlátot, csak közben szopatod azokat, akik nem akarják üzemszerűen megkerülni, de véletlenül beleütköznek.

--
https://iotguru.live

+1

Gratulálok, összehoztál egy csomó szalmabábot.

"De mindenki ugy csinalja, ahogy neki jobb..."

Így van. Amíg lószar van, veréb is lesz.

--
https://iotguru.live

Nem is tudom minek reagaltam. Igerem, tobbe nem fordul elo.

Sehol nem írtam, hogy ne lehetne megoldani. De anti-pattern ebben a környezetben, rettentő sok problémát eredményez.

"Gondolom amikor a megrendelőd kér valamit, akkor megmondod neki, hogy bocs, ez nem fog menni mert nem akarom keresztülhugyozni a rétegeket."

Hogyne, ez a szakmám. Ha valamilyen megoldással szakmailag nem értek egyet, akkor nyilván nem fogom körbetákolni. Ha meg nagyon erősködnek, akkor majd keresnek helyettem valaki mást, aki körbetákolja nekik... úgy látom vannak azért jelentkezők szép számmal.

--
https://iotguru.live

"Mert azért lenne a kizárás fontos, hogy a user egyik munkamenete technikailag zavarná a másikat?"

Miért is zavarná, hacsak nem elbaszott a rendszer? Ha zavarja egymást a két belépése, akkor szarul van valami implementálva és/vagy a szőnyeg alá van söpörve egy komoly probléma. Attól nem lesz jobb a helyzet, hogy csokipapírba csomagoljuk a szart.

"És nem azért mert ez valamilyen valós üzleti igényből adódó követelmény volna?"

Eddig nekem nem tudtak erre valós üzleti igényt mondani, mondanál egyet? Eddig a legjobban valami ködös biztonsági okokkal tudták megmagyarázni, de arra is vannak jobb megoldások.

--
https://iotguru.live

És az ilyen hekkmágus lesz az, aki a sok semmirevaló hozzánemértő managernél pirospontot szerez ezért... "Na végre valaki aki hajlandó dolgozni és megold bármit".

Az, aki meg próbálja megértetni velük hogy ez büdi/gyanús az meg a "problémás" fejlesztő lesz. A jutalom pedig az, hogy a menedzserkék majd a bólogató jánost tolják előre. Aki innentől már pozícióból meg erőből átviszi az akaratát és építi a fostengert. :)

Biztos nincs igazam, frusztrált is vagyok :D és amúgy is off.

Meg kell próbálni a managert meggyőzni: el kell tudni magyarázni a műszaki érveidet.
A hozzánemértő számára a "nincsenek érveid" és a "nem tudod elmagyarázni úgy hogy értsem" az ugyanaz.

Ha nem sikerül a meggyőzés akkor én általában leírom hogy mi a műszaki oka annak ha ellenzek egy megoldást.
Aztán ha összedől akkor van mire mutatni hogy "én szóltam". (és neki lehet állni megcsinálni jól)

Az fontos, hogy megmaradjon a viszony. Ha elküldöd a fenébe azzal hogy "hagyjál ez baromság" akkor elbuktad a viszonyt.
--
Gábriel Ákos

Nem értem miért lenne ez probléma vagy értelmetlen üzleti igény? De most nem az üzleti igény értelme a lényeg hanem hogy technikailag hogy lehet megvalósítani.
Mind a Facebook mind a Google mutatja milyen eszközökről vagy bejelentkezve és lehetőséget biztosít arra, hogy kijelentkeztess egy vagy akár minden eszközt.
Nekem pl. 3 eszköz van notebook, asztali gép és mobiltelefon amelyre be vagyok jelentkezve, és lehetőségem van bármelyiket kijelentkeztetni.
Kvázi ugyan ezt szeretném elérni azzal a különbséggel, hogy ha bejelentkezek egy új eszközre akkor a többit automatikusan jelentkeztesse ki.

Azon felül, hogy még mindig anti-pattern a dolog, fel kell tennem a kérdést, hogy milyen authenticator technológiát használsz, mert ugye ez nem a JSF réteg feladata, amit el szeretnél érni... és például kevered egy access token manuális visszavonásával azt, hogy egy user - egy session működésmódot szeretnél elérni egy erősen stateless környezetben egy erősen stateless protokollon át egy erősen stateless rendszerben.

Az ember előbb-utóbb megtanulja különféle kisebb-nagyobb szopások árán, hogy amire nincs általában megoldás a használt framework-ben, akkor az nem azért van, mert balfaszok tervezték...

--
https://iotguru.live

Belépsz, lekéred a sessionjeidet, tudod az aktuálisnak az id-ját, a többire meg meghívod a logout-ot.
Netbeans-ben nem fogod tudni összekattintani, programozni kell hozzá.

--
Gábriel Ákos

+1

Értelmes üzleti igény, nem nehéz megvalósítani és egyáltalán nem antipattern.

Erre azert nincs kesz megoldas, mert egyreszt ritkan lehet ra szukseg, masreszt trivialis megcsinalni.

Fapados megoldas: Az adatbazisban a felhasznalohoz bevezetsz egy uj oszlopot, ahol nyomonkoveted, hogy eppen be van-e jelentkezve.
Amikor valaki be akar jelntkezni, ranezel erre az oszlopra is es ha mar be van jelentkezve, az uj bejelentkezest egyszeruen visszautasitod.

Nem annyira fapados: Csinalsz egy ApplicationScoped bean-t ahol nyilvantartod, hogy ki van belepve a session-jevel egyutt. Minden belepeskor ranezel erre a listara, ha mar benne van az aktualis user, akkor a regi session-t invalidalod es eltarolod az uj sessiont. Ezzel a mar bentlevot kidobod, az ujat beengeded.

Az elsőt meg ne valósítsa senki! Nem is értem egyáltalán miért gondol valaki ilyenre. Egyes routereknél is találkoztam vele, hogy nem enged be mert már beragadt valahogy a session. Például be voltam jelentkezve egy gépről, aztán lemerült, átmentem másikra aztán jött a meglepi..

Inkább a második megoldás!

Az elso eppen ettol fapados. Ha nem jelentkezel ki, akkor meg kell varni a session timeout-ot, ami jo esetben nem fel ora...
Beragadni session nem tud java webapp-ban. Ha tudna, akkor az app server rovid idon belul felzabalna a memoriat.
Amugy routeren en is lattam ilyet, sot jartam is ugy, ahogy te.

Az ApplicationScoped dolgok hogy skálázódnak?

Esszel kell hasznalni, lehetoleg csak read-only modban, kulonben belassithatjak az oldalt sok felhasznalo eseten.

Ha spring alapu a project akkor van kesz megoldas, 3 sor az egesz:
https://javarevisited.blogspot.com/2018/07/spring-security-concurrent-session.html

Két sor addig, amíg kiderül, hogy klaszterezni is kellene :)

Azt nem tudom, mert amugy nem vagyok nagy spring fan.
De a feljebb javasolt ApplicationScoped bean-t egy sorral ki lehet terjeszteni az egesz clusterre.
https://blog.payara.fish/introduction-to-clustered-singleton

A random kulcsszavakra való Google kereséseken kívül próbáltad amúgy? Mert amit most linkeltél, az egy Glassfish fork és amúgy se tudod rátenni egy ApplicationScoped bean-re.

--
https://iotguru.live

Feltéve, hogy összesen egy node fut.

Ha meg van minimum kettő, ami azért illik legyen már manapság, akkor majd minden egyes node pontosan egy user-t enged be... persze, nyilván lehet fölé tenni valami elosztott cache vagy session replicator megoldást, aztán hozzáfércelni a meglévő rendszerekhez, de ez már ismét kókányolás, a rosszabbik fajtából.

Anti-pattern. Ha az embernek van egy kis szakmai gerince, akkor nem csinál ilyet.

--
https://iotguru.live

Ha az embernek van szakmai gerince, akkor nem csinal "modern" web-fejlesztestganyolast... az egesz paradigma a workaround workaroundjanak a workaroundjara epul. Gerinces ember ehhez (HTML+CSS+JS) hozza nem nyul.

Fasz stateless "best practice" is a http hianyossagaibol erdeztetheto.

Te miert akarsz bad-practice-t eroltetni masokra? Nativ (vekony) kliens + TCP/IP a megoldas.

Ezek szerint nem ismered a JEE clusteres működését.
Ott minden egyes node megkapja más node-ok sessionjeit, mindegyiknél ott van az összes, automatikusan replikálódik. Ehhez nem kell csinálni semmit, főleg nem kokányolni.
Ha invalidálsz egy session-t, akkor az automatikusan minden node-on invalidálódik.

A megoldás is roppant egyszerű. Amikor bejelentkezik a user, akkor megnézed az aktuális session-ök között, hogy van-e élő bejelentkezése másik gépről. Ha van, akkor arra a session-re hívsz egy invalidate -et. Ennyi.

"Ezek szerint nem ismered a JEE clusteres működését."

Hogyne ismerném. Pont ezért mondom, hogy ez így anti-pattern. A session replikáció ehhez ugyanis kevés.

"Ha invalidálsz egy session-t, akkor az automatikusan minden node-on invalidálódik."

Hogyne. Csak épp a hivatkozott Spring Security egyrészt rendszeridegen komponens JavaEE környezetben, másrészt a másik node másik session-t fog ismerni ugyanahhoz a felhasználóhoz.

"Amikor bejelentkezik a user, akkor megnézed az aktuális session-ök között, hogy van-e élő bejelentkezése másik gépről."

Azonos gépről nem lehet? Hol tárolod a felhasználók session-user összerendelését?

--
https://iotguru.live

"Rendszeridegen." :D

(szakszerű a kifejezés nem azért röhögök...)
--
Gábriel Ákos

Én úgy tudom, hogy nem replikálódik automatikusan, csak ha distributable minden webes node. Viszont ha nem distributed és pl van egy load balancer előtte sticky session configgal, akkor minden node külön kezeli a session-jeit.