Permissions Hasura - Kit'Asso Documentation

Vue d’ensemble

Kit’Asso utilise les permissions Hasura pour contrôler l’accès aux données. Hasura gère les autorisations au niveau GraphQL, ce qui remplace le mécanisme Row Level Security (RLS) natif de PostgreSQL. Philosophie de sécurité :

“Le public peut lire le contenu actif, les utilisateurs authentifiés (admin) peuvent tout gérer.”

Rôles :

public — Visiteurs non authentifiés (lecture seule du contenu actif)
user / admin — Utilisateurs authentifiés via Nhost Auth (CRUD complet)

Permissions par domaine

1. Contenu toujours visible (tools, categories, filters, tool_features, site_assets)

Rôle	SELECT	INSERT	UPDATE	DELETE
public	✅ Tous	❌	❌	❌
admin	✅ Tous	✅	✅	✅

Résultat : Les visiteurs voient tous les outils et catégories. Seuls les admins peuvent créer, modifier ou supprimer.

2. Contenu avec statut (workflows, tool_packs, quizzes)

Rôle	SELECT	INSERT	UPDATE	DELETE
public	✅ Uniquement `status = 'active'` (ou `is_active = true`)	❌	❌	❌
admin	✅ Tous (y compris drafts)	✅	✅	✅

Résultat : Les visiteurs ne voient que le contenu publié. Les admins voient et gèrent les drafts.

3. Contenu enfant (workflow_steps, quiz_questions, quiz_answers, quiz_recommendations)

Rôle	SELECT	INSERT	UPDATE	DELETE
public	✅ Uniquement si le parent est actif	❌	❌	❌
admin	✅ Tous	✅	✅	✅

Logique : La visibilité d’un step suit celle de son workflow parent. Si un workflow est en draft, ses steps ne sont pas visibles publiquement.

4. Quiz Responses (cas spécial)

Rôle	SELECT	INSERT	UPDATE	DELETE
public	❌	✅ (soumission de quiz)	❌	❌
admin	✅ (analytics)	✅	✅	✅

Résultat : Le public peut soumettre des réponses de quiz mais ne peut pas les lire. Les admins accèdent aux données pour l’analytics.

5. Pack Tools (table de jonction)

Rôle	SELECT	INSERT	UPDATE	DELETE
public	✅ Tous	❌	❌	❌
admin	✅ Tous	✅	✅	✅

Configuration dans Hasura

Comment configurer les permissions

Ouvrez la console Hasura de votre projet Nhost
Sélectionnez une table (ex: tools)
Allez dans l’onglet Permissions
Définissez les règles pour chaque rôle :

Exemple : table tools, rôle public :

SELECT : ✅ Autorisé, sans filtre (toutes les lignes)
INSERT/UPDATE/DELETE : ❌ Non autorisé

Exemple : table workflows, rôle public :

SELECT : ✅ Autorisé, avec filtre : { "status": { "_eq": "active" } }
INSERT/UPDATE/DELETE : ❌ Non autorisé

Exemple : table workflows, rôle admin :

SELECT : ✅ Autorisé, sans filtre
INSERT/UPDATE/DELETE : ✅ Autorisé

Patterns de permissions

Pattern 1 : Public read, Admin CRUD

Tables : tools, categories, filters, tool_features, site_assets Tous les visiteurs peuvent lire. Seuls les admins peuvent modifier.

Pattern 2 : Public read active only, Admin read all

Tables : workflows, tool_packs, quizzes Le public ne voit que le contenu avec status = 'active'. Les admins voient tout.

Pattern 3 : Public read via parent

Tables : workflow_steps, quiz_questions, quiz_answers, quiz_recommendations La visibilité dépend du statut du parent (workflow ou quiz).

Pattern 4 : Public insert only

Tables : quiz_responses Le public peut soumettre des données (réponses quiz) mais ne peut pas les consulter.

Tester les permissions

Test 1 : Visiteur non authentifié

// Sans token JWT — rôle "public"
const result = await nhost.graphql.request({
  query: '{ tools { id name } }'
});
// ✅ Retourne tous les outils

const result2 = await nhost.graphql.request({
  query: '{ workflows { id title status } }'
});
// ✅ Retourne uniquement workflows avec status = 'active'

Test 2 : Admin authentifié

// Après nhost.auth.signIn()
const result = await nhost.graphql.request({
  query: '{ workflows(where: { status: { _eq: "draft" }}) { id title } }'
});
// ✅ Retourne les drafts

const result2 = await nhost.graphql.request({
  query: `mutation {
    insert_tools_one(object: { name: "Test", description: "Test tool", pricing_tier: "Gratuit" }) {
      id
    }
  }`
});
// ✅ Création autorisée

Test 3 : Insertion publique bloquée

// Sans authentification
const result = await nhost.graphql.request({
  query: `mutation {
    insert_tools_one(object: { name: "Hack", description: "Test" }) { id }
  }`
});
// ❌ Erreur : permission denied

Bonnes pratiques

✅ À faire

Toujours tester les permissions avec un utilisateur non authentifié avant déploiement
Utiliser des filtres Hasura pour le contenu avec statut
Documenter les permissions dans la console Hasura

❌ À éviter

Ne jamais exposer des données sensibles au rôle public
Ne pas créer de permissions trop permissives (ex: public avec CRUD)
Ne pas oublier les tables enfants quand on restreint un parent

Ressources

Database Schema

Structure complète des 10 tables

Nhost & GraphQL

Architecture backend

API Layer

Abstractions qui respectent les permissions automatiquement

Nhost Docs

Documentation officielle

Base de données

​Vue d’ensemble

​Permissions par domaine

​1. Contenu toujours visible (tools, categories, filters, tool_features, site_assets)

​2. Contenu avec statut (workflows, tool_packs, quizzes)

​3. Contenu enfant (workflow_steps, quiz_questions, quiz_answers, quiz_recommendations)

​4. Quiz Responses (cas spécial)

​5. Pack Tools (table de jonction)

​Configuration dans Hasura

​Comment configurer les permissions

​Patterns de permissions

​Pattern 1 : Public read, Admin CRUD

​Pattern 2 : Public read active only, Admin read all

​Pattern 3 : Public read via parent

​Pattern 4 : Public insert only

​Tester les permissions

​Test 1 : Visiteur non authentifié

​Test 2 : Admin authentifié

​Test 3 : Insertion publique bloquée

​Bonnes pratiques

​✅ À faire

​❌ À éviter

​Ressources