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 ... 191 192 [193] 194 195 ... 375
2881
Sítě / Re:Nastavení routování
« kdy: 12. 11. 2018, 07:11:44 »
Tam, kde děláte DNAT, musíte v tomhle případě dělat i SNAT. NATovaný paket pak bude mít jako adresu zdroje uvedenou IP adresu toho NATujícího zařízení, odpovědní paket doputuje zase k tomu NATu, ten DNAT a SNAT se provedou obráceně a teprve pak se ten paket odešle zpět do internetu.

2882
Pokud to chcete postaru, bez WITH nebo window funkcí, použijte pro „setřesení“ těch vícenásobných záznamů do jednoho GROUP BY a nějakou agregační funkci, která vám z těch vícenásobných záznamů vybere ten správný. Pokud chcete vybírat např. nejmladší záznam a víte, že nikdy nebudou dvě nejvyšší skóre jednoho hráče ve stejný den, můžete vzít maximum z data. A nebo pokud předpokládáte, že se záznamy do databáze vkládají chronologicky a ID se přiděluje ze sekvence, můžete použít maximální id.

Kód: [Vybrat]
SELECT ps.*
FROM player_score ps
WHERE ps.id IN (
  SELECT MAX(id)
  FROM player_score ps2
  WHERE ps2.created_at >= '2000-01-01' AND ps2.score = (
    SELECT MAX(ps3.score)
    FROM player_score ps3
    WHERE ps3.player_id = ps2.player_id AND ps3.created_at >= '2000-01-01'
  )
  GROUP BY ps2.player_id 
)

No a nebo pokud je vám jedno, který ze záznamů se vrátí u těch vícenásobných maximálních skóre, a používáte MySQL, která se pro vracení náhodných dat náramně hodí, udělejte prostě na tom vnějším SELECTu GROUP BY player_id – MySQL do výsledné sady sama náhodně vybere jeden z těch vícenásobných záznamů:

Kód: [Vybrat]
SELECT ps2.*
FROM player_score ps2
WHERE ps2.created_at >= '2000-01-01' AND ps2.score = (
  SELECT MAX(ps3.score)
  FROM player_score ps3
  WHERE ps3.player_id = ps2.player_id AND ps3.created_at >= '2000-01-01'
)
GROUP BY ps2.player_id 

2883
Je MITM systém v takovém případě schopný komunikaci rozšifrovat?
Předpokládám, že ten privátní klíč ke klientskému certifikátu máte jen vy. Pokud vám v takovém případě MitM pošle svůj certifikát, dokáže komunikaci mezi vámi a MitM rozšifrovat. Ale nedokáže se už vaším certifikátem autentizovat k vzdálenému serveru, takže z něj nedokáže získat data. Tj. dokázal by takhle získat tajné údaje od vás, ale ne ze serveru.

Pokud správce toho MitM serveru tedy nechce komunikaci s tím cílovým serverem úplně znemožnit, nezbývá mu, než v tomhle případě nepodvrhovat vlastní certifikát a komunikaci nechat tak jak má být, tedy je šifrovaná mezi serverem a klientem, proxy nedělá MitM a do té šifrované komunikace nevidí. Konkrétní nastavení závisí na firemní politice – pokud se např. přihlašujete certifikátem k firemní datové schránce tak vám tu komunikaci asi umožnit musí. Pokud nemáte v popisu práce přihlašovat se někam certifikátem, snadno zdůvodní, že to tedy ke své práci nepotřebujete a že tu komunikaci mohou klidně zaříznout.

Technicky je to zařízené tak, že klient vlastnictví privátního klíče prokazuje tak, že jím podepíše vše, co bylo součástí předchozí komunikace (ustavení TLS spojení), a její součástí je i serverový certifikát. Takže pokud MitM útočník podvrhne svůj certifikát, podepíše klient ten a serveru nebude sedět podpis. Pokud MitM útočník nepodvrhne svůj certifikát a nechá tam původní serverový, nebude moci rozšifrovat komunikaci.

Ono to plyne i z toho, co má TLS zajišťovat. Pokud se připojujete bez přihlašovacího certifikátu, autentizuje se pouze server vám (klientovi) – a vy uděláte tu „chybu“, že uvěříte špatnému certifikátu. Pokud se ale přihlašujete klientským certifikátem, je to vzájemná autentizace – klient autentizuje (koho, co) server, ale zároveň i server autentizuje klienta. Klient sice opět může důvěřovat falešnému certifikátu, ale server (správně napsaný) na případný falešný certifikát klienta nenaletí.

