Contexte d'identité des tâches

Ce que vous saurez faire

Exécutez le travail en arrière-plan au nom de la personne qui l’a demandé, dans son organisation. Enregistrez ces deux informations dans la tâche, revérifiez-les à l’exécution et refusez toute tâche dont les détails ne correspondent pas.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• Comment l’API trouve le rôle de l’appelant à chaque requête, dans L’autorisation dans l’API : identité, puis adhésion, puis rôle.
• La sécurité au niveau des lignes comme deuxième verrou, dans Requêtes sûres pour chaque locataire.

Votre projet

• ~/projects/ticket-api à l’instantané end-of-m04, avec PostgreSQL et Azurite en cours d’exécution, et l’environnement virtuel actif.
• Deux terminaux, comme au module 2 : un exécute le fournisseur d’exercice (python -m idp), l’autre exécute l’API (fastapi dev). Un troisième terminal exécute les commandes de cette leçon.

Cette leçon copie tous les fichiers du module 5 : tâches en arrière-plan, accès de soutien, audit et changements des membres. Les deux prochaines leçons utilisent les autres fichiers. Après la copie, votre projet correspond à l’instantané end-of-m05.

Un chèque que la banque paie la semaine prochaine

Pensez à un chèque papier. Le lundi, Grace fait un chèque tiré sur le compte bancaire de Larkfield et le signe. Le fournisseur le présente à la banque la semaine suivante.

La banque ne paie pas simplement parce que le papier semble correct. Quand le chèque arrive, la banque pose de nouveau deux questions. Ce compte est-il encore ouvert? Grace a-t-elle encore le droit de signer pour ce compte? Si Larkfield a retiré ce droit à Grace le mercredi, la banque refuse le chèque, même s’il était valide le lundi.

Le chèque nomme aussi son compte. Personne ne peut écrire « payez ceci à partir du compte de Bramble Books » sur le chèque de Grace et recevoir l’argent. La banque vérifie que la signataire peut signer pour ce compte.

Le travail en arrière-plan dans l’API de billets suit la même logique. Une personne le demande aujourd’hui, le travail se fait plus tard, et l’autorisation doit être valide à ce moment-là.

Le problème : la requête se termine, mais pas le travail

Certains travaux sont trop lents pour une seule requête. Une exportation écrit les billets d’une organisation dans un fichier CSV. Avec beaucoup de données, cela peut prendre plusieurs minutes. L’API ne le fait donc pas pendant que la personne attend. Elle enregistre une tâche : une note qui dit « exportez ces billets ». Elle répond immédiatement avec 202 Accepted (accepté). Un programme distinct, le processus, trouve la tâche plus tard et fait le travail.

Cette séparation améliore la rapidité, mais elle rend inopérantes les vérifications du module 4. Chaque vérification y a lieu pendant une requête. L’API lit le jeton, trouve l’organisation dans le chemin et lit l’adhésion. Quand le processus exécute une tâche, il n’y a ni requête, ni jeton, ni chemin. La personne qui l’a demandée s’est peut-être déconnectée il y a une heure.

Que sait donc le processus? Seulement ce que dit la tâche. Voici un cas construit : un processus qui fait confiance à la tâche, sans deuxième vérification. Ce code n’est pas dans le projet.

La même tâche, exécutée vingt minutes plus tard. La ligne était correcte quand Sam a fait sa demande; l'autorisation a changé avant l'exécution.

Description textuelle du diagramme

Trois moments : à 10 h, Sam, membre du personnel, demande une exportation. À 10 h 05, Grace donne à Sam un accès en lecture seule. À 10 h 20, le processus exécute la tâche. Un processus qui fait confiance à la tâche utilise la ligne telle quelle. Il exporte donc tous les billets de Larkfield pour une personne qui n’a plus le droit d’exporter. Le cours a construit ce cas. Le processus du projet revérifie l’adhésion de Sam à 10 h 20 et refuse la tâche. Un membre en lecture seule n’a pas le droit d’exporter.

Deux choses tournent mal ici. D’abord, l’autorisation est périmée : l’API l’a vérifiée à 10 h, et le processus l’a utilisée à 10 h 20. Ensuite, la tâche elle-même peut être incorrecte. Un bogue, une ligne de base de données créée manuellement ou un message de file modifié peut nommer une mauvaise organisation. La personne peut n’en avoir jamais été membre. Un processus qui fait confiance à la tâche travaille alors dans la mauvaise organisation. Aucune personne connectée n’est là pour l’arrêter.

