reklama

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] 2 3 ... 216
1
Sytémovou utilitku nice znám ta však neřeší všechny problémy. Jak mnozí z diskutérů uvedly není, moudré vytěžovat server na 100%. Hledám řešení, které mi umožní, zapínat vytěžovací úlohy v případě, pokud průměrné vytížení serveru za poslední hodinu nepřesáhlo například 30%. Podobně by bylo hezké brát v úvahu, operační paměť, nebo zápisy na disk. Tohle pomocí nice, pokud vím,  nezvládnu.
Proč to chcete dělat? Vypadá to, že se snažíte ručně optimalizovat něco, co bude jádro optimalizovat mnohem lépe.

2
/dev/null / Re:administrace systemu
« kdy: 20. 07. 2019, 15:26:09 »
Píšete „vím, že to jde přes“, ale i to víte špatně. Pokud se na nějaké zařízení chcete dostat, domluvte se s jeho majitelem. Pokud byste se někam dostával neoprávněně, jde o neoprávněný přístup k počítačovému systému, na který trestí zákoník pamatuje v § 230 a oceňuje ho až dvěma roky vězení, v případě přitěžujících okolností i více.

3
Vytváříte tam objekt Document a pravděpodobně nikde nenastavujete fieldu documentsForUsers nějakou hodnotu – v deklaraci to nemáte a nejspíš to není ani v konstruktoru. document.getDocumentsForUsers() pak vrací null a pokus o volání metody na null skončí NullPointerException.

Jinak s ORM vám asi nepomůžu, já mám k ORM vrozený odpor (podle mne je to nástroj, který dělá víc škody než užitku) a zatím se mu úspěšně vyhýbám… (Ne že bych nedělal i na projektech, kde se používá ORM, ale nemusím u nich ORM řešit.)

4
Vývoj / Re:Prototypové OOP
« kdy: 16. 07. 2019, 11:00:53 »
Nejrozšířenější jazyk používající prototypovou dědičnost je JavaScript. O prototypové dědičnosti v JavaScriptu si můžete přečíst např. v článku Třídy, dědičnost a OOP v Javascriptu – II.

5
Software / Re:Interaktivní návrh obrazovek
« kdy: 16. 07. 2019, 09:35:10 »
Lidé z oboru, kteří tohle dělají, jsou UX designéři. Používají např. Sketch, Figma nebo Adobe XD pro návrh wireframů nebo obrazovek. Dají se použít i pro jednoduché prototypy, případně se pro prototypy používá např. InVision, Framer, Axure nebo Principle.

6
Token pro autorizaci požadavků na resource server se obvykle posílá v hlavičce Authorization – použije se typ autentizace  „Bearer“ a pak je uvedený token. Tj. HTTP hlavička pak vypadá takhle:

Kód: [Vybrat]
Authorization: Bearer <token>

Resource server s podporou JWT by měl umět vyzvednout si JWT token z této hlavičky.

7
Spring musí být nakonfigurován, aby povolil ten přístup bez client secret – dá se k tomu něco najít např. zde: Spring Security OAuth 2.0 - client secret always required for authorization code grant.

Podle mne je local storage nebo session storage bezpečné úložiště pro ty tokeny – dostanou se k němu jenom skripty z příslušné domény. Pokud jde o SPA aplikaci, můžete ten token uložit i přímo v aplikaci, ale pak dojde k odhlášení uživatele když obnoví stránku (F5).

8
Používáte podporu pro resource server, která je součástí Spring Boot, takže JWT nebudete ověřovat ručně. O ověření se postará Spring Boot a z vašeho pohledu to bude fungovat stejně, jako jakýkoli jiný způsob přihlášení. Tzn. deklarujete, které části aplikace může používat anonymní uživatel, které přihlášený, případně jakou roli musí mít uživatel, aby mohl použít danou službu. Je dobré to ověřit tak, že vyzkoušíte přístup s platným tokenem, s expirovaným tokenem, s tokenem s nevalidním podpisem a bez tokenu. K aplikaci byste se měl dostat jenom s platným tokenem, v ostatních případech musí server vrátit nějakou chybu.

Implicit flow se už dnes nepoužívá. Byl navržený pro aplikace v prohlížeči, ale i tam už se dnes doporučuje používat authorization flow, akorát se v takovém případě nepoužívá client secret (protože u aplikace běžící kompletně v prohlížeči není kam ho schovat).

9
Pokud běží REST API na jiném hostname, než webová aplikace (typicky to tak je), musí ten REST server posílat Access-Control-* hlavičky, aby prohlížeč komunikaci akceptoval. Je to ochrana před tím, aby webová stránka nemohla volat REST služby serveru, který s tím nepočítá – mohla by tak na ten server útočit.

Akorát ve Springu to nemusíte řešit ručně, má už pro to podporu: Enabling Cross Origin Requests for a RESTful Web Service.

10
Každá stránka by si měla kontrolovat, zda je token k dispozici – a pokud není, přesměrovat uživatele na přihlašovací stránku.

