[Javalist] WebStart JNLP API

Gábor Garami gabor.garami at hron.me
2013. Feb. 5., K, 13:45:19 CET


Nezd, a http auth mindenkepp nyugos, ha nem https felett authentikalsz,
mert gyak cleartext (oke, base64) megy a user/pass.

Ezen felul - amint az kiderult - a http auth-ra mindenki szeret
ratelepedni, a load balancernek hasznalt webszerverektol kezdve a javaws-on
at sokminden masig.

En oszinten szolva nem szeretem, mert ugy erzem: latszolagos vedelmet ad
csupan, illetve mert iszonyatosan megkoti a kezem. Egy formos
authentikacioba tudok gombot tenni az elfelejtett jelszo esetere, a
kitiltott usernek mas hibat tudok visszaadni adott esetben, meg ugy az
egesz sokkal kevesbe kotott.

Nagyon sokat szivok/szivtam mar http authtal, igy talan ertheto, hogy
averzioim vannak vele szemben.

Garami Gábor
gabor.garami at hron.me
Skype: hron84
Tel: +36 20 235 9621

Sent from my T-Mobile G2
Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.
2013.02.05. 12:51, "Zoltán Bernát" <bernatzoltan at gmail.com> ezt írta:

> Gabor! Ez a megoldas nagyon santit. Sehogy nem lehet osszehozni e ket
> dolgot. (file path-t hasznalni passwordkent) Mi van akkor, ha egy
> usert ki akarok tiltani a rendszerbol. Azaz nem akarom, hogy
> hozzaferjen a tovabbiakban az adott konyvtarhoz. Megvaltoztatom a
> konyvtar nevet, hatha azt nem talalja ki? Es a tobbi usernek meg
> szolok egyenkent, hogy telepitsek ujra a desktop alkalmazasukat, es
> mindegyiknek meguzenem az uj konyvtar nevet is? Ez nagyon gaz, nem?
>
> Mi a bajod a http-basic auth-tal? Kifejtened nekem? Ez ha nem
> webbongeszo klienst es nem jnlp klienst hasznalok, ngyon is megfelelo
> nekem.
>
> Alapbol az en kliens alkalmazasom egy sima swinges desktop kod. Ott
> rontottam el a dolgot, hogy abban biztam, hogy siman tudom majd
> hasznalni a Werb Start rendszert. Hat nem tudom. :(
>
> Gábor Garami <gabor.garami at hron.me> írta (2013. február 5. 12:26):
> > Azert egy fajlnevet nem olyan trivialis kitalalni, mint egy jelszot,
> > mert az nem onkenyesen valasztott, hanem bizony generalt, tehat nem
> > lehet szotari hokuszpokusszal elni.
> >
> > Viszont jelen esetben az egyik legjobb megoldas lenne. Persze, nem
> > ismerem a felhasznalasi korulmenyeket (intranet? hanyan hasznaljak?)
> > igy nehez okosakat mondani, de mivel jelenleg pont az a problemank,
> > hogy ha authentikaljuk a jart, akkor rossz lesz az authentikacio, igy
> > ez egyfajta megoldas lehet.
> >
> > Egyebkent lehet ez ideiglenes megoldas is, amig peldaul egy, a HTTP
> > auth-tol kicsit ertelmesebb authentikaciot tesztek az alkalmazasba.
> >
> > Garami Gábor
> > E-mail: gabor.garami at hron.me
> > Tel: +36 20 235 9621
> > MSN: hrgy at vipmail.hu
> > Skype: hron84
> >
> >
> > 2013/2/5 Zoltán Bernát <bernatzoltan at gmail.com>:
> >> Haaat!
> >> Azert ez nem igy mukodik. Nem ugy vedek egy file-t, hogy olyan helyre
> >> teszem, hogy "ne talaljak meg".
> >> Szoval ilyen dolog nem jatszik, hogy "eldugom a filerendszerben" es
> >> bizom benne, hogy nem talaljak meg a kenyes allomanyokat, azaz
> >> tulajdonkeppen a file eleresi utvonalat tekintem passwordnek. Ha azt
> >> valaki kitalalja, ove a jar.
> >> A file-okat passwordokkel kell vedeni. A jar file-jaimat egy
> >> passworddel vedett konyvtarba tettem. (a webkontener vedi, tehat
> >> nyilvan nem a linux)
> >>
> >>
> >> Gábor Garami <gabor.garami at hron.me> írta (2013. február 5. 10:48):
> >>> A dolog forditott: ha a jar nincs linkelve sehol, a JNLP nelkul ember
> >>> meg nem talalja.
> >>>
> >>> Pont ezert kell a JNLP-t vedeni, mert az alapjan felderitheto az egesz
> >>> bagazs. A jar meg legyen eldugva a fajlrendszerben, es ne mutasson ra
> >>> link. Senki nem fogja tudni, hogy ott van.
> >>>
> >>> Garami Gábor
> >>> E-mail: gabor.garami at hron.me
> >>> Tel: +36 20 235 9621
> >>> MSN: hrgy at vipmail.hu
> >>> Skype: hron84
> >>>
> >>>
> >>> 2013/2/5 Zoltán Bernát <bernatzoltan at gmail.com>:
> >>>> Dehat a jar file-okat kell vedeni nem a jnlp-t. A jnlp az csak egy kis
> >>>> xml file. A kutyat nem erdekli, ha olyanhoz is eljut, akinek nem
> >>>> szanom. A jar-okat meg nem adhatom authentikacio nelkul. Pont azokat
> >>>> akaorm vedeni.
> >>>> Egyebkent meg azert lett http basic, mert a form (tehat a wenkontener
> >>>> altal managelt form) autentikaciot nem sikerul osszehoznom a jnlp
> >>>> klienssel. Tehat a jnlp kliens tud mit kezdeni egy  401-es http
> >>>> koddal. (HTTP/1.1 401 Access Denied)
> >>>> Foldob a usernek egy ablakot, mint egy webbrowser.
> >>>> Viszont a form auth. ha jol emlekszem 301-es http koddal operal. Azaz
> >>>> atiranyitja a kerest. (arra  login,jsp-re,amit beallitottam a
> >>>> telepitesleiroban) Ezt viszont a jnlp nem eszi meg. Tehat nyilvan nem
> >>>> tud mit kezdeni az atiranyitott oldaltol kapott html-lel.
> >>>> Nem fogja kitolteni a user helyett a form-ot. :)
> >>>>
> >>>>
> >>>> Gábor Garami <gabor.garami at hron.me> írta (2013. február 4. 23:32):
> >>>>> Egy kerdes: miert van a kliens letoltes HTTP auth-tal vedve?
> >>>>>
> >>>>> Vedjuk csak a JNLP-t, de ne http authtal, hanem valami rendes kis
> >>>>> formmal, ami beauthentikal, majd felkinalja a jnlp linkjet, amit az
> >>>>> app maga szolgal ki (erre a reszere egy kis szervlet tokeletesen eleg
> >>>>> lehet), ezutan a jnlp a megfelelo jarokat mar authentikacio nelkul
> >>>>> vinne. Gondolom a JNLP-t mar nem toltogeti le allandoan a javaws, ha
> >>>>> megis, az nyug...
> >>>>>
> >>>>> Garami Gábor
> >>>>> E-mail: gabor.garami at hron.me
> >>>>> Tel: +36 20 235 9621
> >>>>> MSN: hrgy at vipmail.hu
> >>>>> Skype: hron84
> >>>>>
> >>>>>
> >>>>> 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
> > _______________________________________________
> > 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
>
--------- következ? rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130205/955536b6/attachment.html>


További információk a(z) Javalist levelezőlistáról