L’idée : enregistrer qui et où, puis revérifier

Revenons au chèque. Il contient trois faits : la signataire, le compte et le montant. Quand le chèque arrive, la banque vérifie la signataire et le compte dans leur état actuel.

Une tâche a besoin des trois mêmes faits. Ensemble, ils forment le contexte d’identité de la tâche :

• l’acteur : la personne qui a fait la demande, usr-sam;
• le locataire : l’organisation pour laquelle le travail est fait, larkfield;
• l’action de la tâche : une exportation exige export.create.

Le projet suit quatre règles :

1. Enregistrez le contexte de la requête vérifiée, jamais celui du corps de la requête. L’acteur vient du sub du jeton. Le locataire vient du chemin, après la vérification de l’adhésion. Un champ du corps ne peut changer ni l’un ni l’autre.
2. La ligne de la tâche est la seule source. La table jobs conserve actor_id et tenant_id. Si un message dans une file désigne la tâche, il contient son identifiant. Le processus compare tout autre champ du message avec la ligne et ne l’utilise jamais.
3. Revérifiez à l’exécution de la tâche. Le processus lit l’adhésion actuelle de l’acteur au locataire de la tâche. Il interroge la même fonction que l’API, decide(role, action). Si la réponse est non, le processus refuse la tâche et enregistre la raison.
4. Faites le travail dans le locataire. Chaque requête contient le locataire, et la sécurité au niveau des lignes est activée, comme pour chaque requête HTTP.

Vérifiez à la porte, puis revérifiez au bureau. L'API vérifie la requête; le processus vérifie la ligne de la tâche selon l'adhésion au moment de l'exécution.

Description textuelle du diagramme

Au moment de la requête, l’API vérifie le jeton de Sam, son adhésion à Larkfield et son rôle. Elle enregistre ensuite une ligne de tâche avec l’acteur et le locataire issus de ces vérifications. À l’exécution, il n’y a aucun jeton. Le processus prend la ligne et relit l’adhésion de Sam à Larkfield. Il demande à decide() si son rôle autorise export.create. Si oui, il écrit le fichier CSV. Sinon, il refuse la tâche et enregistre pourquoi. Un message de file désigne seulement la tâche.

Un petit exemple détaillé

Voici une tâche et quatre issues possibles à son exécution. Seuls les faits au moment de l’exécution changent.

La tâche indique	Au moment de l’exécution	Le processus fait
acteur usr-sam, locataire larkfield, export	Sam est membre du personnel chez Larkfield	terminé : le personnel peut faire export.create
acteur usr-sam, locataire larkfield, export	Grace a donné à Sam un accès en lecture seule	refusé : read_only may not export.create (le rôle en lecture seule ne peut pas créer d’exportation)
acteur usr-sam, locataire bramble, export	Sam n’a aucune adhésion chez Bramble Books	refusé : no membership in this organization (aucune adhésion à cette organisation)
acteur usr-sam, locataire larkfield, export	un message de file indique tenant_id: bramble	refusé : le message nomme une autre organisation que la tâche

Les deuxième et troisième lignes sont les deux échecs de la section précédente. La quatrième ligne correspond au chèque dont le nom du compte a été changé. Le processus ne croit pas le message; il le compare avec la ligne.

Ajouter les tâches à votre projet

Passez maintenant à la réalisation. Les fichiers viennent de l’instantané end-of-m05.

1. Arrêtez l’API avec Ctrl+C. Laissez le fournisseur en cours d’exécution. Dans ~/projects/ticket-api, copiez les fichiers du module 5 à partir de l’instantané :

   macOS et Linux

   S=../nextia-learning-labs/C23/snapshots/end-of-m05
   for d in contract docs migrations scripts tests ticket_api; do cp -R "$S/$d/." "$d/"; done

   Windows

   $S = "..\nextia-learning-labs\C23\snapshots\end-of-m05"
   foreach ($d in "contract","docs","migrations","scripts","tests","ticket_api") { Copy-Item -Recurse -Force "$S\$d\*" $d }

2. Ouvrez migrations/018_jobs.sql dans VS Code. Trouvez les deux colonnes tenant_id et actor_id. Les deux sont NOT NULL (non nulles), et les deux sont des clés étrangères. Les dernières lignes activent la sécurité au niveau des lignes pour jobs, comme pour les billets.

