ODK Collect - připojení k ODK Aggregate - SSL protocol error #235
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#235
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Zkoušel jsem z Androidu a aplikace ODK Collect připojit se k serveru. Zatim se nedařilo zobrazit cokoliv že se spojil se serverem a vyskakovaly chybová okna jako toto:
Taky jsem usiloval o něco podobného i s appkou GeoODK collect, ale taky se nedařilo.
Vzhledem k okolnostem však nemohu zcela přesně formulovat problém, aby se dal zopakovat.
Moje testy přes Android jsou hrozně otravné peklo. (pomalý tablet, mizerný internet, router který odpojuje wifi, mizerné světelné podmínky a jiné záludnosti. Běžně tak doma simuluji takovou krizovou událost, ještě bych mohl vytopit sklep nebo zapálit dům a bude to komplet :)
Pokud se vám podaří ověřit, že klient komunikuje se serverem, tak super, já se k tomu postupně prokoušu.
Pro kontrolu jsem zkoušel připojení z iOS s Ushahidi Mobile, tak tam klient se serverem komunikuje.
(jasně, vim že to je zcela jiná věc a jinak navržená appka, ale neměl jsem jinou možnost jak ověřovat žijící server.)
Správná adresa - http://dasm.dasm.cz:8815/aggregate - je uvedena na dlaždici ODK Collect na vstupní straně.
HTTPS nebude fungovat v drtivé většině aplikací, protože máme selfsigned certifikát.
closed
Ha, zkusil jsem a máte samozřejmě pravdu, funguje to.
URL jsem lovil na mobilu a pak přepsal ručně, ono taky používat na téhle parodii tabletu copy+paste je komplikovaný porod.
až budu řešit design vstupní strany, tak to bude muset být o kapku víc friendly pro špatně vidící spoluobčany :)
No ono by možná stálo za úvahu, jestli nepřehodnotit, jak vlastně má být celá VM deploynuta, protože tenhle systém, kdy máme HTTPS jen někde a někdy a máme aplikace rozházené po různých portech, je celkem na prd.
Ideální případ by byl použít nějakou skutečnou doménu, aplikace nastrkat na její subdomény a k těm requestovat Let's encrypt certifikáty. Pak bychom prostě měli https://odk.spotter.xx nebo https://odk.nejaka-ngo.cz, všude by mohlo být pouze HTTPS, takže by uživatel nemusel zjišťovat, který že to protokol má použít a doménový název je také o poznání lépe zapamatovatelný něž nějaké hauznumero následované dvojtečkou a dalším kratším hauznumerem. Také bychom eliminovali problém s průchodností portů přes některé přehnaně restriktivní firewally. Ale v takovém případě by skutečně muselo být zajištěno, že VM poběží na adrese, která je dostupná z internetu a bude mít platné DNS záznamy.
Technologicky schůdnou alternativou by pak bylo naopak HTTPS nepoužívat vůbec a všude použít plain HTTP, čímž by se eliminovalo alespoň zmatení protokolů. Nicméně posílat osobní údaje z nějakého knihovního hotspotu nešifrovaně je recept na katastrofu. Bohužel plain HTTP musí být u mobilních aplikací použito stejně, protože selfsigned certifikáty nežerou a neexistuje jednoduchý univerzální způsob, jak je k tomu donutit.
Jasné, díky za návrh. Poladit domény určitě dává smysl , jen nejdřív rozmyslet jak.
Co se týče subdomén, tak bych byl zatím ještě opatrný, výběr aplikací není definitivní. jsme stále v příliš ranné fázi, kde přežiju i nepohodlí a omyly.
Pro funkční úpravu vstupní strany si plánuji úlohy pro kodera, chtěl bych oddělit vstupní stranu pro uživatele a pro admina.
Napadlo mne co by mohlo vylepšit přístup k VM:
Samotná Úvodní strana (s nějakým easy setupem) by mohla být na mém hostingu a doméně.
Kde by byly nakonfigurovány redirecty vedoucí na neveřejnou IP běžící VM, SW by zůstal na VM jak je.
Tohle by asi muselo být nějak mazaně udělané, v setupu strany a já nevím co ještě.. (doufám že zde není nějaký principielní problém?) Při spuštěné VM, nastavit IP a počkat až se přepíší záznamy v DNS?
Zatím zkusme ještě chvíli pracovat na VM, kde sice bude ukrutné trápení s URL, HTTP HTTPS, SSL i s jinými okolnostmi, ale bude to stále pokus o přenositelnou VM.
Je to možná cesta jak zjednodušit URL?
Pro admina rozhodně oddělené rozhraní bude potřeba. Už jen proto, že se skrze něj budou nastavovat různé konfigurační parametry předávané aplikacím a taky updatovat kontejnery.
Zjednodušení přístupu nerozumím. Certifikát se ověřuje při každém připojení klienta k serveru. Takže jediný případ, kdy by něco takového mohlo fungovat by bylo, kdyby váš server na forpsi fungoval jako proxy a zároveň nejspíše i jako VPN server, ke kterému by se VM připojila jako klient. Všechny požadavky by pak šly přes něj, což by nebylo ani rychlé, ani přenositelné.
Flow HTTPS požadavku z pohledu klienta je:
A pokud se bavíme o certifikátech Let's Encrypt, tak tam žádosti o certifikáty a recertifikaci fungují z pohledu HTTPS serveru následovně:
Některé části je možno dělat trochu jiným (složitějším) způsobem anebo je dělat ručně, ale Let's Encrypt certifikát je takto nutno obnovit každé tři měsíce. Nicméně právě tohle jsou důvody, proč HTTPS server musí být alespoň občas dostupný z internetu (aby se certifikát vůbec dal získat a obnovit) a proč nějaké čarování s redirecty ovoce nejspíš nepřinese (neposkládá se chain of trust).
Zásadní problém vidím v tom, že bereme aplikace, které jsou od začátku do konce navrženy pro bezpečný provoz na serveru a cpeme je na VM, která nemá ani pevně danou adresu, ani FQDN, ani není součástí nějaké infrastruktury. Spíše než "přenositelnou" bych se pokoušel o "instalovatelnou" - tj. nebude s ní možno běhat po lesích a bude nutno na ní udělat nějaké poinstalační nastavení k tomu, aby se dala plnohodnotně používat. Dokud se k ní nezačneme chovat jako k serveru, nebude nám fungovat HTTPS, nebudou nám chodit maily, nebude nám fungovat OAuth (Google, Facebook, Humanitarian ID) a dost možná se k ní z některých míst nebude dát ani připojit, protože používáme nestandardní porty.
Aha, ok... snad jsem to v principu pochopil.
řekněme že tedy půjdeme cestou instalovatelnosti... znamená to teď nějakou velkou změnu do stávajícího stavu? Poinstalační setup mi nevadí, s tím se dá počítat. Obnova certifikátu - to se dá taky zvládnout.
Jo a ještě na cookies jsem zapomněl. Ty mají taky zásadní problém s tím, že všechny aplikace jedou na stejné adrese a liší se jen porty, protože cookies porty nerozlišují. To je například důvod, proč když se přihlásíte do Sahany a pak ještě do SAMBRO, ze Sahany vás to zase vykopne.
Velkou, ve smyslu "složitou a zdlouhavou" ne. Nicméně nějaké překopáníčko bude potřeba. Podobně jako u Dockerizace od toho očekávám usnadnění vývoje i následné práce s jednotlivými aplikacemi. Zrovna třeba u toho ODK Aggregate, kde to se všemi těmi proxynami a redirecty bylo na posrání, myslím, že pomocí FQDN a vynucení validního HTTPS budu schopen všechny ty podivné workaroundy úplně eliminovat. Jediné, co se zásadně změní, budou požadavky na to, kde VM bude moct být nainstalována a provozována.
Ok, vše co píšete mi připadá rozumné. Přiznávám, že tyhle detaily znám jen z uživatelského hlediska. Jsem rád, že nad tím takto přemýšlíte.
Takže ano, představuji si z toho, že výsledek snažení bude adminem "plynule" nainstalovatelný balík SW, nakonfigurovatelný na jím určenou destinaci, tj server. Konfigurací si nastaví a zabezpečí prostředí a bude mít po ruce vše co v základu potřebuje.
Kdyby se rozhodl nainstalovat na desktop HW, tak to bude možné? (například na samostatný diskový oddíl?)
Můžu od toho čekat že připravíte instalační diskovou image, kde nebudou živé SW, ale budou tam všechny zdroje k určitému datu tak, aby ta instalace mohla proběhnout i bez internetu? (a později s internetem možnost updatovat nové verze)
S tím bych neměl problém.
Je to pořád virtuálka. Pokud má desktop HW dostatek systémových prostředků a funguje na něm nějaký hypervizor, tak to pojede. Jediný problém, se kterým se dotyčný bude muset poprat je zase jen networking. Ten se jakožto externí závislost programově nijak nastavit nedá. Ten se dá jen vydatně zdokumentovat.
Přesně obráceně. Na virtuálce budou Docker image s živými SW (resp. spinkajícími, čekajícími na
polibek z pravé láskyaktivaci z administrátorského rozhraní) sestavené k určitému datu. Distribuce zdrojů by zabírala daleko více místa a museli bychom k ní distribuovat i všechny build skripty. Navíc sestavení samotné sežere další hromadu času a systémových prostředků. To byl další z důvodů, proč jsme aplikace nakontejnerovali. Chceš aplikaci? Pusť si kontejner. Nechceš aplikaci? Zastav kontejner. Chceš update? Stáhni si image ze Spotterova webu a kontejner pak restartuj.Aktualizované image pak mohou být distribuovány na web kýmkoliv, kdo bude disponovat přístupem pro zápis, zdroji (resp. přístupem na GitHub a jiné internety) a build skripty k jejich sestavení. To budu v počátku já a až se vzájemně nasereme, může to být kdokoliv jiný.
ok, zatím mi to připadá jako dobrý návrh. Jaký tedy bude nejbližší postup?
Mam udělat něco ohledně domén?
Není třeba. Už jsem udělal. Nacpu vám dostupnou testovací VM na svou subdoménu. Tam můžu rozbíjet, žádat certifikáty a testovat dle libosti. Hlavní strana bude tedy dostupná na https://spotter.dasm.cz, Sahana na https://eden.spotter.dasm.cz a tak dále. Až si dohraju, dám vědět.
ok