Co se stane, když kontejnery spustíte poprvé bez přípravy > 자유게시판

• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Čtvrtá situace: REST je lepší pro operace typu upload souborů a streaming. HTTP má pro to vyhrazené mechanismy, které GraphQL neumí nativně. Pokud posíláte velké binární soubory, videa nebo obrázky, REST endpoint s multipart/form-data je jednodušší a rychlejší řešení. GraphQL sice zvládá soubory přes specifikaci, ale je to krkolomné a zbytečně komplikované. V praxi se proto soubory posílají klasicky přes REST a zbytek API běží na GraphQL. Není ostuda kombinovat oba přístupy v jedné aplikaci.

Co se týče samotných akcí, snažte se psát je tak, aby byly idempotentní – tedy aby jejich opakované spuštění nezpůsobilo problémy. To platí zejména při nasazování, kde opakovaný běh nesmí vytvořit duplicitní release nebo přerušit běžící službu. Mějte také na paměti, že Actions je vázané na GitHub – pokud váš projekt migruje na jinou platformu, budete muset pipeline přepsat. U klasických CI serverů je portace obvykle jednodušší, protože používají univerzálnější konfiguraci.

Při ověřování každého požadavku vždy zkontrolujte nejen podpis a expiraci, ale také, že token nebyl revokován. JWT je ze své podstaty stavový, pokud potřebujete možnost okamžitě zrušit přístup, musíte vést seznam zneplatněných tokenů. To se hodí zejména při odhlášení uživatele nebo při změně oprávnění. Bez této kontroly může token zůstat platný až do konce své expirace, For more about https://jak.mazovia.Edu.Pl/index.php/Co_rozhoduje_o_tom,_že_frontend_a_backend_mluví_stejnou_řečí? check out our web site. což je v některých scénářích nepřijatelné. Implementujte tedy mechanismus, který ověří, zda token není na černé listině, a to ideálně pomocí krátké doby platnosti a pravidelného čištění seznamu.

Prvním krokem je vždy podpis tokenu. Používejte silný algoritmus, jako je RS256, který vyžaduje asymetrický klíč. Soukromý klíč drží server, veřejný klíč slouží k ověření podpisu. Nikdy nepodepisujte token symetrickým klíčem, pokud nemáte naprostou jistotu, že klíč nemůže uniknout na klientskou stranu. Důležité je také nastavit krátkou dobu platnosti, ideálně minuty, ne hodiny. Pro delší přístup použijte refresh token, který umožní získat nový přístupový token bez nutnosti znovu přihlašovat uživatele. Tím omezíte okno, ve kterém může útočník token zneužít.

jak zařídit malou kuchyni poznáte, že je vaše implementace JWT skutečně bezpečná? Nejčastější chybou je ignorování algoritmu v hlavičce tokenu. Útočník může změnit algoritmus na „none" nebo slabší, pokud server nekontroluje, jaký algoritmus je povolen. Vždy na straně serveru explicitně ověřte, že použitý algoritmus odpovídá tomu, který váš systém skutečně podporuje. Nikdy nevěřte algoritmu uvedenému v tokenu bez další kontroly. Druhým častým problémem je ukládání tokenu v prohlížeči do localStorage. To je snadný terč pro útočníka, který využije XSS zranitelnost. Místo toho umístěte token do paměti aplikace, případně do httpOnly cookie s atributy SameSite a Secure. Tím snížíte riziko, že se token dostane do nesprávných rukou.

Praktickým nástrojem je tzv. rezerva na neznámé. Vytvořte si vlastní šablonu odhadu, která obsahuje položky jako „průzkum", „implementace", „testování", „integrace", „komunikace" a „dokumentace". Ke každé položce si napište čas, který jste u minulých podobných úkolů reálně potřebovali, ne to, co jste si představovali. Po dokončení úkolu si porovnejte odhad se skutečností a zapište si, kde jste se mýlili. Tato zpětná vazba je nejcennější pro budoucí plánování.

Typickou chybou je také podcenění samotného testování. Nepočítejte jen s napsáním testů, ale také s časem na jejich spuštění, analýzu selhání a opravu chyb, které testy odhalí. K tomu přidejte manuální ověření v prohlížeči nebo na zařízení, protože automatické testy neodhalí vše. Pokud pracujete v týmu, zahrňte do odhadu i čas na code review, připomínky a následné úpravy. I rychlá kontrola může zabrat hodinu, když se objeví designové neshody.

Jak poznat, že vám REST nestačí a GraphQL nepomůže První situace: když máte mobilní aplikaci s omezenou konektivitou. REST typicky vrací všechna data z daného endpointu, i když potřebujete jen polovinu. Například profil uživatele zahrnuje i seznam jeho objednávek, které na malém displeji vůbec nezobrazujete. To znamená zbytečný přenos stovek kilobajtů. GraphQL vám umožní dotázat se pouze na jméno, e-mail a poslední přihlášení. Pokud tedy cílíte na uživatele s pomalým připojením, GraphQL výrazně sníží velikost payloadu. Pozor jen na to, že každý dotaz musíte schválně omezit, jinak si klient může vyžádat celou databázi.

Obraz sestavíte příkazem docker build -t moje-aplikace . Tečka na konci je důležitá, říká Dockeru, kde hledat Dockerfile. Po sestavení spustíte kontejner přes docker run -p 3000:3000 moje-aplikace. Tím mapujete port z vašeho počítače na port v kontejneru. Pokud aplikace běží na portu 3000, otevřete prohlížeč a uvidíte ji. Bez mapování portů se k ní zvenčí nedostanete. To je první typická chyba: zapomenout na -p a myslet si, že aplikace je nedostupná, přestože běží.