3. Appliquez les deux nouvelles migrations et rechargez les deux boutiques :

   python -m scripts.load --reset

   applied  018_jobs
   applied  019_audit_and_support_access
   Database is up to date (19 migrations).
   Loaded the small data in 0.6 s:
                        larkfield   bramble
     customers                 40        12
     tickets                  200        40
     messages                 331        58
     attachments               43        14
     documents                 36         3
     ai_runs                  294        69
     ticket_embeddings        200        40
     57 files uploaded to the object storage.
     3 messages have no ticket: they are in orphaned_messages.

4. Exécutez les tests :

   python -m pytest

   La dernière ligne est 234 passed, 1 deselected (234 réussis, 1 non sélectionné) : 16 de plus qu’à la fin du module 4. Les nouveaux tests sont dans tests/test_lifecycle.py, et ce module les explique tous.

5. Redémarrez l’API avec fastapi dev.

L’exportation de Sam, étape par étape

Dans le troisième terminal, obtenez un jeton pour Sam et conservez l’adresse des routes de Larkfield dans une variable :

macOS et Linux

TOKEN=$(python -m scripts.login --user usr-sam --print-access-token)
A=http://127.0.0.1:8000/v1/tenants/larkfield

Windows

$TOKEN = python -m scripts.login --user usr-sam --print-access-token
$A = "http://127.0.0.1:8000/v1/tenants/larkfield"

Les commandes curl ci-dessous sont identiques sous Windows, avec curl.exe à la place de curl. Dans Windows PowerShell 5.1, écrivez les guillemets d’un corps JSON sous la forme \", par exemple -d '{\"status\": \"open\"}'. Demandez une exportation des billets ouverts :

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"status": "open"}' $A/exports

{"job_id":"fe056555-413a-4272-a211-ae362a4bd4c5","tenant_id":"larkfield","actor_id":"usr-sam","kind":"export","status":"queued","reason":null,"result":null,"created_at":"2026-10-10T06:35:37.212348Z","finished_at":null,"download_url":null}

L’identifiant de votre tâche et les heures diffèrent. Le statut de la réponse est 202 Accepted : « Je l’ai reçue, et ce n’est pas encore terminé ». Regardez la ligne dans psql (docker compose exec db psql -U tickets -d tickets) :

SELECT job_id, tenant_id, actor_id, kind, params, status FROM jobs;

                job_id                | tenant_id | actor_id |  kind  |              params              | status
--------------------------------------+-----------+----------+--------+----------------------------------+--------
 fe056555-413a-4272-a211-ae362a4bd4c5 | larkfield | usr-sam  | export | {"team": null, "status": "open"} | queued
(1 row)

Sam a envoyé seulement {"status": "open"}. L’API a écrit larkfield et usr-sam à partir de ses propres vérifications. Sam pourrait-il plutôt envoyer l’organisation dans le corps, comme le suggère Tomás? Essayez. Le modèle refuse les champs inconnus :

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"tenant_id": "bramble"}' $A/exports

{"error":{"code":"invalid_request","message":"The request is not valid.","request_id":"f68ecd04788f","fields":["tenant_id"]}}

Exécutez maintenant le processus une fois. Il prend chaque tâche en attente, la vérifie et l’exécute :

python -m scripts.worker --once

fe056555-413a-4272-a211-ae362a4bd4c5  export for usr-sam in larkfield: done {'rows': 39, 'object_key': 'tenants/larkfield/exports/fe056555-413a-4272-a211-ae362a4bd4c5.csv'}

Le processus a écrit 39 billets ouverts dans un fichier sous tenants/larkfield/. Redemandez la tâche à l’API : curl -s -H "Authorization: Bearer $TOKEN" $A/exports/<your job ID>. La réponse indique maintenant "status":"done" (statut terminé), avec un download_url (URL de téléchargement). C’est un lien signé valide pendant cinq minutes, comme pour les fichiers du module 4. Ouvrez-le dans votre navigateur. Les premières lignes du fichier :

ticket_id,customer_id,subject,team,priority,status,created_at
T-30002,C-0022,Charged twice for order LK-182074,billing,1,open,2026-09-25 08:20:19+00:00
T-30005,C-0015,Verification code not arriving,login,2,open,2026-09-25 09:32:08+00:00

Le processus dans ticket_api/worker.py est court. La partie importante est la vérification :

with db.connection() as conn:
    role = repository.membership_role(conn, job["tenant_id"], job["actor_id"])
