OVH Community, votre nouvel espace communautaire.

Quelques questions générales sur API v6


smrhp
16/02/2016, 14h05
Bonjour,

Après questionnement du support via ticket, j'ai la confirmation :
- qu'il n'y a pas de système d'api actuellement pour permettre l'association d'un CK avec un compte OVH (ce qu'on fait actuellement via l'url de validation)
- que le password qu'on peut indiquer sur l'api de création d'un utilisateur SMS n'est en fait pas utilisé ensuite par les autres API...

Bref, pas de solution technique à mon problème à part se mettre à valider manuellement la création de mes utilisateurs SMS... La migration de mes clients existant va être simple...

smrhp
12/02/2016, 08h25
Bonjour,

Bon pas trop de réponse ni sur ce forum, ni sur la ml api@ml.ovh.net et au téléphone on nous dit qu'il faut passer ces canaux très réactifs... Bref, y'a pas de support pour l'api v6 ovh ?

smrhp
27/01/2016, 15h50
Bon, je continue d'avancer mais avec un peu la sensation de reculer dans la compréhension de votre API (c'est vraiment vraiment pénalisant de n'avoir ni support téléphonique, ni documentation claire et complète (autre que https://eu.api.ovh.com/console/).
Visiblement login/password existe encore pour mes comptes utilisateurs tels que je les utilise : https://eu.api.ovh.com/console/#/sms/{serviceName}/users#POST
Et je n'arrive pas à trouver de moyen de créer un CK "encapsulé" dans un logiciel de CRM dispo pour mon support téléphonique (car je ne vais ni leur filer les identifiants de mon nic handle, ni valider moi-même chaque création de compte sms pour mes clients). Donc finalement dans mon cas j'ai l'impression qu'il me faudrait 2 CK : un avec pas mal de droits pour créer les comptes (genre sur /sms/* pour mon logiciel interne de gestion client dispo mon SAV) et un CK intégré dans mon appli pour les clients avec des droits permettant d'envoyer des sms. Pourtant le système d'un CK par client pourrait être bien pour limiter les droits sur uniquement son compte (/sms/{serviceName}/users/*) (mais là je ne vois pas comment faire pour l'intégrer dans mon logiciel SAV pour que mon support puisse être autonome pour ouvrir un compte sms pour un client sans avoir les id de mon compte ovh (pour l'équivalent de telephonySmsUserAdd ça a l'air d'aller mais pour créer un CK associé qui n'aurait que les droits pour ce login, je ne vois pas ?)

smrhp
27/01/2016, 14h38
petit complément, je dirais même (vu que smsAccount existe toujours) qu'en fait je peux continuer de créer des login et que je peux donner des droits au CK correspondant sur ces urls /sms/{serviceName}/users/* +/- qqes autres selon les besoins ?
(en gros CK ici reviendrait à remplacer l'ancien password associé au login du smsAccount)

smrhp
27/01/2016, 14h32
Bonjour et merci pour ta réponse,

Citation Envoyé par vcasse
Si je comprend bien : tu géres l'ensemble de tes client sur un même compte OVH (nichandle) et pour chaque client, tu utilises un serviceName différent.
Et même encore un peu plus loin, je gère l'ensemble de mes clients sur un même nichandle ET un même serviceName. Dans le but d'acheter les SMS par gros lots (50 ou 100000) et ensuite je pioche dans mon "credit" pour alimenter les quotas des utilisateurs (via api mais l'écran équivalent en OVH v3 est celui-ci : https://goo.gl/kNVGgy
J'utilise les fonctions telephonySmsSetUserQuota et telephonySmsUserSend (par exemple, pour que les SMS soient décompté du compte de mon client). Ainsi je n'avais pas le mot de passe de mon compte OVH dans l'application. Pour l'activation de l'expéditeur j'avais d'ailleurs déporté l'activation sur une page php d'un serveur web pour ne pas avoir à mettre ce mot de passe dans l'application.

Tu as bien vu, l'api ne permet plus de s'identifier par login/mot de passe. C'est pour éviter que les mots de passe des comptes OVH ne trainent dans des scripts. C'est plus simple pour révoquer un accés ensuite.
ça c'est en effet mieux, car à l'époque de la création du service ça m'avait chagriné d'avoir souvent besoin de ce mot de passe pour l'utilisation de l'API. Mais finalement à part l'activation de l'expéditeur, je m'en étais sortis sans avoir besoin d'intégrer de mot de passe.

En soit, tu peux créer une CK identique pour tous tes clients. Cependant, cela signifie que la personne qui trouve cette CK pourra envoyer des requêtes avec des serviceName différents du sien. Bref, ca marche, mais c'est moyen sécurisé.

Ce que je te conseille, et je crois que tu l'as bien compris, c'est de créer un CK pour chaque client, de validité illimitée, avec des droits restreint sur le serviceName souhaité. Tu peux gérer ca dans le champs Right de https://eu.api.ovh.com/createToken/.
Par exemple, là tu donnes tous les droits de consultation et de création pour le serviceName sms-nnnn-n
ce qui veut donc dire que pour cette fonction : telephonySmsUserSend ( est string, est string [...]
serait plus ou moins remplacé par un CK ?

Oui ! C'est même le but
La AK sert principalement si tu veux faire des applications en ligne. Chaque CK peuvent par contre, avoir des accés différents. En gros, il faut voir AK, AS et CK comme un trio d'identifiants. Un peu comme on trouve sur les bases de données : login, mot de passe, url, port, table
par contre pour pouvoir créer un CK relié à un même AK, il faut passer impérativement par les API ? a priori l'url createToken recrée systématiquement un trio si j'ai bien compris ?

Mais je n'ai pas trouvé de "PUT/POST" autour de /me/api/credential ou /me/api/application ? j'ai l'impression d'après cette page que ce serait l'api /auth/credential mais je n'ai pas trouvé de documentation sur cette partie de l'API.

Pour nuancer ton propos : c'est principalement par question de priorité que cette fonctionnalité ne se trouve pas encore dans les espaces clients. Les équipes se sont d'abord concentrées sur la fermeture du v3.
déjà c'est un peu rassurant, ça veut dire qu'il semble prévu que ça évolue. Sauf qu'annoncer la fermeture d'un service avant d'avoir fini le nouveau c'est un poil "limite" tout de même.

vcasse
27/01/2016, 09h33
Bonjour smrhp,

Après pas mal de tentatives, j'ai fini par réussir à utiliser les AK,AS,CK pour m'authentifier. J'aurais cependant concernant ces clés quelques questions sur leur "concept". Mon application est un exécutable qui s'installe chez mes clients. Pour AK et AS, j'ai tendance à être presque sûr que c'est clé devront être intégrée en tant que constante dans mon application. Pour consumerkey j'ai un peu plus de doutes ? Est-ce que j'en génère une seule avec les bons droits pour mon application et ce sera la même CK chez tous mes clients ? est-ce que je dois prévoir un système qui crée cette CK depuis l'application pour chaque client ?
Je gère mes comptes clients actuellement avec un seul "serviceName" (= sms-nnnn-n) et j'ai autant d'utilisateur sms avec mot de passe dans ce compte que de client ayant l'option sms.
Si je comprend bien : tu géres l'ensemble de tes client sur un même compte OVH (nichandle) et pour chaque client, tu utilises un serviceName différent.

Tu as bien vu, l'api ne permet plus de s'identifier par login/mot de passe. C'est pour éviter que les mots de passe des comptes OVH ne trainent dans des scripts. C'est plus simple pour révoquer un accés ensuite.

En soit, tu peux créer une CK identique pour tous tes clients. Cependant, cela signifie que la personne qui trouve cette CK pourra envoyer des requêtes avec des serviceName différents du sien. Bref, ca marche, mais c'est moyen sécurisé.

Ce que je te conseille, et je crois que tu l'as bien compris, c'est de créer un CK pour chaque client, de validité illimitée, avec des droits restreint sur le serviceName souhaité. Tu peux gérer ca dans le champs Right de https://eu.api.ovh.com/createToken/.
Par exemple, là tu donnes tous les droits de consultation et de création pour le serviceName sms-nnnn-n

GET /sms/sms-nnnn-n/*
POST /sms/sms-nnnn-n/*
on peut donc créer plusieurs CK reliés à un même AK ?
Oui ! C'est même le but
La AK sert principalement si tu veux faire des applications en ligne. Chaque CK peuvent par contre, avoir des accés différents. En gros, il faut voir AK, AS et CK comme un trio d'identifiants. Un peu comme on trouve sur les bases de données : login, mot de passe, url, port, table

au passage j'ai trouvé des API /me/api/application par exemple et quelques autres qui semblent pouvoir permettre d'accéder à la liste des AK/AS/CK déjà créé sur le compte... cela voudrait dire que les API existent, mais qu'ovh ne s'est pas donné la peine de développer la partie interface client ??
Tu as raison, ces appels permettent la gestion des accés :
/me/api/credential/{credentialId}
/me/api/application/{applicationId}

Pour nuancer ton propos : c'est principalement par question de priorité que cette fonctionnalité ne se trouve pas encore dans les espaces clients. Les équipes se sont d'abord concentrées sur la fermeture du v3.

N'hésites pas si tu as d'autres questions concernant ta migration !

Cordialement,
Vincent

smrhp
26/01/2016, 15h58
bonjour,

alors si j'en crois cette page, il semblerait bien que le mot de passe associé à un login d'utilisateur n'existe plus et qu'il faille donc bien générer un CK à la place ? Quelqu'un peut me confirmer ?
http://guides.ovh.net/SmsUserApi

on peut donc créer plusieurs CK reliés à un même AK ?

au passage j'ai trouvé des API /me/api/application par exemple et quelques autres qui semblent pouvoir permettre d'accéder à la liste des AK/AS/CK déjà créé sur le compte... cela voudrait dire que les API existent, mais qu'ovh ne s'est pas donné la peine de développer la partie interface client ??

smrhp
25/01/2016, 15h05
Bonjour,

Utilisant depuis plusieurs année la version soAPI dans une application windows que nous développons, je me penche sur la migration en API v6 vu que la fin du SOAP semble se profiler pour de bon.

Après pas mal de tentatives, j'ai fini par réussir à utiliser les AK,AS,CK pour m'authentifier. J'aurais cependant concernant ces clés quelques questions sur leur "concept". Mon application est un exécutable qui s'installe chez mes clients. Pour AK et AS, j'ai tendance à être presque sûr que c'est clé devront être intégrée en tant que constante dans mon application. Pour consumerkey j'ai un peu plus de doutes ? Est-ce que j'en génère une seule avec les bons droits pour mon application et ce sera la même CK chez tous mes clients ? est-ce que je dois prévoir un système qui crée cette CK depuis l'application pour chaque client ?
Je gère mes comptes clients actuellement avec un seul "serviceName" (= sms-nnnn-n) et j'ai autant d'utilisateur sms avec mot de passe dans ce compte que de client ayant l'option sms.

Une autre question plus pratique. j'ai généré plusieurs applications et CK depuis les url suivantes pour divers tests :
- https://eu.api.ovh.com/createToken/
- https://eu.api.ovh.com/createApp/

Le soucis c'est que je ne trouve pas d'endroit pour gérer ces jetons "application" (un peu comme pour les api google où on a une console pour gérer tout ça). Ai-je mal cherché ou cette espace n'existe pas ?? Dans ce cas comment supprimer une application qui ne servirait pas ? (la plupart du temps j'avais mis une limite, mais une fois j'ai du cocher illimité à la création...)

Merci pour votre aide.