Authentification

L’API de données identifie un utilisateur réel de l’espace. Pas un « compte de service », pas une identité technique : votre programme agit sous le nom de quelqu’un, avec ses droits, et ses actions portent sa signature dans l’historique.

01Les quatre informations

Information	Exemple	Où la trouver
Adresse	`https://kouassi.madata.app`	Celle de votre espace.
Base	`prod_kouassi`	`prod_` suivi du sous-domaine.
Identifiant	`[email protected]`	L’email de connexion de l’utilisateur.
Clé d’API	`a1b2c3…`	Créée dans l’espace, affichée une seule fois.

02Créer une clé d’API

Ouvrez vos préférences. Dans l’espace, cliquez sur votre nom en haut à droite, puis Préférences.
Onglet « Mes connecteurs ». Descendez jusqu’à la carte Clés API.
« Nouvelle clé API ». Donnez-lui une description qui dira, dans six mois, quelle intégration débrancher : « synchro boutique en ligne », pas « test ».
Confirmez votre mot de passe. L’espace vous le redemande : créer une clé, c’est ouvrir une porte.
Copiez la clé. Elle n’est affichée qu’une fois. L’espace n’en garde qu’une empreinte et ne peut pas la ré-afficher. Perdue, une clé se remplace, jamais ne se retrouve.

Une clé vaut un mot de passe

Elle donne accès à tout ce que son porteur peut voir et faire, sans mot de passe ni double authentification. Elle vit dans un gestionnaire de secrets ou une variable d’environnement, jamais dans un dépôt de code, jamais dans une capture d’écran envoyée au support.

Une clé par intégration

Une clé par programme, nommée. Le jour où un prestataire part ou où un serveur est remplacé, vous révoquez une clé au lieu de tout changer.

03Obtenir le uid

Le uid est l’identifiant numérique de l’utilisateur dans l’espace. Toutes les méthodes de execute_kw le réclament.

pythonauthenticate

common = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/common")
uid = common.authenticate(DB, LOGIN, CLE, {})

if not uid:
    raise SystemExit("cle refusee : verifiez la base, l'identifiant et la cle")

authenticate renvoie false, pas une erreur, quand les identifiants ne passent pas. Le quatrième argument est un dictionnaire d’informations sur le client appelant : {} convient.

Trois causes à un refus

La base n’est pas prod_<espace>.
L’identifiant n’est pas l’email de connexion.
La clé a été révoquée, ou c’est le mot de passe qui a été collé alors que la double authentification est active.

04Double authentification

Tant que la double authentification n’est pas activée sur un compte, son mot de passe fonctionne aussi sur l’API. Dès qu’elle l’est, le mot de passe est refusé par l’API et seule une clé d’API passe. C’est voulu : un second facteur ne se saisit pas dans un script, et une clé se révoque d’un clic.

La bonne pratique, dans les deux cas

Utilisez une clé même sans double authentification. Le code qui colle un mot de passe d’utilisateur casse le jour où ce dernier le change, et donne à votre programme bien plus que l’accès aux données : l’interface aussi.

05Session web (cookie)

Le troisième canal, /web/dataset/call_kw, est celui du navigateur. Il n’accepte pas de clé en en-tête : il veut un cookie de session, obtenu par /web/session/authenticate.

bashouvrir une session, puis appeler

# 1. ouvrir la session et garder le cookie
curl -s -c cookies.txt https://<espace>.madata.app/web/session/authenticate \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","params":{"db":"prod_<espace>",
        "login":"[email protected]","password":"votre-cle-d-api"}}'

# 2. appeler avec le cookie
curl -s -b cookies.txt https://<espace>.madata.app/web/dataset/call_kw \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"call","params":{
        "model":"res.partner","method":"search_count",
        "args":[[]],"kwargs":{}}}'

Ce canal sert surtout à rejouer à l’identique ce que fait l’interface, quand une méthode dépend du contexte de session. Pour tout le reste, XML-RPC et JSON-RPC sont plus simples : rien à garder entre deux appels.

La session expire

Une session inactive finit par expirer et l’appel suivant renvoie « Madata Session Expired » (code 100). Votre programme doit savoir se reconnecter. Sans état, XML-RPC n’a pas ce problème.

06Une clé n’élève jamais les droits

Trois barrières s’appliquent à chaque appel, dans cet ordre.

Barrière	Ce qu’elle contrôle
Droits d’accès	Le droit de lire, créer, modifier ou supprimer un modèle. Un utilisateur sans accès à la comptabilité ne lira aucune écriture, quelle que soit la clé.
Règles d’enregistrement	Quelles lignes du modèle il voit. Un commercial peut ne voir que ses propres opportunités : l’API lui en montre autant, ni plus ni moins.
Société active	Les enregistrements de la société courante. Voir multi-société.

Autrement dit : votre programme ne verra jamais rien de plus que ce que son porteur voit à l’écran. Si un appel renvoie moins que prévu, c’est presque toujours une question de droits, pas de code.

Le bon porteur

Choisissez l’utilisateur en fonction du travail. Une synchronisation de catalogue n’a pas besoin des droits comptables. Un utilisateur dédié, correctement limité, est plus sûr qu’une clé d’administrateur, et l’historique dira ensuite qui a fait quoi.

07Révoquer

Dans Préférences → Mes connecteurs → Clés API, la liste montre chaque clé, sa description et sa date de création. L’icône de corbeille la supprime : l’appel suivant du programme concerné échoue immédiatement.

Révoquez sans hésiter quand une clé a pu fuiter, quand l’intégration qu’elle servait est arrêtée, ou quand la personne qui la portait quitte l’entreprise. En créer une nouvelle prend trente secondes.