Dotaz: eObčanka a protokol czeeopauth pod KDE

[Luboš Doležel (Doli)]

Ahoj,

snažím se rozchodit eObčanku a první otravný problém je handler protokolu czeeopauth při přihlašování.

V /usr/share/applications/eopauthapp.desktop mám asociaci dle očekávání, ale problém je, že jakmile browser chce otevřít URL např. czeeopauth://mwid=767aae75-d431-4680-9f1f-363a9341b400, tak xdg-open nakonec zkusí otevřít toto URL v Chromu (mém výchozím prohlížeči).

Je to ovšem celé o dost zapeklitější. Ověřil jsem, že xdg-open používá kde-open5, a to se chová následovně:

• czeeopauth://mwid=767aae75 -> zkusí spustit prohlížeč (chyba)
• czeeopauth:/mwid=767aae75 -> spustí správnou aplikaci
• czeeopauth://mwid767aae75 -> spustí správnou aplikaci
• czeeopauth:mwid=767aae75 -> spustí správnou aplikaci

Takže jen a pouze přítomnost // a = v URL současně vede k této chybě

Samozřejmě nemohu ovlivnit podobu URL, kterou ten eGov web používá...

Nemáte nápady?

Odpovědi

[Max]

K čemu ta aplikace slouží? Jde mi o to, že po nasazení bankovní identity nebo mojeid, případně eGoverment klíče do telefonu už není potřeba mít doma čtečku a ověřovat se klíčem z občanky. Nebo to má stále ještě nějaký přínos? Nevím, jen se ptám.
Zdar Max

[Luboš Doležel (Doli)]

Mám bankovní identitu, mám i NIA ID, ale současně mám doma hned několik SC čteček a dnes jsem si vyzvedával nový OP, tak jsem si čip nechal aktivovat s tím, že to vyzkouším

OP se dá mimo jiné používat i pro ukládání vlastních klíčů apod.

No a jak jsem později zjistil, tak je na můj problém nahlášený i bug.

[luky]

Pokud je ctecka integrovana treba v notebooku, jako to maji kacelarsky HPcka a DELLy, tak je to pohodlnejsi nez overeni pres telefon.

[❗Červivý Hřib krade❗]

přeprasit zdrojáček kde-open5 tady asi hele :D

[reb]

Pokud aplikace/web používá neplatné URL, doporučuji nahlásit na relevantní kontakt. Státní správa celkem dbá na dodržování různých norem a standardů, resp. je k tomu vedena (např. zákony), takže na podobné podněty celkem reaguje a šance na nápravu je obstojně vysoká.

[LarryL]

Problém není v neplatné URL.

[Peter Golis]

Nie je to URL ale URI, to je pravda. Bežní užívatelia v tom nevidia rozdiel. Otázky sú tu dve:

1. Či to URI czeeopauth://mwid=767aae75 v správnom formáte (či nie je preklep niekde na webovej stránke)
2. Prečo si ho privlastnil prehliadač a nie SW eObčanka (či nemá Chrome moc agresívny URI handler alebo mime-type)

V tom ale nepomôžem. Nemám ani Chrome, a ani české doklady s elektronickým podpisom.

[LarryL]

Ano správně bychom měli psát URI, ale o to nejde.

ad 1) Na to právě směřoval můj komentář, tzn. zatím jsem to podle diskuze pochopil tak, že v URI žádný překlep nebo problém není, takže není důvod hlásit neplatnou URI/URL, tak jak navrhoval "reb".

ad 2) To, že si danou URI přivlastnil prohlížeč je právě chyba v kde-open5 (netestoval jsem, nezkoušel jsem, jen konstatuji co vyplynulo z předchozí diskuze).

[Peter Golis]

To by v ideálnom svete mohol potvrdiť človek, čo používa elektronický podpis (validitu URI formátu) a nemá Chrome (URI handler). Zvyšok okolo je len fabulácia.

[LarryL]

Ano s Chrome je problém, ale ten problém není v Chrome (Chromiu) samotném, ale v tom, že používá xdg-open > kde-open5.

Validita URI formátu je možná problematická jen kvůli znaku "=", který je rezervovaný pro URL, ale je to dostatečný argument pro státní správu, aby změnila URI?

[Peter Golis]

Pokiaľ je ten problém v znaku = (rezervovanom pre URL), tak je to problém linku (URI) na webovej stránke. A mal by sa opraviť na tej stránke. URL je totižto iný subset URI.

Aj keď riešenie workaroundom v kde-open, alebo inou alternatívou môže byť rýchlejšie.

[LarryL]

Aj keď riešenie workaroundom v kde-open, alebo inou alternatívou môže byť rýchlejšie.

