[Javalist] WebStart JNLP API

2013. Feb. 5., K, 12:42:57 CET

Koszonom a tippet! Majdnem mukodott. Harom klikk a glassfish admin
feluleten, es mar meg is van a virtualis szerver:
webstart.mydomain.hu.

Es valoban igy mar nem irja folul a jnlp kliens a header-emet.
Egeszen addig a pillanatig, amig a user egyszer el nem rontja az
azonositast pl egy rossz password megadasaval. Ekkor a server visszaad
egy 401-es kodot, es azt mar azonnal elkapja a jnlp, es innentol
kezdve borul az egesz. Ha ekkor a user megad a jnlp-nek egy un/pw
parost, (pl "a" user "b" password) akkor a kovetkezo elrontott
bejelentkezes alkalmaval ez a paros megy a servernek, azaz ha user be
akar jelentkezni "c" userkent "d" passworddel, de ez a password nem
okes "c" usernek, akkor a belepteti a rendszer a korabban megadott a/b
parossal. Ez pedig nagyon gaz. :(
(egyebkent egy ilyen elrontott bejelentkezes utan is mukodik a
bejelentekezes megfeleloen, ha a user nem rontja el a un/pw parost,
azaz szepen lehet felhasznalot valtani)

Szoval ugy tunik ez a dolog sehogy sem megy. Azert ez eleg meglepo.
Hiszen semmi extra dolgot nem akartam csinalni.

Istvan Verhas <istvan at verhas.com> írta (2013. február 5. 8:11):
> Miért kell ugyanazon a host-on lennie a jar-oknak és a webapp-nak? Legalább
> virtualhost szinten legyenek szétválasztva és akkor nem fogja felülírni a
> headert. Ehhez elég két dns bejegyzés ugyanarra az ip címre.
> udv
> vi
>
> Sent from viPhone
>
> On 2013.02.05., at 0:24, Zsombor <gzsombor at gmail.com> wrote:
>
>  Ez a http protokol, és ezen belül ez a basic authentikáció. Ha az adott
> host:port párhoz fordul egy alkalmazás, akkor a korábban ledobott cookiekat
> kell prezentálnia - ami ez esetben mellékes, valamint ha korábban volt, hogy
> "Auth fail" üzenettel és egy "Realm" névvel jött vissza egy http lekérés,
> ami után sikerült authentikálnia, akkor mindig kell küldenie az user/pw
> párost, minden egyes requesttel - az adott szerver felé. S ezért kell
> beleirogatni a request-be, hogy ne hogy kimaradjon belőle - s hogy ezt kvázi
> transzparens módon lekezelje feléd, mintha nem is lenne semmilyen
> authentikáció. Ez az egész a java.net.URLConnection és a hozzá kapcsolódó
> http kliens műve. Nyilván, ha Te mondjuk az apache HttpClient-et használnád,
> az nem tudna az egész realm/cookie/stb beállításaidról ... Persze az meg más
> problémákhoz vezetne.
>
> Zs
>
>
> 2013/2/4 Zoltán Bernát <bernatzoltan at gmail.com>
>>
>> Igen ezt a problemat ismerem, sajnos, mert a klienskod letolteset
>> lehetove tevo web oldal eleresehez is http-basic-kel kell azonositani
>> a webbongeszoben. Ott megoldottam a dolgot egy, meg elfogadtaho
>> szinten.
>> De itt azert ha jol "erzem" a dolgot, meg bosszantobb a helyzet,
>> illetve talan egy kicsi (vagy nagyon) masrol is van szo. Igazabol nem
>> ertem, mi a turo koze van a jnlp kliensek az en alkalmazasom altal
>> kuldott http keresekhez. Nehogy mar ne kuldhessek olyan headert,
>> amilyet akarok! Az alkalmazasom mas serverekhez is fordulhatna http
>> keresekkel, ezek headerjet is modositgatna a jnlp? Vagy ugy
>> viselkedne, mint egy web bongeszo, es csak a codbase serverhez
>> intezett keresek headerjebe irogat bele? Es mi ertelme van
>> beleirogatni? Tehat mi szuksege van erre a jnlp-nek??? Mert a jar
>> file-ok letoltesehez persze beleir a headerbe. Ez rendben is van,
>> hoszen szol neki a webserver, hogy http-basic auth kell.
>> Es programom egyeb protokollokal is kommunikalhatna a serverrel, akar
>> olyan protokollal, amit nem is ismer a jnlp. Akkor abba hogyan
>> piszkalna bele? Teljesen erthetetlen szamomra ez a dolog. Ebbol meg az
>> kovetkezik,  hogy valamit nagyon felreertek a rendszer
>> feladataval/mukodesevel kapcsolatban.
>>
>> Zsombor <gzsombor at gmail.com> írta (2013. február 4. 23:32):
>> > Jah, érthető. Sajnos ez a "hogyan logoljunk ki http-basic-auth-ot
>> > használó
>> > webalkalmazások"-ból kérdés/szívás problémája:
>> >
>> >
>> > http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
>> >
>> >
>> > Hát, nem túl rózsás a helyzet.
>> >
>> > üdv
>> >
>> >  Zs
>> >
>> > 2013/2/4 Zoltán Bernát <bernatzoltan at gmail.com>
>> >>
>> >> Tulajdonkeppen nem kell ketszer.
>> >>
>> >> A felhasznalo, a kliensprogram telepitesekor csak egyszer kell, hogy
>> >> megadja  a jelszavat. A javaws lehetoseget ad arra, (mint egy web
>> >> bongeszo,) hogy a usernek ne kelljen ezt a jelszot tobbet megadnia.
>> >> Tehat ezt a jelszot tobbet nem keri a rendszer azt a javaws
>> >> "megjegyzi", ha ezt a user igy akarja. A user kattint a desktopjan
>> >> levo ikonon (amit a jnlp kliens telepitett) es mar indul is a
>> >> programom. (nyilvan a jnlp kliens, a progi inditasa elott megnezi,
>> >> hogy a szerveren levo jar file-ok last modified erteke ujabb-e, mint a
>> >> kliensnel levokenek. Ehhez a persze el kell ernie a szerveren a vedett
>> >> mappaban levo jar-okat, ehhez pedig folhasznalja a telepiteskor, elso
>> >> alkalommal bekert jelszot)
>> >>
>> >> Tehat elindul az en alkalmazasom, es csak az o szamara kell bepotyogni
>> >> minden alkalommal a un/pw parost. Raadasul a usernek tobb accountja is
>> >> lehet a serveren. (mint ahogyan van is) De hiaba adja meg pl. a
>> >> masodik fiokjanak un/pw parosat, ha az alkalmazas installalasakor a
>> >> jnlp-nek az elso fiokjanak az un/pw parosat adta meg, soha nem tudja
>> >> mar elerni a masodik fiokjat.
>> >>
>> >>
>> >>
>> >> Zsombor <gzsombor at gmail.com> írta (2013. február 4. 21:31):
>> >> > Hali !
>> >> >
>> >> >
>> >> >  Miért baj, hogy nem kell kétszer authentikálni? Felhasználóként
>> >> > kifejezetten zavarna, ha kétszer kellene beírnom a jelszavamat ...
>> >> >
>> >> >
>> >> > Zs
>> >> >
>> >> > 2013/2/4 Zoltán Bernát <bernatzoltan at gmail.com>
>> >> >>
>> >> >> Sziasztok!
>> >> >>
>> >> >> Van egy vastagkliens alkalmazasom, ami web service-szel kommunikal
>> >> >> egy
>> >> >> glassfish szerverrel.
>> >> >> Szeretnem megoldani a kliens kod Web Startos terjeszteset.
>> >> >> A szerveren egy konyvtarban vannak a kliens kod jar faljai es a jnlp
>> >> >> leiro file is.
>> >> >> Ezt a konyvtarat a webkontener vedi, HTTP BASIC authentikacioval
>> >> >> lehet
>> >> >> hozzaferni. (persze https folott). Azaz nem akarom,  hogy barki
>> >> >> hozzaferjen a klien kodhoz.
>> >> >> web.xml: <auth-method>BASIC</auth-method>
>> >> >> (probalkoztam a <auth-method>FORM</auth-method> megvalositassal is,
>> >> >> sajnos sikertelenul)
>> >> >>
>> >> >> Ilyenkor persze a jnlp kliens nem fer hozza kapasbol a jar
>> >> >> file-okhoz,
>> >> >> ezert foldob a usernek egy ablakot, ahol megadhatja a
>> >> >> username/password parost.
>> >> >> Ennek megadas utan lehuzza az alkalmazast, es mar fut is a kliens
>> >> >> gepen.
>> >> >>
>> >> >> A kliens programom is HTTP basic auth. segitsegevel eri el a web
>> >> >> service-eket.
>> >> >> Indulasakor bekeri a usertol a felhasznalo nevet es a jelszot.
>> >> >> Ezutan minden serverhez inditott keres http headerjebe beirja az
>> >> >> authotization elembe ezt a username/passsword ertekeket, es a
>> >> >> webkontener  ezen ertekekre autentikal. A problema ott van, hogy a
>> >> >> user gepen futo jnlp klines(javaws.exe) a szepen felulirja a
>> >> >> programom
>> >> >> altal a http headerbe irt authotization ertekeket, azzal a
>> >> >> username/password parossal, amit a user akkor adott meg neki, amikor
>> >> >> a
>> >> >> jnlp kliens kerte tole, hogy azzal lehuzhassa a jar file-okat a
>> >> >> server
>> >> >> vedett konyvtarabol.
>> >> >>
>> >> >> Igy viszont ugyebar tok mindegy milyen un/pw parost ad meg a user, a
>> >> >> jnlp kliens a sajat valtozatat kuldi a servernek. (persze ha a
>> >> >> fejlesztokornyezetbol futtaom a kliens kodot, akkor minden
>> >> >> megfeleloen
>> >> >> mukodik)
>> >> >>
>> >> >> Bogarasztam a JNLP API-t, de nem talaltam olyat, amivel ravehetnem a
>> >> >> jnlp klienst, hogy ne irja bele minden keres fejebe a sajat
>> >> >> authorization erteket.
>> >> >> Van v.kinek otlete, hogy lehet ebbol kikeveredni?
>> >> >> Koszi.
>> >> >> _______________________________________________
>> >> >> Javalist mailing list
>> >> >> Javalist at lists.javaforum.hu
>> >> >> http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Javalist mailing list
>> >> > Javalist at lists.javaforum.hu
>> >> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >> >
>> >> _______________________________________________
>> >> Javalist mailing list
>> >> Javalist at lists.javaforum.hu
>> >> http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>> >
>> >
>> > _______________________________________________
>> > Javalist mailing list
>> > Javalist at lists.javaforum.hu
>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>> >
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>