From 97fbebaa22fc38b4276e1e05ca41631bfdf96044 Mon Sep 17 00:00:00 2001
From: Santo Cariotti <santo@dcariotti.me>
Date: Thu, 1 Dec 2022 12:39:34 +0100
Subject: docs: Requests updated

---
 docs/chapters/setup.tex | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

(limited to 'docs/chapters/setup.tex')

diff --git a/docs/chapters/setup.tex b/docs/chapters/setup.tex
index 43aff83..fab0a4a 100644
--- a/docs/chapters/setup.tex
+++ b/docs/chapters/setup.tex
@@ -9,17 +9,31 @@ Imposteremo tutto il necessario per simulare l'attacco visto nel capitolo preced
 \end{itemize}
 
 \section{API}
-Nella realtà, come ad esempio l'API di Reddit \cite{REDDIT:1}, si espone un endpoint \emph{/api/v1/me/} dove \emph{v1} è la versione dell'API in cui si ritornano i dati per l'utente autenticato. E questa è una buona prassi, un endpoint che si può trovare più o meno in tutte le REST API.
 
-\textbf{Cosa proveremo a fare noi?} Proprio un'API che fa ciò, niente più e niente meno. Ci limiteremo però solo a controllare che il JWT passato è valido in modo da ritornare i dati dell'utente che noi pensiamo sia stato autorizzato.
+Prendendo ad esempio l'API REST di Github \cite{GITHUB:1}, si vede come, anche nella realtà, si usa un endpoint generale per visualizzare le informazioni di un determinato utente.
+
+\textbf{Cosa proveremo a fare noi?} Diamo per assodato che un utente è autorizzato a visualizzare quell'endpoint (e così anche i corrispettivi di PUT e DELETE) solo se è l'owner di quella risorsa o se ha permessi speciali: da staffer nel nostro caso. 
 \newline\newline
 Il codice di questo servizio è presente al link \underline{\url{https://git.dcariotti.me/m6-ie/tree/server}}.
 \newline\newline
-La parte incriminata è la route qui sotto. Qui si limita a ritornare la riga utente che corrisponde all'ID utente passato dall'header.
+La parte incriminata è la route qui sotto: controlla se l'utente dell'url è lo stesso del token di autorizzazione o altrimenti che l'utente dell'autorizazzione (il quale token è creato dal server) sia uno staffer.
 
 \begin{lstlisting}
-async fn get_user(claims: Claims) -> Result<Json<UserList>, AppError> {
-    match User::find_by_id(claims.user_id).await {
+async fn get_user(Path(user_id): Path<i32>, claims: Claims) -> Result<Json<UserList>, AppError> {
+    let claimed = match User::find_by_id(claims.user_id).await {
+        Ok(user) => user,
+        Err(_) => {
+            return Err(AppError::NotFound("User not found".to_string()));
+        }
+    };
+
+    if user_id != claimed.id {
+        if !(claimed.is_staff.unwrap()) {
+            return Err(AppError::Unauthorized);
+        }
+    }
+
+    match User::find_by_id(user_id).await {
         Ok(user) => Ok(Json(user)),
         Err(_) => Err(AppError::NotFound("User not found".to_string())),
     }
@@ -33,7 +47,7 @@ let token_data = decode::<Claims>(bearer.token(), &KEYS.decoding, &Validation::d
             .map_err(|_| AppError::InvalidToken)?;
 \end{lstlisting}
 
-infatti il problema sta nell'inizializzazione della codifica/decodifica di JWT, in particolare quando definiamo il secret, dato che non fa un controllo della sicurezza di tale stringa.
+Il problema sta nell'inizializzazione della codifica/decodifica di JWT, in particolare quando definiamo il secret, dato che non fa un controllo della sicurezza di tale stringa.
 
 \begin{lstlisting}
 static KEYS: Lazy<Keys> = Lazy::new(|| {
-- 
cgit v1.2.3-18-g5258