Samozřejmě to závisí na tom, že ten privátní klíč pro klientský certifikát máte opravdu jenom vy. Pokud vám certifikát generovala nějaká firemní autorita, a abyste se o to nemusel starat, vygenerovala vám i privátní klíč, pak je samozřejmě možné, že jí ten privátní klíč zůstal někde za nehty a teď se jím může přihlašovat místo vás.

2884
Certifikát v žádném případě nenese soukromý klíč – klientský soukromý klíč musí zůstat na klientovi, jinak by nebyl soukromý.

Tyhle antiviry pokud vím bývají nastavené tak, aby do některé komunikace nelezly – např. právě pokud se přihlašujete do nějakých známých systémů (např. intranety nebo extranety) klientským certifikátem, někde to údajně mají nastavené tak, aby nelezly do komunikace s vybranými bankami. Stejná výjimka bude předpokládám i v případech, kdy se přihlašujete klientským certifikátem k neznámému systému, akorát tam to bude komplikovanější na implementaci, protože požadavek na klientský certifikát se posílá až po serverovém certifikátu, a může se dokonce poslat i v průběhu spojení v rámci SSL renegociace.

2885
Na těch obrázcích toho není moc vidět, ale jsou ty certifikáty při přístupu z firemní sítě pravé? Nejsou to certifikáty podvržené nějakým antivirem, který strašně nutně potřebuje skenovat obsah šifrované komunikace?

2886
V rámci EU asi těžko, ale mimo EU to určitě omezit můžete. Např. na Amazon.com běžně narazíte na to, že tamní prodejci do ČR nedoručují (jasně, spadá to pod právo USA, jenom tím ukazuju, že omezení na cílové státy je běžné).

2887
Server / Re:Docker ignoruje /etc/hosts
« kdy: 08. 11. 2018, 12:30:33 »
Kontajner bezi vo svojom nezavislom network priestore, takze nevie nic o /etc/hosts z host OS. S pouzitim --network=host si presunul kontajner do host network priestoru, takze uz vidi host /etc/hosts.
Síťový prostor jsou údaje v jádru (přiřazené IP adresy, routovací tabulky, pravidla firewallu). /etc/hosts je jenom obyčejný soubor na disku, jádro s ním nijak nepracuje. Ten soubor používá systémová knihovna – DNS resolver. Obvykle glibc, ale může být použita jiná knihovna, případně může aplikace používat jiný způsob resolvování a záleží na ní, zda používá /etc/hosts.

2888
Server / Re:Docker ignoruje /etc/hosts
« kdy: 08. 11. 2018, 10:53:28 »
Aplikace běžící uvnitř Docker kontejneru se řídí konfigurací uvedenou v /etc/hosts uvnitř kontejneru. Aby fungoval ping zevnitř kontejneru na hostitelský stroj, musí být správně nastaveno routování mezi nimi a nesmí to zakázat firewall.

2889
Ano, lze. Ale musíte si tu návratovou hodnotu z funkce setTimeout() uložit do nějaké proměnné nebo objektu, který bude dostupný i při tom příštím volání kódu, kde je to setTimeout(). U jednoduchého kódu to může být globální proměnná, jakmile je to trošku složitější, je dobré ta data nějak zapouzdřit – buď pomocí objektu, nebo v JavaScriptu pomocí scope vnořených funkcí (vizte třeba Základní vzory pro vytváření jmenných prostorů v JavaScriptu).

2890
Vývoj / Re:Vhodná verze Javy
« kdy: 04. 11. 2018, 20:27:44 »
Určitě byste měl znát vše (tím myslím jazykové konstrukce a povědomí o tom, co je ve standardní knihovně), co je ve verzi 8, ta je dnes nejrozšířenější. Pak je dobré mít alespoň ponětí o tom, co se přidalo (nebo u 11 odebralo) do novějších verzí (9 – 11), až na jeden případ jsou to drobnosti. A průběžně sledovat, co se bude přidávat do nových verzí.