decision = decide(role, ACTION[job["kind"]])
if not decision.allowed:
    finish(db, job, "refused", f"{job['actor_id']}: {decision.rule} (checked when the job ran)")
    return "refused"

Il lit le rôle dans la base de données, maintenant, et utilise le même decide() que chaque requête. Ensuite, il fait le travail avec db.connection(job["tenant_id"]). La sécurité au niveau des lignes le limite donc aux lignes de Larkfield.

L’autorisation change avant l’exécution de la tâche

Reproduisez maintenant la chronologie du schéma. Sam demande une deuxième exportation, cette fois de tous les billets. Avant l’exécution du processus, Grace donne à Sam un accès en lecture seule. La route PATCH est nouvelle dans ce module, et Changements de cycle de vie l’explique. Sous Windows, définissez $GRACE comme vous avez défini $TOKEN.

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{}' $A/exports
GRACE=$(python -m scripts.login --user usr-grace --print-access-token)
curl -s -X PATCH -H "Authorization: Bearer $GRACE" -H "Content-Type: application/json" -d '{"role": "read_only"}' $A/members/usr-sam
python -m scripts.worker --once

{"job_id":"adeeb78b-3f7b-431e-99e9-856a44883429","tenant_id":"larkfield","actor_id":"usr-sam","kind":"export","status":"queued","reason":null,"result":null,"created_at":"2026-10-10T06:35:37.673063Z","finished_at":null,"download_url":null}
{"tenant_id":"larkfield","tenant_name":"Larkfield","role":"read_only"}
adeeb78b-3f7b-431e-99e9-856a44883429  export for usr-sam in larkfield: refused (usr-sam: read_only may not export.create (checked when the job ran))

La ligne indique encore usr-sam et larkfield, exactement comme avant. Les faits qui l’entourent ont changé, et le processus l’a constaté. Grace est propriétaire, donc elle peut lire le résultat avec curl -s -H "Authorization: Bearer $GRACE" $A/exports/<job ID>. Il indique "status":"refused" (statut refusé), avec la même raison. Sam ne peut pas le lire : un membre en lecture seule ne peut pas utiliser les routes d’exportation. Il reçoit donc 403.

Redonnez à Sam le rôle de membre du personnel avant de continuer :

curl -s -X PATCH -H "Authorization: Bearer $GRACE" -H "Content-Type: application/json" -d '{"role": "staff"}' $A/members/usr-sam

Une ligne de tâche falsifiée

L’API n’écrit jamais de tâche pour une organisation inaccessible à l’acteur. Mais le processus ne s’appuie pas sur cette garantie. Voici un cas construit : une personne ayant accès à la base de données insère une tâche pour Sam chez Bramble Books. Elle le fait sans passer par l’API. Dans psql :

INSERT INTO jobs (job_id, tenant_id, actor_id, kind) VALUES (gen_random_uuid(), 'bramble', 'usr-sam', 'export');

Exécutez ensuite le processus :

python -m scripts.worker --once

9909ec95-4970-43e5-8d2e-d33e82155a5f  export for usr-sam in bramble: refused (usr-sam: no membership in this organization (checked when the job ran))

La ligne nommait une organisation à laquelle Sam n’a aucune adhésion, donc la vérification a échoué. Aucun billet de Bramble n’a quitté la base de données.

Un message qui nomme une autre organisation

Les systèmes plus grands placent un message dans une file d’attente pour chaque tâche, et les processus lisent cette file. Le cours Mise à l’échelle des API et des charges de travail d’IA en construit une. Le processus de ce projet lit directement la table jobs. Mais run_job() accepte aussi le message qui désigne la tâche, pour montrer la règle :

if message and message.get("tenant_id") not in (None, job["tenant_id"]):
    finish(db, job, "refused", "the message names another organization than the job")
    return "refused"

Le processus n’utilise jamais le tenant_id du message pour choisir l’organisation. Il le compare seulement avec la ligne. Une différence indique un bogue ou une attaque, donc la tâche s’arrête. Un test envoie exactement ce message. Exécutez les tests des tâches :

python -m pytest tests/test_lifecycle.py -k "job or export or message" -v

tests/test_lifecycle.py::test_an_export_runs_as_the_person_who_asked PASSED
tests/test_lifecycle.py::test_a_job_is_refused_when_its_actor_was_removed_before_it_ran PASSED
tests/test_lifecycle.py::test_a_job_row_that_names_an_organization_its_actor_cannot_access_is_refused PASSED
tests/test_lifecycle.py::test_a_queue_message_with_another_organization_changes_nothing PASSED
tests/test_lifecycle.py::test_another_members_export_is_not_found_but_the_owner_sees_it PASSED
======================= 5 passed, 11 deselected in 1.35s =======================

