Dotaz: Interakce webové aplikace s desktopovou

[fujunity]

Ahoj. Budu vytvářet webovou aplikaci v php pro nastavování uživatelských profilů tj. uživatel se přihlásí a potom může měnit nějaké nastavení. Chtěl bych ale vytvořit desktopovou aplikaci v javě, která by měla umět to samé. Neboť ta webová aplikace bude centrálním přístupem do nějaké složité struktury, tak je potřeba aby ta javovská aplikace komunikovala s tou webovskou. Otázka zní jak to realizovat? Posílat při každé akci dotazy typu get jako https://web.cz/aplikace/?user=uziv&pass=heslo&action=vypis_vlastnosti asi není zrovna dobrý nápad hlavně co se týče bezpečnosti.

Odpovědi

[Jendа]

SOAP?

[Filip Jirsák]

Můžete použít jinou metodu formátování dat, než HTML formuláře, to pak ale znamená na straně serveru mít dva různé způsoby získávání dat z požadavku. Z hlediska bezpečnosti je úplně jedno, zda budou parametry v URL dotazu, jako formulářová data v těle dotazu, nebo v těle dotazu jako SOAP zpráva, vaše vlastní XML nebo JSON. Každopádně nevím, co vám na tom připadá nebezpečného – je to úplně stejné, jako byste to posílal z prohlížeče, a pro běžné použití je správně použité HTTPS dostačující.

[fujunity]

Každopádně nevím, co vám na tom připadá nebezpečného – je to úplně stejné, jako byste to posílal z prohlížeče, a pro běžné použití je správně použité HTTPS dostačující.

To rozhodně není. Pokud se přihlásím do web aplikace, tak se heslo pošle jen jednou a potom mě zajímá jen SESSION ID které je uložené v cookies prohlížeče a nějaký "příznak" logged v sessions na serveru. Takto bych musel při každém požadavku odesílat znovu heslo a to je to co mi tam vadí.

[Filip Jirsák]

Vždyť to posíláte přes HTTPS. Mimochodem, posílat z prohlížeče s každým požadavkem jméno a hash hesla (např. HTTP DIGEST autentizace) je nesrovnatelně bezpečnější, než posílat session ID. Hash hesla můžete bezpečně posílat i přes nešifrované HTTP… Heslo z bezpečného prohlížeče rozumně vymámit nelze, k získání session ID je naopak mnoho prostředků, některým se lze bránit, některým ne (třeba odposlech na síti – samozřejmě v případě nešifrované komunikace). Dokonce i posílání nehashovaného hesla (HTTP BASIC) nešifrovanoukomunikací je bezpečnější, ež session ID – možnost odposlechu je sice stejná, ale z prohlížeče to heslo jiným způsobem nedostanete, session ID se ale pořád můžete pokusit získat různými způsoby.

[Sten]

Doporučuji udělat ty aplikace dvě — backend, který dostane, co má udělat, a udělá to (třeba přes JSON; kdyby to nebylo PHP, doporučil bych SCGI + JSON-RPC), a frontend, který to vykreslí pro uživatele (HTML formuláře) a veškeré operace odešle backendu. Java aplikace potom bude komunikovat přímo s backendem (vlastně to bude alternativní frontend). Komunikace mezi serverem a klientem by samozřejmě měla být šifrovaná.