Produits Entr'ouvert » Combo

C'est un truc que je trouvais aussi du côté du Passerelle mais j'avais trouvé plus important d'y insister sur les tests.

Mais ici, discutons du patch, et simplement, hash = hmac.HMAC(str(key), digestmod=digestmod, msg=s), et voilà l'affaire réglée, non ?

Frédéric Péters a écrit :

Mais ici, discutons du patch, et simplement, hash = hmac.HMAC(str(key), digestmod=digestmod, msg=s), et voilà l'affaire réglée, non ?

Ça ne fonctionnera pas si key aura la valeur u'clé', par exemple.

Mais est-ce une valeur qu'on y autorise ? (ma suggestion partait bien sûr de l'idée qu'on se limitait à de l'ascii dans key).

Je ne vois pas où dans combo on définirait une secret_key, il faudrait, si c'est ce qu'on veut, n'y autoriser que de l'ascii.

J'ai sorti l'exemple de combo au pif.
Plus concretement, ça peut venir des variables définies dans hobo.

Ma question était "est-ce une valeur qu'on y autorise ?" et la réponse permet de déterminer si on peut faire un simple str(), ou pas. Il me semblait, mon idée, c'était qu'on se limitait à de l'ascii. Tu sembles penser qu'on n'a pas cette garantie, qu'on laisse des gens y placer des valeurs arbitraires.

Je ne sais pas pour combo mais coté passerelle on peut mettre de l'unicode dans ApiUser.key (CharField)... et on aura le même problème qu'ici avec passerelle/base/signature:sign_string(); je penche plutôt en faveur d'un validators=[ASCIIValidator()] sur les champs de clé mais le .encode('utf-8') me va aussi.

Benjamin Dauvergne a écrit :

Je ne sais pas pour combo mais coté passerelle on peut mettre de l'unicode dans ApiUser.key (CharField)... et on aura le même problème qu'ici avec passerelle/base/signature:sign_string(); je penche plutôt en faveur d'un validators=[ASCIIValidator()] sur les champs de clé mais le .encode('utf-8') me va aussi.

Dépôt passerelle pas à jour chez moi, pas vu que c'était corrigé aussi.

Mais donc, soit on se dit qu'on se limite à de l'ascii, et on prend le str() et on met des validateurs là où il faut, soit pas.

Frédéric Péters a écrit :

Mais donc, soit on se dit qu'on se limite à de l'ascii, et on prend le str() et on met des validateurs là où il faut, soit pas.

Dans les variables hobo je trouve qu'il sera difficile d'imposer de l'ascii uniquement vu qu'on ne fait pas de différence entre, disons, le titre du portail citoyen("Orléans" par exemple)et la clef de signature.
Je penche, donc sur mon patch initial, comme celui dans passerelle.

Mais on parle pas d'hobo, là. Dans hobo, le secret_key, il est généré.

Oui ça sent le blurp défini dans du JSON. À part les champs de modèle c'est la seule source d'unicode que je vois (à moins de se faire chier à mettre un u'xxx' dans un settings.py mais bon là...).

J'ai vu ici https://hobo.fsb.dev.entrouvert.org/environment/ une variable Clef de signature des webservices Teamnet, mais j'imagine que ce n'est pas la bonne façon de faire.
Pour avancer je propose de commiter la suggestion de patch de Fred.

Si c'est la bonne façon de faire, pour l'instant. Je pense que ce qu'on devrait viser à l'avenir c'est de créer un APIUser dans passerelle pour chaque instance définie par hobo. Comme APIUser.key on utiliserait la secret_key du service. La seule action humaine serait alors d'associer une instance à un web-service dans Passerelle pour lui ouvrir l'accès. Dans w.c.s. et combo on saurait automatiquement quelle clé utiliser.

Benjamin Dauvergne a écrit :

Si c'est la bonne façon de faire, pour l'instant. Je pense que ce qu'on devrait viser à l'avenir c'est de créer un APIUser dans passerelle pour chaque instance définie par hobo. Comme APIUser.key on utiliserait la secret_key du service. La seule action humaine serait alors d'associer une instance à un web-service dans Passerelle pour lui ouvrir l'accès. Dans w.c.s. et combo on saurait automatiquement quelle clé utiliser.

Je suis d'accord.
Je propose de pousser mon dernier patch