Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 36 37 [38] 39 40 ... 375
556
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 24. 06. 2022, 00:22:44 »
A da sa to urobit ak sa v blizkosti takeho PC uz nenachadza?
Token se zahodí automaticky s ukončením prohlížeče. Pokud se někdo na sdíleném počítači přihlásí do Google účtu, pak do aplikace a pak to tam celé nechá otevřené a odejde, nepomůže mu odhlášení z aplikace na jiném počítači – protože ten, kdo si sedne k původnímu počítači, se do aplikace znovu přihlásí přes Google účet (který tam zůstal odemčený).

557
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 23. 06. 2022, 18:18:14 »
Nemusi to nutne riesit tento scenar, moze sa stat ze zostal prihlaseny niekde na verejnom PC a chce sa z neho proste odhlasit.
To je ale úplně něco jiného. To se udělá prostě tak, že se v prohlížeči zahodí uložený token.

558
Otázka do pranice,  co způsob(ol)í žadateli  i datovou schránku? Četl jsem nějaké ďábelské plány, že někdo, kdo si dovolí využít "e-goverment", tak za to na něj pošlou datovou schránku. Ale nevím jestli od toho upustili. A i kyby, čejo se to týkalo (použití které metody z nadpisu)?
Bude to platit od 1. 1. 2023 a nezáleží na metodě, kterou použijete – jakékoli použití NIA po 1. lednu vám tu datovou schránku založí. Což je vtipné zejména u toho přístupu s úrovní záruky nízká od ČSOB, protože s tou se přihlásíte k NIA, ale pro přihlášení do datové schránky to nestačí (tam je vyžadována alespoň úroveň značná).

559
To je nějaké divné. V ČSOB mi bankovní identitu založilu proti mé vůli. Nejde zrušit. Když jsem ji zkoušel použít, tak to šlo, a to žádnou aplikaci nemám.
Tohle je různé banka od banky. Některé to mají opt-in, některé opt-out a některé vám to založí a máte akorát možnost nepoužívat to. Prý se připravuje možnost na úrovni NIA zakázat, které poskytovatele identity nechcete používat – tj. třeba řeknete, že máte bezpečné MojeID a eObčanku, a pokud by se někdo pokoušel přihlásit vaší identitou od kteréhokoli jiného poskytovatele, neprojde to.
ČSOB myslím umožňuje i přihlášení na úrovni nízká, tam byste nic speciálního (aplikaci, hw klíč) nepotřeboval.

560
Jestli on spíš nebude problém v tom, že OKsystem cz s.r.o. je něco jiného než OK SYSTEMS, OK System nebo OKsystem a.s. První a poslední jsou opravdu firmy.

561
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 22. 06. 2022, 11:38:54 »
To okamzite odhlasenie nema byt z dovodu, ak by sa utocnik dostal k jeho jwt tokenu, alebo by sa mu niekto prihlasil jeho menom a heslom, tak aby vedel dane zariadenie okamzite odrezat a odhlasit.
K čemu to bude, když se útočník na tom zařízení okamžitě zase může přihlásit přes Google?

562
Tady píšou, že NIA ID má také značnou: https://info.identitaobcana.cz/KvalifikovaniSpravci.aspx
tak to zkusím.
„Značná“ je méně než „vysoká“. Nicméně „značná“ vám zatím stačí na většinu operací. V budoucnosti ale např. náhrada elektronického podpisu bude vyžadovat úroveň „vysoká“.

563
Doporučuju použít MojeID. Když budete chtít, dosáhnete s ním na nejvyšší úroveň zabezpečení, v brzké době bude mít akreditaci pro celou EU, a zřídíte si to také na CzechPointu (začněte ale na webu MojeID na výše uvedeném odkazu).

Bankovní identita je omezená – v ČR se s ní nepřihlásíte k soukromoprávním subjektům, které vystupují v roli orgánů veřejné moci (např. zdravotní pojišťovny). Nedosáhnete s ní na nejvyšší úroveň zabezpečení a platí jen v rámci ČR.

564
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 21. 06. 2022, 11:03:09 »
Taky je dulezite mit na pameti, ze v pripade microservice architektury bezi business logika aplikace v Javascriptu Browseru a tudiz je pristupna pro manipulaci.
Ne, v případě microservice architektury běží byznys logika aplikace v těch microservisách na serveru.

Microservice architektura dava smysl hlavne, pokud potrebuju obsouzit radove miliony uzivatelu, pro pouziti v mensim
rozsahu to oproti Spring Boot monolitu prinese leda DevOps opruz, slozity debugging a hromadu potencialnich bezpecnostnich problemu.
Microservice architektura dává smysl také tehdy, když chcete službu provozovat bez výpadků. Nebo když ji chcete snadno škálovat (to nemusí být jen miliony uživatelů, zdroje můžete ušetřit i tehdy, když máte špičku s desetitisíci uživatelů dva dny v měsíci). Nebo když chcete mít jednotlivé části oddělené z hlediska vývoje, aby bylo možné je nezávisle na sobě vyměnit.

Microservice architektura je dost široký pojem, ony ty služby nemusí být zas až tak „micro“. Nějakou komplexitu to přináší, ale ve výsledku je jednodušší udržet dlouhodobě použitelnou microservice architekturu. Platí, že když někdo neumí udělat dobře monolit, nebude umět udělat dobře ani microservisy. Ale microservisy vyvíjejí větší tlak na tu správnou architekturu.

do stateless microservice formatu se session
To je nonsense. Session drží stav, nemůžete mít bezestavovou architekturu se stavem.

