Différences

Ci-dessous, les différences entre deux révisions de la page.

--- informatique:api-rest:postgrest [2022/03/16 16:04] – [Écrire (CREATE/UPDATE) via l'API] …DELETE bertrand
+++ informatique:api-rest:postgrest [2023/10/11 11:17] (Version actuelle) – [Création de la base de données] bertrand
@@ Ligne 3: / Ligne 3: @@
 [[https://postgrest.org/en/v6.0/|PostgREST]]
-Traduction réduite et adapté des tutoriels [[https://postgrest.org/en/v6.0/tutorials/tut0.html]] et [[https://postgrest.org/en/v7.0.0/tutorials/tut1.html]] (voir aussi la série sur [[https://gis-ops.com/postgrest-tutorial-installation-and-setup/]] et [[https://gis-ops.com/postgrest-postgis-api-tutorial-geospatial-api-in-5-minutes/]])\\
+Traduction réduite et adapté des tutoriels [[https://postgrest.org/en/stable/tutorials/tut0.html]] et [[https://postgrest.org/en/stable/tutorials/tut1.html]] (voir aussi la série sur [[https://gis-ops.com/postgrest-tutorial-installation-and-setup/]] et [[https://gis-ops.com/postgrest-postgis-api-tutorial-geospatial-api-in-5-minutes/]])\\
 Voir aussi [[https://g-ernaelsten.developpez.com/tutoriels/PostgREST/|tuto sur developpez.com]] qui parle aussi de l'accès en PHP depuis Symfony/Laravel…
@@ Ligne 62: / Ligne 62: @@
   ('Paris'), ('Lyon'), ('Grenoble'), ('Brest');
 </code>
+<note important>Si vous avez des dates (created_at, updated_at…) il est utile de définir le fuseau horaire :
+<code sql>
+ALTER DATABASE nom_de_la_base SET timezone TO 'Europe/Paris';
+# la commande ci-dessous ne le fait que pour la session en cours :
+set time zone 'Europe/Paris'; # ou 'CET' = Centre Europe
+# les commandes suivantes permettent de vérifier avant/après :
+show timezone; # par défaut -> UTC
+select NOW(); # UTC : 2023-10-11 08:12:13.955544+00 et en CET (en été) : 2023-10-11 10:12:13.955544+02</code>
+</note>
 [FACULTATIF] Si on a utilisé une image docker PostGIS, on peut ajouter une colonne geometry :
@@ Ligne 147: / Ligne 157: @@
 </code>
+<note tip>Pour tester les requêtes on peut utiliser [[https://curl.se|curl]], et éventuellement faire un pipe sur //json query// (jq) pour que soit bien plus lisible le JSON retourné.\\ Il y a aussi l'utilitaire [[https://insomnia.rest/download|Insomnia]], et également Postman qui pousse plutôt la solution web, mais propose également un [[https://learning.postman.com/docs/getting-started/installation-and-updates/#installing-postman-on-linux|client lourd]], malheureusement, ni l'un ni l'autre ne sont libres ou Open Source !</note>
 ===== Utilisateur autorisé en écriture =====
-Dans la partie précédente, nous avons juste défini un utilisateur anonyme limité en lecture. Nous allons ajouter un utilisateur //sig_user// identifié pour des accès en écriture sur la base via l'API PostgRest.
+Dans la partie précédente, nous avons juste défini un utilisateur anonyme limité en lecture.\\
+Pour écrire, il faut définir 2 niveaux de protection, le premier est un utilisateur //sig_user// avec des droits d'accès en écriture sur la base PostgreSQL, le second est un token JWT d'accès à l'API PostgREST. Au final, l’instanciation du conteneur PostgREST recevra donc 2 mots de passe distinct, celui de l'utilisateur de la base (ou plus exactement du schéma), et celui de token.
 Cette partie s'inspire très largement du tuto [[https://postgrest.org/en/v7.0.0/tutorials/tut1.html]]
-==== Création utilisateur ====
+==== Création utilisateur et AFFECTATION DES DROITS ====
 <code sql>
 create role sig_user nologin;
@@ Ligne 159: / Ligne 172: @@
 grant usage on schema location to sig_user;
 grant all on location.town to sig_user;
-grant usage, select on sequence location.town_town_id_seq to sig_user;
+grant usage, select on sequence location.town_town_id_seq to sig_user; # <------------- outre la table, il faut aussi les droits sur la séquence !!
 </code>
-<note tip>Lors du déploiement, les droits seront à définir sur toutes les tables, vues et fonctions :
+<note warning>Lors du déploiement, les droits seront à définir sur toutes les tables, vues et fonctions utiles :
 <code bash>
 GRANT SELECT ON ALL TABLES IN SCHEMA location TO sig_user;
@@ Ligne 167: / Ligne 180: @@
 </code></note>
 ==== Création du jeton (token) pour sécuriser ====
-L'authentification du client avec l'API utilise les jetons web JSON (JSON Web Tokens). Ce sont des objets JSON chiffré utilisant un mot de passe connu seulement par nous et le serveur.
+<note>pour mieux comprendre les JWT, voici un tuto de 11mn : https://grafikart.fr/tutoriels/json-web-token-presentation-958\\
+La première partie du token correspond à l'en-tête en JSON, c'est à dire //{"alg": "HS256","typ": "JWT"}//, la seconde le //payload//, dans notre cas //{"role":"sig_user"}//, et la troisième est la signature du token, définit à partir des 2 premières parties et du mot de passe.\\
+Voir aussi, pour aller plus loin : https://www.rfc-editor.org/rfc/rfc7519</note>
+L'authentification du client avec l'API utilise les jetons web JSON (JSON Web Tokens). Ce sont des objets JSON chiffré utilisant un mot de passe connu seulement par nous et le serveur. Comme les clients ne connaissent pas le mot de passe, ils ne peuvent pas altérer le contenu de leurs jetons. PostgREST détectera les jetons contrefaits et les rejettera.
 Création d'un mot de passe de 32 caractères:\\
@@ Ligne 189: / Ligne 205: @@
 jwt-secret = "<the password you made>"
 </file>
+<note tip>Si on crée le serveur postgREST via un conteneur Docker, au lieu de ce fichier, on précise ce mot de passe via la clé //PGRST_JWT_SECRET// dans le docker-compose.yaml</note>
 ==== Création du jeton JSON Web Token (JWT) ====
 Plus d'informations sur les [[wpfr>JWT]]\\
 Rendez-vous sur [[https://jwt.io/#debugger-io|jwt.io]] puis suivez-les instructions comme sur le schéma:\\
 {{https://postgrest.org/en/v7.0.0/_images/tut1-jwt-io.png}}
 À quelques adaptations près :
   - À la place du //HEADER//, il faut avoir le JSON : {"typ":"JWT","alg":"HS256"}
@@ Ligne 199: / Ligne 216: @@
   - À la place de //secret//, saisissez le mot de passe créé au § précédent.
   - Copier le jeton
+**Ne pas oublier que le rôle et le mot de passe doivent appartenir à l'utilisateur qui aura accès a la base de données. Si l'utilisateur ne possède pas le rôle ou le mot de passe utilisé lors de la création du TOKEN, l'accès à la base de données lui sera refusé.**
 En ligne de commande mettre en place le token sur le ou les serveurs qui doivent écrire :
@@ Ligne 216: / Ligne 235: @@
     -d '{"town_name": "Bordeaux"}'
     -
-# supprimer :
+# supprimer la ville ayant pour id 3 :
-curl "http://localhost:3000/area?area_id=eq.39" \
+curl "http://localhost:3000/town?town_id=eq.3" \
     -X DELETE \
     -H "Prefer: return=representation" \

DokuWiki ArAr - CDRC-C14

Outils pour utilisateurs

Outils du site

Différences

Outils de la page