Dorénavant, toutes les routes hydra utilisant d'autres méthode que la méthode GET requièrent une authentification basique à l'aide d'un token dans le header, afin que seul udata puisse les appler (pour l'instant).
Pour tous les appels de udata vers l'API hydra, il faut donc dorénavant passer le token dans le header HTTP sous la forme "Authorization": "Bearer API_TOKEN".
Le token en question peut être généré aléatoirement une fois, et stocké dans les secrets de l'infrastructure, appelé par uadata via le fichier de config.
magopian
commented
3 weeks ago
Fait suite : https://github.com/datagouv/hydra/pull/130/
Dorénavant, toutes les routes hydra utilisant d'autres méthode que la méthode GET requièrent une authentification basique à l'aide d'un token dans le header, afin que seul udata puisse les appler (pour l'instant).
Pour tous les appels de udata vers l'API hydra, il faut donc dorénavant passer le token dans le header HTTP sous la forme "Authorization": "Bearer API_TOKEN".
Le token en question peut être généré aléatoirement une fois, et stocké dans les secrets de l'infrastructure, appelé par uadata via le fichier de config.
La logique d'appel à hydra suite à une activité sur une ressource est située ici : https://github.com/opendatateam/udata/blob/master/udata/core/dataset/events.py.
Le
publish.delayse déclenche dans un worker, il faut donc démarrer les workers avecinv workpour pouvoir tester le publish.