JWT je jen JSON zakódovaný v BASE64 (resp. jsou to tři objekty, každý se zakóduje do BASE64 a vše se pak spojí tečkou do jednoho řetězce). Takže získat z toho ty údaje (pokud byste neprováděl validaci) jde i ručně. Lepší je ale použít hotovou knihovnu, např. na jwt.io je docela dobrý přehled knihoven pro různé jazyky.

11
Client-id je veřejný údaj, ten není potřeba šifrovat. Client secret se používá v případě, kdy se autentizuje serverová aplikace, do které můžete ten klíč client secret schovat. Pokud se autentizuje webová aplikace běžící v prohlížeči, client secret se nepoužívá – bezpečnost je založená na tom, že autentizační server po dokončení autentizace přesměruje prohlížeč na adresu, která je svázaná s daným klientem. Tj. i kdyby přihlášení zahájil útočník, skončí to tak, že se uživatel přihlásí do té správné (ne útočníkovi) aplikace.

Pro podpis JWT se pak mohou použít dvě různé metody – buď  se používá sdílený klíč, nebo klasický elektronický podpis s veřejným a privátním klíčem. Ten sdílený klíč se používá v případě, kdy si aplikace navzájem důvěřují a vše je na serveru, takže se sdílený klíč k nikomu cizímu nedostane. Aplikace, která JWT token jenom ověřuje, totiž musí mít ten samý klíč, který se používá pro vytvoření podpisu – škodlivá aplikace by tudíž mohla sama vytvořit falešný JWT, který by ale byl podepsán tím správným klíčem, a třetí aplikace by mu důvěřovala.

Druhá možnost je použití veřejného a privátního klíče. To používají třeba veřejné služby – když se přihlašujete prostřednictvím Google nebo Twitteru, dají vám jenom veřejný klíč. Nemohou použít přístup se sdíleným klíčem, protože pak by tím jejich klíčem mohl kdokoli podepsat JWT, který by pak vypadal jako skutečný JWT od Googlu nebo Twitteru. Implementačně je ten způsob s dvojicí klíčů trochu složitější, ale většinou používáte nějakou knihovnu, kde už je to podepisování zapouzdřené a vy to nemusíte řešit. Pokud tedy klienta nemáte pod kontrolou (buď je to webová aplikace v prohlížeči, a nebo aplikace třetích stran), používá se tahle druhá metoda s veřejným i privátním klíčem. My to například budeme používat i v jednom spolku, kde se bude autentizovat víc různých aplikací. Sice jsou všechny ty aplikace „naše“ a mohli bychom jim věřit, ale očekáváme, že i ty „naše“ aplikace budou různě důvěryhodné – takže rovnou použijeme tu variantu s veřejným a privátním klíčem, a ten privátní klíč bude znát jenom aplikace provádějící autentizaci.

Kontrola toho, zda JWT nebylo změněno, by se měla provádět vždy, když se JWT použije (budete z něj číst nějaká data). K tomu právě slouží ten podpis. V knihovnách to obvykle bývá nazváno jako validace a ověří se právě to, že podpis sedí s daty, tj.  po podepsání nedošlo ke změně dat. K validaci je právě potřeba znát buď ten sdílený klíč nebo veřejný klíč, podle toho, co se používá.


Mám na tohle diskusní téma zapnuté e-mailové notifikace, takže když sem vložíte příspěvek, dozvím se to, a pokusím se poradit, pokud budu vědět.

12
Sítě / Re:Veřejná, neveřejná
« kdy: 23. 06. 2019, 21:42:04 »
To nic nemění na tom, že i když bude mít možnost navázat z venku spojení na libovolný port TCP i poslat UDP paket na libovolný port (a paket dorazí až na cílový počítač), pořád ještě to neznamená, že tam není firewall. Firewall může blokovat třeba pakety nepatřící do žádného spojení nebo třeba tyhle pakety. Stejně tak přítomnost firewallu nijak nesouvisí ani s tím, zda je ta IP adresa routovaná nebo zda je to řešené jako NAT 1:1.

13
Sítě / Re:Veřejná, neveřejná
« kdy: 23. 06. 2019, 20:58:04 »
Tak mi komunikace na všechny porty prochází, ale jsem za firewallem? Jak to jde dohromady?
Firewall blokuje provoz podle nějakých pravidel. Ta pravidla nemusí brát ohled na porty nebo to může být podmínka „port + další podmínka“. Firewall může blokovat i provoz, který žádné porty nemá (nemáme jen protokoly TCP a UDP).

14
Vývoj / Re:bash regular pro xml
« kdy: 21. 06. 2019, 13:36:29 »
jde to, většina implementací regulárních výrazů podporuje rekurzivní matche.
To ale na parsování XML nestačí.

15
Vývoj / Re:bash regular pro xml
« kdy: 21. 06. 2019, 11:12:05 »
Raději použijte nějakou utilitu, která vám umožní použít XPath. Bude to mnohem jednodušší na použití a bude to fungovat. Napadá mne třeba XML Shell, vygooglit se toho dá víc.

Stran: [1] 2 3 ... 216

reklama