Produits Entr'ouvert » Passerelle

J'ai regardé et pas tout compris, sans avoir non plus réussi à savoir si ces deux api servent vraiment le même objectif.

Déjà, la doc de http2sms a été mise à jour récemment (la page indique 18/05/2020) sans mention de déprécation aucune (https://docs.ovh.com/fr/sms/envoyer_des_sms_depuis_une_url_-_http2sms/).

Ensuite, l'API /sms/{serviceName}/jobs, il n'y a rien du tout pour spécifier un utilisateur SMS comme avec http2sms. Sans avoir été vérifier je suppose qu'on a un serviceName commun à tous les clients et qu'on a créé pour chacun un utilisateur, donc on ne peut pas utiliser cette API (du moins, sans comprendre comment lui donner un utilisateur à manger).

Il faut aussi noter que l'usage de cette API est nettement moins simple, il faut dépendre du client python ovh, ou implémenter le système de signature qui va bien. En plus il faudra gérer des API keys côté OVH, dont je ne suis pas sûr qu'on puisse en générer sans date d'expiration.

Bref, pas fun, sauf si je passe complètement à côté du truc.

Valentin Deniaud a écrit :

Bref, pas fun, sauf si je passe complètement à côté du truc.

(Vu ensemble au bureau)

En fait ça changera notre façon de gérer les SMS OVH, en achetant un compte SMS dédié pour chaque client (qui aura son serviceName genre sms-xxx), puis un token d'utilisation permanent lié à ce compte sms-xxx via https://eu.api.ovh.com/createToken/index.cgi?GET=/sms&GET=/sms/sms-xxx/jobs&POST=/sms/sms-xxx/jobs. C'est le résultat de cette création de token qu'il faudra renseigner dans le connecteur SMS.

Ca sera nettement plus facile à suivre dans l'interface OVH, pas de "mix" bizarre entre utilisateur d'API et expéditeurs, etc. Et plus facile aussi de suivre la facturation, etc.

Cela signifie cependant qu'il faut créer un nouveau connecteur car l'actuel, qui utilise http2sms, devra perdurer quelques temps.

On peut aussi choisir de créer un nouveau endpoint dans le connecteur actuel... mais je ne sais pas si ça va être clair.

Ouaip :

Si vous gérez plusieurs comptes SMS (serviceName : sms-XXXX-1, sms-XXXXX-2 …) vous pouvez transférer des crédits entre vos différents comptes. Pour cela utilisez la méthode POST /sms/{serviceName}/transferCredits en indiquant le compte SMS à débiter, celui à créditer et enfin le montant de crédits à transférer.

Ce mécanisme est très intéressant pour gérer plusieurs comptes SMS de façon indépendante notamment pour de la revente à différents acteurs. Pour isoler les comptes vous devez mettre en place des Tokens distincts afin d’isoler les droits. Cette opération se réalise au moment de créer vos Tokens d’application, dans les droits vous aurez à spécifier explicitement que telle application n’a des droits que sur un ServiceName spécifié dans les url autorisées.

C'est un peu casse couille les histoires de tokens par contre, on dirait des signatures Publik.

Valentin Deniaud a écrit :

gérer des API keys côté OVH, dont je ne suis pas sûr qu'on puisse en générer sans date d'expiration

(on peut)

Benjamin Dauvergne a écrit :

C'est un peu casse couille les histoires de tokens par contre, on dirait des signatures Publik.

Ouais, pour bien faire il faudrait créer un token par client, et le restreindre à POST /sms/{LeServiceNameDuClient}/jobs.
Si on estime que c'est lourdingue, ça sera possible d'avoir le même token pour tous les clients qui donne accès à POST /sms/*/jobs, mais bon.
Btw un token c'est en fait trois paramètres, ça occupera de toute façon du temps de copier coller (https://docs.ovh.com/fr/api/api-premiers-pas/).

Bon Thomas avait déjà dit tout ça, j'ai lu trop en diagonale.

On avait un peu les yeux dans nos poches, bien entendu il existe /sms/{serviceName}/users/{login}/jobs qui permet de faire la même chose que http2sms...

Ensuite il y a toute l'API en /users/ qui devrait permettre de suivre correctement la consommation, si on a envie de mettre quelque chose comme ça en place.

Donc j'en reviendrais bien au point du départ du ticket, simplement mettre à jour l'endpoint. Mais comme discuté plus haut, il faut un token pour utiliser la nouvelle API, on ne peut pas juste remplacer sans changer le paramétrage du connecteur.

• ajouter les nouveaux champs clés d'API au connecteur
• marquer le champs mot de passe comme déprécié
• dans le code, si le mot de passe est renseigné, utiliser http2sms, si les clés le sont, utiliser l'API

Et hop l'existant continue à marcher, il peut être migré au fil de l'eau. Ça me semble mieux que d'ajouter un nouvel endpoint/nouveau connecteur.

Valentin Deniaud a écrit :

• dans le code, si le mot de passe est renseigné, utiliser http2sms, si les clés le sont, utiliser l'API

Yep c'est la bonne idée.

J'aimerai qu'on ne profite pour ajouter quelques help_text parce que c'est pas simple de savoir comment tout ça se bouine :

• account : « identifiant du compte, de la forme sms-xxxx » (si c'est bien ça ?)
• application_key : « à obtenir via https://eu.api.ovh.com/createToken/ pour un POST sur /sms/ » (si c'est bien ça aussi...)
• application_secret : « obtenu en même temps que application_key »
• consumer_key : « obtenu en même temps que application_key »
• username : ? « utilisateur API créée sur le compte SMS » (si c'est bien ça, again ?)

Valentin Deniaud a écrit :

(oublié le help_text de username)

Il manque la migration correspondante ; merci pour les help_text et d'accord pour dire que c'est trop long. Allez ajoutons un documentation_url :

class OVHSMSGateway(SMSResource):
  documentation_url = 'https://doc-publik.entrouvert.com/admin-fonctionnel/les-tutos/configuration-envoi-sms/'
  ...

(Ça et la migration, ça sera poussable.)