Le dernier test montre une autre règle. Camille ne peut pas lire l’exportation de Sam (404), mais Grace, la propriétaire, le peut.

Chaque tâche laisse une trace

Le processus écrit un événement d’audit pour chaque exécution, à côté des événements de l’API. Opérations privilégiées explique la table d’audit. Pour l’instant, regardez les événements de cette leçon :

SELECT event_id, action, actor_id, tenant_id, result FROM audit_events ORDER BY event_id;

 event_id |       action        | actor_id  | tenant_id | result
----------+---------------------+-----------+-----------+--------
        1 | export.queued       | usr-sam   | larkfield | done
        2 | export.run          | usr-sam   | larkfield | done
        3 | export.queued       | usr-sam   | larkfield | done
        4 | member.role_changed | usr-grace | larkfield | done
        5 | export.run          | usr-sam   | larkfield | denied
        6 | member.role_changed | usr-grace | larkfield | done
        7 | export.run          | usr-sam   | bramble   | denied
(7 rows)

Chaque exécution refusée contient l’acteur et l’organisation de la ligne. Un propriétaire peut donc voir plus tard ce qu’une personne a tenté.

Pourquoi ne pas donner au processus sa propre identité puissante?

Amira pose la question évidente : « Le processus, c’est notre programme. Pourquoi ne pas lui donner un compte de service qui peut lire toutes les organisations, et sauter les vérifications? »

Kwame répond avec le chèque. Un employé de banque peut ouvrir tous les comptes, mais il ne décide pas quels chèques payer. C’est le droit de signature qui décide. Si le processus utilise ses propres droits, chaque tâche s’exécute avec ces droits. Une ligne falsifiée ou une tâche périmée peut alors tout lire.

Le projet limite donc les droits du processus. Le processus se connecte directement à la base de données. Pour prendre une tâche (claim()), il lit la table jobs de toutes les organisations, car il ne connaît pas encore l’organisation. Tout ce qui suit s’exécute au nom de l’acteur, dans l’organisation de la tâche. Le fournisseur possède aussi un client de service, export-worker. Un jeton pour ce client n’est membre d’aucune organisation. Un test du module 4, test_a_service_token_is_not_a_member_of_any_organization, vérifie qu’il reçoit 404.

Quand l’utiliser, et ce que cela coûte

Utilisez un contexte d’identité pour tout travail exécuté hors de la requête : exportations, importations, rapports planifiés, résumés IA de nombreux billets, courriels. Si le travail agit pour une personne dans une organisation, enregistrez la personne et l’organisation. Vérifiez-les à l’exécution du travail.

Les coûts sont faibles, mais réels :

• Une requête SQL de plus par tâche : la lecture de l’adhésion. Pour une tâche qui dure plusieurs minutes, c’est négligeable.
• Du travail refusé : si le rôle d’une personne change, sa tâche en attente échoue, et elle doit la redemander. C’est le bon résultat, mais la personne a besoin d’une raison claire. La colonne reason la fournit.
• Les tâches longues : la vérification a lieu au démarrage de la tâche. Une tâche qui dure une heure devrait revérifier entre les lots, sinon l’autorisation peut changer en cours d’exécution. Les exportations de ce projet sont courtes, donc une seule vérification suffit.
• Les nouvelles tentatives et les doublons : une file peut livrer un message deux fois. Une deuxième exécution ne doit pas refaire le travail. Le cours Mise à l’échelle des API et des charges de travail d’IA couvre les états des tâches, les nouvelles tentatives et les messages en double.

La suppression d’une organisation est aussi une tâche, dont l’acteur est un administrateur. Changements de cycle de vie l’exécute.

Erreurs courantes

Erreur courante

Le chargement s'arrête : les tables contiennent déjà des données

Symptôme : python -m scripts.load affiche The help-desk tables already have data. Run again with --reset to delete it and load again. (Les tables de soutien contiennent déjà des données. Relancez avec –reset pour les supprimer et les recharger.) Il n’affiche aucune ligne applied (appliqué).

Cause : sans --reset, le chargeur s’arrête avant d’appliquer 018 et 019. La table jobs n’existe donc pas encore.

Solution : exécutez python -m scripts.load --reset.

Erreur courante

