Stratený checkbox

28.11.2011 19:36 | Přečteno: 1378× | Linux | poslední úprava: 28.11.2011 23:19

Zasa som sa raz snažil dopátrať, ako veci fungujú. Tentokrát ukladanie niektorých hesiel v Jave. Pristupujem k Lotus Notes serveru cez webový interface. Takýto prístup je chránený heslom a webová stránka Lotusov používa nejaký java applet. Z toho dôvodu pri pokuse o nahratie toho appletu na obrazovke objaví takéto okno:

A teraz záhada: kedysi v tom okne bol checkbox "Remember password". Teraz tam nie je. Navyše na jednom stroji mám polia "User name" a "Password" pred-vyplnené; na druhom sú prázdne. Nedávno ma to dožralo a pustil som sa pátrať po tom, kam sa mi checkbox stratil.

Dopátral som sa k tomu, že kód zodpovedný za zobrazenie toho dialogu je v deploy.jar, ktorý je súčasťou JRE a na linuxe ho mám v /usr/lib/java/jre/lib/deploy.jar. Tento jar obsahuje niekoľko tried, ktoré nie sú súčasťou Java API. Napríklad je v ňom UIFactory, ktorá má metódu showPasswordDialog(...) a tá má parameter saveEnabled. No a keď v ňom príde true, tak checkbox bude a inak nebude. Neviem sa spoľahlivo dopátrať k tomu, odkiaľ je tá metóda volaná. Ale stiahol som si zdrojáky javy a v nich som hľadal volania showPasswordDialog(...). Väčšina z nich natvrdo posiela saveEnabled=false, ale DeployAuthenticator obsahuje:

isEncryptionEnabled = getCredentialManager().isPasswordEncryptionSupported();
...
info = UIFactory.showPasswordDialog(parentComponent == null ? null : parentComponent.get(),
                    getMessage("password.dialog.title"),
                    details, true, isDomainNeeded, cred,
                    isEncryptionEnabled, authDisplayString );

a mám pocit, že práve táto trieda je zavolaná v tom mojom prípade. Metóda getCredentialManager() vracia objekt triedy CredentialManager. A v nej je natvrdo napísané,

protected boolean isPasswordEncryptionSupported() {
        // not available in base class
        return false;
    }

Z toho vyplýva, že pokiaľ niekto z tej triedy nezdedí na nenapíše vlastnú implementáciu, tak sa heslá ukladať nebudú. No a kto dedí z CredentialManager? Na moje prekvapenie MSCredentialManager, kde to MS na začiatku znamená samozrejme Microsoft. V tejto triede je natívna trieda, ktorá sa pokúsi loadnúť Crypt32.dll atď, atď.

Zaujímavé na tom je, že akosi neexistuje ekvivalentná linuxová implementácia. To ma tak zarazilo, že som zabudol pátrať po tom, od čoho závisí pred-vyplnenie políčok s prihlasovacím menom a heslom.

Mno, tak to by sme mali. Pokiaľ by sa niekomu chcelo overiť moje zistenia, nejak ich okomentovať alebo nebodaj navrhnúť ako dotiahnuť Oracle k pridaniu Linuxovej implementácie, bol by som rád.        

Komentáře

[Luboš Doležel (Doli)]

Mě nejvíc štve to, že si Java nevezme přihlašovací údaje od prohlížeče. Takže pokud jdete na web chráněný HTTP autentizací, musíte to zadávat dvakrát.

[bambas]

Jeste aby to delala, to by bylo pekne zverstvo. No FUJ!

[rastos]

Mnoo ... nie je to márna myšlienka. Veď povolenie/zakázanie takej funkcionality možno nechať na rozhodnutí užívateľa. A dokonca v tomto smere tuším existuje aj nejaký kód: MozillaBrowserService a MozillaPlugin.UnixHandler. Myslím, že by to bolo celkom zaujímavé, keby to celé dohromady fungovalo.

[CET]

Ja to teda nepouzivam, ale Gnome ma nejakej Security Store nebo tak nejak. Ani tam se to neulozi?

[rastos]

To asi silne závisí od toho aký browser človek používa, akým spôsobom ten browser zavolá javu na obsluhu appletu a akú javu vlastne použije. V mojom prípade je to FF a Sun/Oracle java 6u26 v KDE. Ono mne ani nejde tak o vyriešenie ukladania hesiel, ale o to, že linuxová implementácia javy niečo mala a teraz už nemá.

Mimochodom, tie heslá sa fyzicky asi ukladajú do ~/.java/deployment/security/auth.dat. Iste by sa dala napísať javovská trieda, ktorá by to integrovala s KDE Wallet, Gnome keyring, alebo trebárs Password Safe. Ale je to oštara. Java na Linuxe šifrovať vie, tak prečo by mala mať menšiu funkcionalitu, ako na Windowsoch?

[Xerces]

No mě spíš zaráží, že rozmázneš jméno, ale to že máš heslo 10 teček ti zveřejnit nevadí.