565
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 21. 06. 2022, 08:54:55 »
Ano, JWT jsou doporučené řešení pro mikroservisy, protože mikroservisy jsou bezestavové, což právě JWT umožňují (na rozdíl od session). Otázka je, co se s těmi finančními prostředky dělá, že chcete okamžité odhlášení. Pokud je to důležité, měl by to naopak uživatel extra potvrdit. Zároveň chcete mít přihlašování přes Google, takže i když se uživatel okamžitě odhlásí z vaší aplikace, případný útočník se stejně může znovu přihlásit přes Google.

V tom vašem případě by bylo možné při tom provádění operace s finančními prostředky ověřovat, že token není na blacklistu, a tím zařídit to okamžité odhlášení alespoň v kritických případech. Ale spíš mi připadá, že je potřeba ještě definovat, jaké požadavky na bezpečnost vlastně máte. Protože jak jsem psal výše, nedává mi to dohromady smysl (což neznamená, že to smysl nemá – víme od vás jen útržky).

566
Software / Re:"Multi root" systém správy verzí
« kdy: 20. 06. 2022, 22:02:47 »
Ten hook na serveru by jen kontroloval, že commit obsahuje všechny tři adresáře.

Na klientovi by na commitnutí stačilo napsat jednoduchý skript. Pokud uživatel commituje vždy ten samý adresář, skript by ani nemusel mít parametry (případně by měl jako parametr text commit zprávy – ale možná by bylo lepší commit zprávu generovat skriptem). Pokud jeden uživatel commituje více různých adresářů, buď by skriptu předával jako parametr název adresáře, nebo by skript mohl detekovat, ve které adresáři byl spuštěn a zachovat se podle toho.

Pokud to chcete klikací, nainstalujte jim Altap Salamander – v něm budou procházet adresáře a pracovat se soubory. Na nástrojovou lištu jim dáte ikony, kterými budou spouštět ty skripty. Skriptu předáte jako parametr aktuální adresář a skript podle toho provede commit správné trojice.

567
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 19:21:03 »
Session je nesmysl, to nechcete – s mikroslužbami to nejde dohromady. Potřebuje uživatel odříznout zařízení od přístupu okamžitě? Pokud ne, pak JWT s refresh tokenem stačí.

Pokud je teď vyžadováno jen přihlášení přes Google, začal bych tou první variantou (budete používat přímo JWT od Googlu). Pokud budete potřebovat později silnější nástroj, doimplementujete si autorizační server. Nebo použijete Keycloak, pokud mermomocí budete potřebovat něco hodně velkého.

568
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 17:03:27 »
JWT neověřujete s každým požadavkem ověřovat u toho, kdo jej vydal. Právě naopak – JWT je elektronicky podepsaný, takže jenom ověříte podpis a na jeho základě víte, že ho opravdu vydal ten, kdo měl (ve vašem případě Google). Proto se také používá refresh token – vy ověřujete access token sám, bez Googlu, a tím pádem se nedozvíte, když se uživatel třeba odhlásil. Proto access token neplatí moc dlouho, a máte ještě refresh token, na jehož základě získáváte nový access token. Pro tu obnovu už musíte kontaktovat Google, a to je ta chvíle, kdy vám Google může odmítnout vydat access token (třeba protože už se uživatel odhlásil).

Jinak se používají obě vaše varianty. To přímé použití JWT vydaného Googlem je jednodušší na první implementaci (nemusíte řešit vydávání vlastních tokenů). Naopak při použití vlastních tokenů máte vše v ruce – můžete sjednotit data v tokenu napříč poskytovateli (tj. když přidáte Facebook a Twitter, pro koncovou aplikaci se nic nezmění), můžete si do tokenu přidat další informace, které potřebujete, třeba role, do kterých uživatel patří.

569
Software / Re:Čím nahradit MinIO?
« kdy: 20. 06. 2022, 15:15:41 »
Aha, ja som cakal, ze sa to tyka celej aplikacie (aj ked defakto je to viac spustitelnych aplikacii sucastne).
Pokud by to opravdu byla jedna aplikace a váš kód byl odvozený od kódu MinIO, pak by opravdu pro celou aplikaci platila AGPL licence. Já ale předpokládám, že používáte MinIO jako server, S3-kompatibilní úložiště BLOBů, a váš klient není na MinIO přímo závislý – mohl by (třeba s drobnými úpravami) běžet i proti jinému S3 úložišti. Nebo-li že MinIO používáte podobným způsobem, jako byste používali třeba relační nebo NoSQL databázi, souborový server – prostě jako externí službu, která stojí mimo vaši aplikaci. Pokud je to tak, potom se na vás ta „virálnost“ AGPL nevztahuje. Dokonce pokud uživatelé nekomunikují přímo s MinIO, ale pouze s vaší aplikací, nevztahuje se na to ani ten „síťový“ dodatek AGPL.

570
Software / Re:"Multi root" systém správy verzí
« kdy: 20. 06. 2022, 13:03:09 »
Pokud to chcete jako jedno repository, stačí nastavit commit hooky, kterými se bude kontrolovat, že uživatel nemění něco, co nemá. Pokud budete pro synchronizaci používat centrální server, je nejjednodušší nastavit to tam. Uživatel pak sice může udělat chybný commit, ale už ho přes push neprotlačí na centrální server a ostatním. Pokud byste měl jen lokální repository, hooky mohou být i tam – pak je to samozřejmě na zodpovědnosti těch uživatelů, že ty hooky nebudou měnit.

Stran: 1 ... 36 37 [38] 39 40 ... 375