[Javalist] WebStart JNLP API

Zoltán Bernát bernatzoltan at gmail.com
2013. Feb. 5., K, 17:11:21 CET


Na igen, de en pont https folott teszem. Ha nem https folott csinalom,
akkor meg, ha nem HTTP-BASIC, akkor is nyugos, nem?

Es mint mondtam nekem egy swinges kliensem van, azaz amikor megkapom a
szervertol a 401-es http kodot, akkor olyan formot dobok fol a
usernek, amilyet akarok, kitiltott user, elfelejtett jelszo, stb.
Ennel elegansabb es egyszerubb megoldas, mint a HTTP-basic nekem nem
letezik. A kliensek a http basic csupan annyit jelent, hogy headerben
kuldheti a un/pw-t (transparencia miatt nagyon ok) es hogy 401-es
kodot kap vissza, ha nem ok az azonositas.

A javaws aztan boritja az egesz rendszeremet. No! csak azert
vitatkozom veled, mert ha meggyozol, hogy vacak a basic, akkor en meg
kenytelen leszek atirni a kodot.

Arra gondoltam, hogy mi lenne, ha a server nem 401-es status kodot
kuldene vissza, hanem egy custom erteket (ha jol tudom peldaul 460
korul vannak sajat hasznalatre igenybe veheto kodok).

Esetleg lenne valakinek tippje, hogy ezt hogyan lehetne megoldani?
Ugyebar a filter nem ok, mert a filter meghivasa elott autentikal a
webkontener, azaz a filterig el sem jut a request, ha nem ok az un/pw.


Gábor Garami <gabor.garami at hron.me> írta (2013. február 5. 13:45):
> 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
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>


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