Limiter l’accès aux inscriptions des exposants est un projet pratique PostgreSQL destiné aux personnes qui connaissent les bases de SQL et souhaitent qu’un registre partagé respecte l’appartenance des données à chaque compte. Deux exposants doivent créer et gérer leurs propres inscriptions pour le chargement ; l’équipe organisatrice doit toujours pouvoir consulter l’ensemble et attribuer des stands. Vous établirez ces limites dans la base de données, puis les utiliserez pour un travail réel.
Un laboratoire guidé progresse de la visibilité des lignes aux contrôles des nouvelles valeurs, puis aux inscriptions terminées. Un défi indépendant change les artisans, la table et les enregistrements, et vous demande de fournir la même séparation fonctionnelle avec les outils déjà pratiqués. Chaque laboratoire prépare son propre environnement et ses données.
Ce que vous apprendrez
À l’issue de ce cours, vous saurez :
- distinguer une connexion ordinaire authentifiée du propriétaire d’une table et tester l’accès avec l’identité prévue ;
- distinguer les permissions sur les tables et les colonnes des lignes qu’un compte peut lire ou modifier ;
- supprimer les politiques permissives trop larges tout en conservant l’accès légitime de l’organisation ;
- protéger les lignes existantes et les valeurs proposées par INSERT/UPDATE grâce à du SQL de politiques réutilisable ;
- distinguer les lignes masquées, les écritures refusées et les échecs de connexion, y compris pour des écritures sans lignes renvoyées ;
- terminer de nouvelles inscriptions et les affectations de l’organisation sans modifier les enregistrements d’origine.
À qui s’adresse ce cours
Ce cours s’adresse aux personnes qui apprennent PostgreSQL et aux développeurs souhaitant pratiquer le contrôle de l’appartenance des enregistrements par la base de données.
Prérequis : Savoir naviguer dans un terminal et connaître les connexions PostgreSQL, les tables, SELECT/WHERE, INSERT et UPDATE. Les laboratoires expliquent les rôles, la sécurité des lignes, les expressions de politiques, les transactions et la syntaxe shell nécessaire avant leur utilisation. La programmation Python n’est pas requise.
Environnement d’apprentissage : LabEx fournit un Terminal prêt à l’emploi dans le navigateur, avec PostgreSQL, des inscriptions synthétiques et des comptes de base de données préparés séparément. Vous êtes l’opérateur qui teste chaque compte ; aucune installation locale de base de données ni aucun compte cloud n’est nécessaire.
Questions fréquentes
Ce cours enseigne-t-il l’authentification d’un site web ?
Le projet porte sur les permissions de véritables connexions à la base de données. Il n’implémente ni connexion web, ni contexte de locataire pour un compte applicatif partagé, ni pool de connexions. Les propriétaires de tables et les administrateurs restent des identités de confiance ; le cours ne promet pas de bloquer tous les canaux auxiliaires d’information.
Restreindre l’accès bloque-t-il toutes les écritures ?
Le registre terminé doit toujours accepter les insertions légitimes de chaque exposant ainsi que les modifications de ses coordonnées et quantités. L’organisateur ordinaire doit toujours pouvoir consulter tous les exposants et attribuer stands et frais. Tout refuser ne permet pas de terminer le projet.
Que faut-il livrer dans le défi ?
Vous enregistrez et appliquez du SQL de politiques autonome, puis terminez deux inscriptions de chargement définies avec les comptes des artisans concernés et de l’organisateur. Les enregistrements d’origine, les identités et les permissions préparées doivent rester intacts. Le défi utilise les mêmes outils et mécanismes que le laboratoire guidé.