Le processus n'affiche rien

Symptôme : python -m scripts.worker --once s’arrête immédiatement et n’affiche aucune ligne.

Cause : la file d’attente est vide. Chaque tâche s’exécute une fois. Une deuxième exécution du processus ne trouve donc rien.

Solution : demandez d’abord un nouvel export. Pour voir les anciennes tâches, utilisez SELECT job_id, status, reason FROM jobs; dans psql.

Erreur courante

403 quand Omar demande un export

Symptôme : {"error":{"code":"forbidden","message":"Your role may not do this (read_only may not export.create).", …}} (Votre rôle ne permet pas cette action. Le rôle read_only ne permet pas export.create.)

Cause : c’est le comportement attendu. La matrice d’accès accorde export.create uniquement aux propriétaires et au personnel.

Solution : utilisez le jeton de Sam ou de Grace.

Réinitialisation. python -m scripts.load --reset supprime toutes les tâches et recharge les deux boutiques. Si votre projet ne fonctionne plus, copiez l’instantané end-of-m05 avec votre fichier .env et votre dossier .idp.

Vérification des connaissances

Vérifiez votre compréhension

À 10 h, Camille (membre du personnel chez Larkfield) demande un export. À 10 h 10, Grace retire Camille de Larkfield. À 10 h 30, le processus exécute la tâche. Que se passe-t-il, et quelle ligne du processus prend cette décision?

Afficher la réponse

Le processus refuse la tâche : usr-camille: no membership in this organization (checked when the job ran) (usr-camille : aucune adhésion à cette organisation, vérifiée lors de l’exécution de la tâche). La ligne de la tâche indique toujours usr-camille et larkfield. Mais à 10 h 30, le processus lit l’adhésion de Camille avec repository.membership_role() et n’en trouve aucune. Donc, decide(None, "export.create") refuse l’action. Le processus n’écrit aucun fichier. Il consigne un événement d’audit export.run avec le résultat denied (refusé).

Vérifiez votre compréhension

Un collègue propose de mettre tenant_id et user_id dans le message de la file d'attente. Ainsi, le processus n'aurait pas besoin de lire la table jobs. Quel problème cela pose-t-il?

Afficher la réponse

Le message devient la source qui définit qui agit et dans quelle organisation. Toute personne pouvant écrire dans la file peut alors faire agir le processus dans une autre organisation ou sous une autre identité. Un bogue qui modifie un champ peut faire la même chose. Dans ce projet, la ligne de la tâche est la seule source. Le message contient l’identifiant de la tâche. Le processus compare seulement les autres champs à la ligne; toute différence entraîne le refus de la tâche. Le processus vérifie aussi l’adhésion au moment de l’exécution. Un message ne peut pas le faire à sa place.

Vérifiez votre compréhension

Pourquoi l'API prend-elle le locataire dans le chemin et l'acteur dans le jeton, plutôt que dans le corps de la requête? Utilisez la réponse 422 de cette leçon.

Afficher la réponse

L’API a vérifié le locataire du chemin : elle a lu l’adhésion et le rôle pour cette organisation précise. Le sub du jeton désigne la personne dont le fournisseur a signé l’identité. Un champ du corps contient ce que l’appelant saisit. Le modèle d’export interdit les champs inconnus. Ainsi, {"tenant_id": "bramble"} reçoit 422 avec "fields":["tenant_id"] (champs : tenant_id). Même sans cette règle, l’API ne lirait pas ce champ.

Récapitulatif

• Une tâche en arrière-plan s’exécute après la fin de la requête : sans jeton, sans chemin, peut-être sans personne connectée.
• Son contexte d’identité comprend l’acteur, le locataire et l’action. L’API enregistre l’acteur et le locataire à partir de ses propres vérifications, jamais à partir du corps.
• Le processus vérifie l’adhésion de l’acteur à nouveau lors de l’exécution de la tâche, avec le même decide(). Il a refusé l’export de Sam après que Grace lui a accordé seulement un accès en lecture. Il a aussi refusé une tâche falsifiée pour Bramble.
• Un message de la file d’attente désigne la tâche. Le processus compare les autres champs du message à la ligne et ne les utilise jamais.
• Votre projet correspond à end-of-m05 : 234 passed, 1 deselected (234 tests réussis, 1 test exclu).

Ensuite, une personne qui ne fait partie d’aucune organisation doit en aider une : Kwame, l’administrateur de la plateforme.

Leçon suivante : Opérations privilégiées