Proč jsou JWT tokeny bezpečné jen tehdy, když je správně implementujete? > 자유게시판

본문 바로가기

자유게시판

Proč jsou JWT tokeny bezpečné jen tehdy, když je správně implementujet…

페이지 정보

profile_image
작성자 Pearl
댓글 0건 조회 2회 작성일 26-08-29 21:03

본문

Když potřebujete zkontrolovat, co jste změnili, použijte git status a git diff. Status ukáže, které soubory jsou upravené nebo nové, diff zobrazí konkrétní řádky, které se liší. Tím zjistíte, jestli jste omylem nepřepsali něco důležitého. Pokud chcete vrátit soubor do stavu posledního commitu, použijte git checkout -- soubor (pozor, tato operace smaže vaše úpravy bez možnosti obnovy).

Dalším problémem je dotazování na velké množství sloupců, které v danou chvíli nepotřebujete. Místo SELECT * vracejte pouze nezbytné sloupce. Snižuje se tím objem přenášených dat a paměťová náročnost. Když potřebujete jen počty nebo součty, neposílejte do aplikace všechny řádky, ale nechte agregaci na databázi. Také si dejte pozor na neúmyslné kartézské součiny – vynechání JOIN podmínky může znásobit počet řádků a výkon katastrofálně spadnout.

První commit: uložte si výchozí bod Po inicializaci si nastavte jméno a e-mail, protože každá změna se k nim váže. Použijte git config --global user.name a git config --global user.email. Poté přidejte soubory do tzv. staging area příkazem git add . (tečka znamená všechny soubory). Následně proveďte commit: git commit -m "Popis změny". Zpráva by měla být krátká a výstižná, například "Přidán úvodní text" nebo "Oprava překlepu v návodu".

Před tím, než začnete spolupracovat s dalšími lidmi, naučte se větvit. Příkaz git branch nazev_vetve vytvoří novou větev, git checkout nazev_vetve na ni přepne. Větvení umožňuje vyvíjet funkce odděleně, aniž byste ohrozili stabilní verzi. Po dokončení práce větev sloučíte do hlavní větve příkazem git merge nazev_vetve. Konflikty při slučování jsou normální – Git vám ukáže, kde se liší, a vy ručně vyberete správný obsah.

První unit test obvykle vzniká s dobrým úmyslem, ale často končí jako zbytečná zátěž. Než začnete psát testy, musíte si ujasnit, co se od nich očekává. Unit test nemá dokazovat, že program funguje, ale že se chová podle definovaných pravidel. Měl by být rychlý, izolovaný a čitelný. Pokud test běží déle než pár sekund nebo závisí na databázi či síti, není to unit test, ale integrační test. To je první věc, na kterou je třeba myslet.

V neposlední řadě pozor na algoritmus podpisu. Knihovny pro JWT někdy umožňují v hlavičce tokenu specifikovat typ algoritmu, což vede ke známému zranitelnosti „algorithm confusion". Pokud server podporuje symetrický i asymetrický podpis, může útočník podepsat token veřejným klíčem, který server považuje za tajný klíč. Tomu se vyhnete tím, že povolíte pouze jeden konkrétní algoritmus, a to nejlépe asymetrický, jako je RS256. Také si pohlídejte, že server nepřijímá tokeny bez podpisu nebo s prázdným podpisem.

Verzování nemusí být žádná magie. Git je nástroj, který sleduje změny ve vašich souborech a umožňuje se kdykoli vrátit k dřívějšímu stavu. Než začnete, nainstalujte si Git a otevřete terminál ve složce projektu. Pak spusťte příkaz git init, který vytvoří skrytou složku .git. Od té chvíle Git ví, že má hlídat všechny soubory v daném adresáři.

Typická chyba začátečníků je commitovat až po hodinách práce. Raději dělejte menší commity, které odpovídají jedné logické změně. Pokud něco pokazíte, snáze najdete viníka a vrátíte se k předchozímu stavu. Pamatujte, že commit je jako uložená hra – čím častěji ukládáte, tím méně ztratíte.

Když začnete psát první test, nemusíte psát testy pro všechno hned. Vyberte si jednu funkci, která je pro aplikaci klíčová, a napište pro ni tři až pět testů. Pokryjte běžný scénář, okrajové případy a chybové stavy. Například u funkce pro byt v panelákuýpočet slevy otestujte běžnou slevu, nulovou slevu, maximální slevu a případ, kdy je sleva větší než cena. Tím zjistíte, jak se funkce chová v extrémních situacích, a často odhalíte chyby, které byste jinak přehlédli.

Dalším zásadním problémem je délka platnosti tokenu. Pokud nastavíte expiraci na dny nebo týdny, vytváříte časově neomezené zadní vrátka. Útočník, který token získá, ho může používat dlouho. Řešením jsou krátkodobé tokeny s dobou platnosti v minutách. Pro pohodlí uživatele pak použijte takzvaný refresh token, který je uložen na bezpečném místě, například v HttpOnly cookie, a slouží pouze k získání nového přístupového tokenu. Tyto dva typy tokenů by měly mít odlišné struktury i doby platnosti.

Čemu se vyhnout při prvních pokusech o testování Častým omylem začátečníků je, že hned chtějí automatizovat nebo testovat složité systémy. Přitom firmy často potřebují lidi na manuální testování, kde stačí pečlivost a systematičnost. Vyhněte se také tomu, abyste posílali životopis bez konkrétních příkladů. Místo „mám zájem o IT" napište, že jste testovali konkrétní web nebo aplikaci a našli jste v ní chyby. Pokud nemáte žádné vzorové výstupy, vytvořte si je sami. Zkuste si vzít veřejně dostupnou aplikaci a popište ji z pohledu testera: co je v ní rizikové, co byste testovali jako první a proč.class=

댓글목록

등록된 댓글이 없습니다.