first week

órai anyagok/week01/sections/01-http-https.tex

@@ -0,0 +1,205 @@
+\section{HTTP és HTTPS}
+
+\begin{frame}{Mi a HTTP?}
+\footnotesize
+Amikor a böngésződ betölt egy weboldalt, vagy amikor egy mobilalkalmazás adatot kér egy szervertől, a háttérben szinte mindig a \textbf{HTTP} (HyperText Transfer Protocol) protokoll zajlik. Ez egy egyszerű, szövegalapú szabályrendszer arra, hogyan kérjen adatot egy kliens (pl. böngésző) egy szervertől, és hogyan válaszoljon arra a szerver.
+
+\begin{itemize}
+\item Kliens-szerver kommunikáció alapja a weben
+\item \textbf{Állapotmentes (stateless)} protokoll: a szerver alapból nem emlékszik az előző kérésekre -- minden kérés önmagában, a többitől függetlenül értelmezhető
+\item \textbf{Request-Response} modell: a kliens kér, a szerver válaszol
+\item Alapértelmezett port: 80 (HTTP), 443 (HTTPS)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{HTTP verziók}
+\footnotesize
+A HTTP protokoll az évek során több jelentős verzióváltáson esett át, mindig azzal a céllal, hogy gyorsabbá és hatékonyabbá tegye a weben zajló kommunikációt. Ma leggyakrabban HTTP/1.1-gyel és HTTP/2-vel találkozunk, de egyre több nagy szolgáltatás áll át a legújabb HTTP/3-ra is.
+
+\begin{block}{}
+\begin{itemize}
+\item \textbf{HTTP/1.1} (1997) -- perzisztens kapcsolat, azaz nem kell minden kéréshez új TCP-kapcsolatot nyitni
+\item \textbf{HTTP/2} (2015) -- multiplexing (több kérés egyszerre, egy kapcsolaton), bináris protokoll
+\item \textbf{HTTP/3} (2022) -- a QUIC protokollra épül, UDP alapú, még gyorsabb kapcsolatfelépítés
+\end{itemize}
+\end{block}
+\end{frame}
+
+\begin{frame}{HTTP vs HTTPS}
+\footnotesize
+A sima HTTP-n keresztül küldött adatokat bárki, aki hozzáfér a hálózati forgalomhoz (pl. egy nyílt wifin), el tudja olvasni, sőt módosítani is. A \textbf{HTTPS} ezt a problémát oldja meg azzal, hogy a HTTP forgalmat egy titkosítási réteg (SSL/TLS) fölé csomagolja.
+
+\begin{columns}
+\begin{column}{0.48\textwidth}
+\begin{block}{HTTP}
+\begin{itemize}
+\item Titkosítatlan kommunikáció
+\item Lehallgatható, módosítható (Man-in-the-Middle támadás)
+\item Port 80
+\end{itemize}
+\end{block}
+\end{column}
+\begin{column}{0.48\textwidth}
+\begin{block}{HTTPS = HTTP + SSL/TLS}
+\begin{itemize}
+\item Titkosított kommunikáció
+\item SSL/TLS tanúsítvány szükséges hozzá
+\item Port 443
+\end{itemize}
+\end{block}
+\end{column}
+\end{columns}
+\end{frame}
+
+\begin{frame}{Miért kötelező ma a HTTPS?}
+\footnotesize
+Régebben csak a bejelentkezős, kényes adatokat kezelő oldalak használtak HTTPS-t, ma viszont gyakorlatilag minden weboldalnak ezt kellene tennie -- több okból is.
+
+\begin{alertblock}{Fontos}
+Modern webalkalmazásoknál a HTTPS gyakorlatilag kötelező: a böngészők figyelmeztetést adnak a sima HTTP oldalakra, a keresőmotorok (SEO) hátrébb sorolják őket, és sok modern böngésző-funkció (pl. helymeghatározás, kamera) is csak HTTPS mellett engedélyezett.
+\end{alertblock}
+
+\begin{itemize}
+\item \textbf{Bizalom:} a felhasználó látja a lakat ikont, tudja, hogy az adatai védve utaznak
+\item \textbf{Integritás:} útközben senki nem tudja módosítani a forgalmat (pl. reklámot beszúrni)
+\item \textbf{Hitelesség:} a tanúsítvány igazolja, hogy tényleg azzal a szerverrel beszélünk, akivel hisszük
+\end{itemize}
+\end{frame}
+
+\begin{frame}{HTTP metódusok}
+\footnotesize
+Minden HTTP kérésnek van egy \textbf{metódusa}, ami megmondja, milyen műveletet szeretnénk végrehajtani az adott erőforráson. A REST API-k tervezésénél ez a metódusválasztás lesz az egyik legfontosabb döntésünk.
+
+\begin{tabular}{|l|p{7cm}|}
+\hline
+\textbf{Metódus} & \textbf{Jelentés} \\
+\hline
+GET & Erőforrás lekérése (csak olvasás, idempotens) \\
+POST & Új erőforrás létrehozása (nem idempotens) \\
+PUT & Erőforrás teljes frissítése (idempotens) \\
+PATCH & Erőforrás részleges frissítése (nem idempotens) \\
+DELETE & Erőforrás törlése (idempotens) \\
+HEAD & Mint GET, de csak fejlécek, body nélkül \\
+OPTIONS & Támogatott metódusok lekérése (CORS) \\
+\hline
+\end{tabular}
+\end{frame}
+
+\begin{frame}{Idempotencia -- miért számít?}
+\footnotesize
+Egy művelet \textbf{idempotens}, ha többszöri végrehajtása ugyanazt az eredményt adja, mint az egyszeri. Ennek nagy jelentősége van a gyakorlatban: ha egy kérés elakad a hálózaton és a kliens újraküldi, idempotens metódusnál (GET, PUT, DELETE) nem történik semmi baj -- a végállapot ugyanaz marad.
+
+\begin{block}{Példa}
+Ha kétszer küldöd el ugyanazt a \texttt{DELETE /api/users/123} kérést, a felhasználó csak egyszer törlődik -- a második kérés egyszerűen nem talál már semmit, amit törölnie kellene.
+\end{block}
+
+\begin{alertblock}{POST nem idempotens}
+Ha egy \texttt{POST}-tal új erőforrást hozunk létre, és véletlenül kétszer küldjük el (pl. dupla kattintás egy "Rendelés leadása" gombon), két különálló erőforrás (pl. két rendelés) jöhet létre!
+\end{alertblock}
+\end{frame}
+
+\begin{frame}[fragile]{HTTP Request felépítése}
+\footnotesize
+Egy HTTP kérés mindig ugyanabból a három részből épül fel: egy sorból, ami leírja, mit kérünk, néhány fejlécből, és opcionálisan egy törzsből (body).
+
+\begin{block}{Request struktúra}
+\begin{verbatim}
+GET /api/users/123 HTTP/1.1
+Host: example.com
+Accept: application/json
+Authorization: Bearer token123
+\end{verbatim}
+\end{block}
+
+\begin{itemize}
+\item \textbf{Request Line:} metódus (GET), útvonal (\texttt{/api/users/123}), protokoll verzió
+\item \textbf{Headers:} metaadatok kulcs-érték párok formájában (pl. milyen formátumot fogadunk el, kik vagyunk)
+\item \textbf{Body:} opcionális adatok, jellemzően POST, PUT, PATCH kéréseknél (pl. egy új felhasználó adatai JSON-ban)
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]{HTTP Response felépítése}
+\footnotesize
+A szerver válasza (response) hasonló szerkezetű, csak itt a kérés helyett egy \textbf{státuszkód} mondja meg, hogy sikerült-e a kérés.
+
+\begin{block}{Response struktúra}
+\begin{verbatim}
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{"id": 123, "name": "Alice"}
+\end{verbatim}
+\end{block}
+
+\begin{itemize}
+\item \textbf{Status Line:} protokoll, státuszkód (200), státusz szöveg (OK)
+\item \textbf{Headers:} metaadatok (pl. milyen formátumú a válasz törzse)
+\item \textbf{Body:} a válasz tényleges tartalma (HTML, JSON, XML, stb.)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{HTTP státuszkódok}
+\footnotesize
+A státuszkód egy háromjegyű szám, aminek az \emph{első számjegye} határozza meg a kategóriáját. Nem kell mind a száznál is több kódot fejből tudni -- elég, ha felismered, melyik kategóriába tartozik egy adott kód.
+
+\begin{itemize}
+\item \textbf{1xx -- Informational:} ritkán találkozunk vele, ideiglenes válasz (pl. 101 Switching Protocols)
+\item \textbf{2xx -- Success:} a kérés sikeres volt (200 OK, 201 Created, 204 No Content)
+\item \textbf{3xx -- Redirection:} a kliensnek egy másik URL-re kell mennie (301 Moved Permanently, 302 Found, 304 Not Modified)
+\item \textbf{4xx -- Client Error:} a kliens hibázott (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests)
+\item \textbf{5xx -- Server Error:} a szerver oldalán történt hiba, a kliens kérése önmagában helyes volt (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{REST API-ban gyakori státuszkódok}
+\footnotesize
+Egy jól megtervezett REST API mindig következetesen használja a státuszkódokat -- ez az egyik legfontosabb szokás, amit már most érdemes elsajátítani, hiszen a következő heteken folyamatosan ezekkel fogunk dolgozni.
+
+\begin{tabular}{|l|l|l|}
+\hline
+\textbf{Metódus} & \textbf{Sikeres} & \textbf{Hiba} \\
+\hline
+GET & 200 OK & 404 Not Found \\
+POST & 201 Created & 400, 409 Conflict \\
+PUT & 200 OK / 204 No Content & 400, 404 Not Found \\
+PATCH & 200 OK & 400, 404 Not Found \\
+DELETE & 204 No Content & 404 Not Found \\
+\hline
+\end{tabular}
+
+\begin{block}{Két gyakori, metódusfüggetlen eset}
+Autentikáció: 401 Unauthorized (nincs bejelentkezve), 403 Forbidden (be van jelentkezve, de nincs jogosultsága) \\
+Szerver hiba: 500 Internal Server Error, 503 Service Unavailable
+\end{block}
+\end{frame}
+
+\begin{frame}{HTTPS -- SSL/TLS Handshake}
+\footnotesize
+Mielőtt egy HTTPS kapcsolaton bármilyen adat átmenne, a kliens és a szerver egy rövid "kézfogáson" (handshake) esik át, aminek célja, hogy közösen kialakítsanak egy titkos kulcsot, amit csak ők ketten ismernek.
+
+\begin{enumerate}
+\item \textbf{Client Hello} -- a kliens elküldi, milyen titkosítási módokat támogat
+\item \textbf{Server Hello} -- a szerver kiválasztja a közösen támogatott titkosítást, és elküldi a tanúsítványát
+\item \textbf{Certificate Verify} -- a kliens ellenőrzi a tanúsítványt egy megbízható hitelesítésszolgáltatónál (CA)
+\item \textbf{Key Exchange} -- létrejön egy közös, szimmetrikus titkosító kulcs
+\item \textbf{Finished} -- innentől minden adat ezzel a kulccsal titkosítva utazik
+\end{enumerate}
+
+\begin{block}{SSL/TLS verziók}
+A TLS 1.2 még sok helyen használatban van, de a TLS 1.3 az ajánlott: gyorsabb kapcsolatfelépítés és erősebb, biztonságosabb titkosítási módok.
+\end{block}
+\end{frame}
+
+\begin{frame}{Összefoglalás -- HTTP/HTTPS}
+\footnotesize
+\begin{block}{HTTP/HTTPS alapok}
+\begin{itemize}
+\item HTTP: Request-Response modell, állapotmentes (stateless) protokoll
+\item HTTPS: titkosított HTTP, SSL/TLS handshake-kel
+\item HTTP metódusok: GET, POST, PUT, PATCH, DELETE -- mindegyiknek megvan a maga szerepe
+\item Idempotencia: GET, PUT, DELETE biztonságosan újraküldhető
+\item Státuszkódok: az első számjegy adja meg a kategóriát (1xx--5xx)
+\item REST API-ban leggyakrabban használt kódok: 200, 201, 204, 400, 401, 403, 404, 500
+\end{itemize}
+\end{block}
+\end{frame}