Ta výjimka, co není drobnost, je modularita v Javě 9 – určitě je dobré alespoň vědět, co to je. Opravdu porozumět modularitě je užitečné do budoucna – jednak se to bude postupně používat, jednak je dost možné, že se dostanete do nějakého týmu, kde budete jediný, kdo tomu bude opravdu rozumět, a můžete to naučit správně používat ostatní. Na druhou stranu porozumět dobře modularitě nebude snadné, protože je to krok k větší čistotě kódu, čemuž se spousta programátorů bude samozřejmě bránit a budou mít tisíce důvodů, proč zrovna v jejich projektu je nečistý kód správné řešení a předvedou vám velmi nápaditá špatná použití modularity, aby dokázali, že to opravdu nejde používat. Navíc ve spoustě starších projektů opravdu modularitu použít reálně nejde, protože to znamená i architektonické změny – a na tom, že se dříve nepoužila lepší architektura, není nic špatného, protože prostě nebyly k dispozici potřebné nástroje. Tohle se třeba bude týkat všech Springových aplikací… Další problém je, že dneska pro modularitu v Javě chybí nástroje – např. buildovací nástroje, IDE nebo knihovny. Zatím jsou ve stavu, že jim jednoduché použití modularity moc nepřekáží, ale rozhodně se to nedá nazvat podporou. Gradle bude mít něco, čemu by se dalo říkat základní podpora, od verze 5.0 (už je ve fázi RC), IntelliJ Idea pokud narazí na modulový projekt, dá všechno na module-path, což je dobré leda tak na hraní, ale ne pro reálné aplikace, atd. Také k tomu zatím chybí oborové best-practices, a u některých věcí (třeba jednotkové testy) zatím vůbec není jasné, jak se vlastně mají s modularitou dělat správně. Ale přestože jsem teď vyjmenoval spoustu problémů, určitě se vyplatí se tím zabývat, i když to dnes třeba v praxi nevyužijete, protože vás to naučí i lépe uvažovat o architektuře aplikace.

2891
Vývoj / Re:Chat aplikace v javě
« kdy: 30. 10. 2018, 11:15:46 »
Pokud to budete psát ve Springu, je nejjednodušší použít technologie, pro které už Spring má podporu. Má podporu jak pro web (Spring MVC nebo Spring WebFlux), tak pro oboustrannou komunikaci přes WebSocket. Chatovací aplikaci používající WebSocket najdete snad v každém návodu, jak používat WebSocket se Springem. Např. Spring WebSockets: Build an User Chat.

2892
Vždyť jsem to psal, že to netušíte ani vy. Tam, kde by člověk očekával vaše vysvětlení, je prázdno.

2893
ale podla jirsaka ti to nemoze fungovat.
Nikoli, to podle vás. Já netuším jak jste z toho, že Ubuntu používá pro konfiguraci sítě netplan, dospěl k závěru, že systemd je monolit. A nejspíš to netušíte ani vy.

2894
Utkvělou představu máte vy v tom, že dnsmasq není distribuční.
Zase si vymýšlíte, já jsem nic takového netvrdil. Něco jiného je, zda aplikace dostupná v distribuci jako balíček, a něco jiného je, zda jde o systémový balíček, který ta distribuce sama používá pro zabezpečení své základní funkcionality. dnsmasq byl před Ubuntu 2016.10 na desktopu systémovým balíčkem, protože pomocí něj Ubuntu zajišťovalo překlad DNS. Od verze 2016.10 už systémovým balíčkem není, protože ho v této roli nahradil systemd-resolved. To neznamená, že si dnsmasq dál nemůžete nainstalovat - můžete, třeba pokud budete chtít, aby váš počítač poskytoval překlad DNS ostatním počíačům v síti. Ale ty konfigurační nástroje distribuce, které se starají o síť, budou zcea jistě umět spolupracovat se systemd-resolved (protože je to systémový nástroj), ale nemusí umět spolupracovat s dnsmasq. Například grafické konfigurační nástroje neo obecně nástroje pro konfiguraci sítě. Samozřejmě, že si dnsmasq můžete nakonfigurovat sám, ale budete muset nejspíš řešit to, co jinak řeší ty distribuční nástroje - například to, že když se DHCP klient dozví o změně DNS serverů, musí to nějak propagovat DNS resolveru. Když použijete DNS resolver dodávaný s distribucí, postará se o tohle distribuce, když použijete nějaký jiný, distribuce se o to nejspíš starat nebude a musíte si to zařídit sám.

2895
Zatímco ty jsi se evidentně ani nesnažil pochopit to, co je cílem
Cílem bylo to, aby systém při překladu DNS názvů používal místní cache a na záznamy, které nemá v cache, se ptal DNS serverů nakonfigurovaných přes DHCP. Že se musí použít něco jiného, než distribuční systemd-resolved, to je jen vaše utkvělá představa.

Stran: 1 ... 191 192 [193] 194 195 ... 375