IMHO nejenom rychlejší, ale i správnější, protože vyhodnocování v jakém programu se má daná URI otevřít by nemělo probíhat na základě toho jestli obsahuje znak "=".

[Peter Golis]

Čiže to URI je správne, aj keď obsahuje znak ktorý nemá obsahovať. Tento názor vylučuje sám seba.

[LarryL]

Nejsem na 100% přesvědčený, že v URI nemůže být "=", viz:

Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.

https://www.ietf.org/rfc/rfc3986.txt

Můj předchozí komentář se netýkal správné/nesprávné URI (podle rfc definice), ale jestli je správné mít v Linuxu program (kde-open5), který vyhodnocuje (otevírá) vhodné aplikace pro danou URI jen podle toho jestli se v URI nachází znak "=". To jaká aplikace se použije pro danou URI by se mělo vyhodnotit snad podle "scheme" a nikoliv podle "=" v názvu. Nesouhlasíš?

[Peter Golis]

URL je podmnožina URI, takže znak = môže byť v URI. Ale potom sa človek nesmie diviť keď ten znak urobí z URI pre zmenu URL ktorú si zoberie Chrome aj keď nemá spracovávať danú schému.

Ale to je zbytočné rozoberať.

[LarryL]

keď ten znak urobí z URI pre zmenu URL

A jsi o tom skálopevně přesvědčen, že znak "=" v URI z ní udělá URL? Já už o tom tak přesvědčený nejsem.

Ale to je zbytočné rozoberať.

Není. To v čem se otevře daná URI mně přijde jako docela zásadní věc, která by měla být doladěná a měla by fungovat dle očekávání.

[Peter Golis]

Pokiaľ je použitie znaku = vyhradené pre URL a použije sa v URI mimo podmnožiny URL, tak by sa adresa URI z mimo podmnožiny URL mala týmto zneplatniť. A webík s vadnou adresou by sa mal opraviť.

Alternatívou je vykonať workaround. Buď považovať takto pokazené URI za URL (a nechať to spracovať internetovým prehliadačom), alebo podsunúť takto neplatnú adresu aplikácii.

[LarryL]

No a na ten můj komentář (na který odkazuješ) nyní říkám, že "Já už o tom tak přesvědčený nejsem.". Takže v tuto chvíli nemáme v diskuzi nikoho, ani žádný odkaz, který by prokazoval, že "=" v URI z ní udělá URL.

[Peter Golis]

Ja som o tom ani nikdy presvedčený nebol. A furt si stojím za tým, že by to mal skontrolovať niekto čo nemá Chrome, ale používa eObčanku. Zvyšok okolo je len fabulácia.

[LarryL]

S Firefoxem to funguje, protože ten má vlastní vestavěný zpracovávač schémy.

[Peter Golis]

To je rozumný nápad, použiť iný prehliadač. Taký, v ktorom to funguje bez problému.

[LarryL]

Ale řešení to není. Řešením je opravit kde-open. Např. v XFCE funguje spojení Chrome a eObčanky bez problémů.

[Peter Golis]

Workaround is not the solution, but is cheap fix.

[LarryL]

...a cheap fix by měl být jen dočasný než přijde solution

[Peter Golis]

Ale to by musel niekto s eObčankou nahlásiť bug na správne miesta, a dodať k tomu aj technické detaily. Potom sa vytvorí riešenie ktoré ...

[LarryL]

Bug je vytvořen na KDE již od července.

[Peter Golis]

V tom prípade postupujú podľa pridelenej dôležitosti.

[j]

Tak to urcite ... tohle je defakto vzdalene zneuzitelnej security bug, tudiz to nejhorsi co muze kde byt.

---

Dete s tim guuglem dopice!

[Peter Golis]

V tom prípade by si mal tvoj názor podložiť v dôkazoch pre ten bug, a nie ho ventylovať na externom fóre.

Ale mal si dobrý fór.

[Luboš Doležel (Doli)]

Já bych jen doplnil, že KDE to původní URI přetvoří na http://czeeopauth/mwid=767aae75. Prostě to do schématu prdne http a z původního schématu to udělá hostname!

Můžeme vést nekonečné diskuze o tom, co v URI má nebo nemá být, ale to, co z toho KDE vyrobí, než to předá prohlížeči, určitě nemá podporu ani v RFC, ani v jakékoliv logice.

Ten kód, co tohle dělá, musí bejt strašná prasárna.

[LarryL]

Ten kód, co tohle dělá, musí bejt strašná prasárna.

Podle mě se někdo snažil o nějakou automatiku při rozpoznávání URL, aby to bylo co nejuniverzálnější pro široké použití v KDE a trošku to s tou automatikou přehnal