La sélection d'avatar utilisateur via l'API ne fonctionne plus

Dev
1

Salut tout le monde. J’utilise le SSO sur mon forum et les avatars sont contrôlés par mon site web.

Jusqu’à il y a quelques jours, le téléchargement/la mise à jour d’avatars du site web vers Discourse, via l’API, fonctionnait. J’obtiens maintenant une erreur 422 - Unprocessable Entity.

J’ai essayé de déboguer le problème, j’ai fait quelques tests avec Postman et j’ai les mêmes problèmes. La requête que j’effectue est ci-dessous (sans l’URL, le nom d’utilisateur et la clé API, bien sûr).

Quelqu’un sait s’il y a un problème avec cette partie de Discourse ?

Merci d’avance.

Mon exemple :

curl --location --request PUT 'https://{{URL}}/u/{{USERNAME}}/preferences/avatar/pick' \
--header 'Api-Key: {{API_KEY}}' \
--header 'Api-Username: system' \
--header 'Content-Type: application/json' \
--data-raw '{
"upload_id": 972,
"type": "uploaded"
}'
2

Quelqu’un ? Personne n’a rencontré le même problème ?

3

Ceci est probablement lié au changement de l’API pour effectuer des téléchargements directs vers S3 ?

4

Je pense que cela interférerait avec le téléchargement réel, et non avec l’attribution de l’avatar à l’utilisateur.

Je peux télécharger le fichier sans aucun problème. C’est lorsque j’appelle l’API pour indiquer quel fichier utiliser comme avatar que j’obtiens l’erreur, et cela a commencé à l’improviste.

1 « J'aime »
5

Je tente ma chance et je relance une dernière fois. Il est étrange que personne n’ait trouvé cela. Je suis sûr que ce n’est pas un problème de codage car cela fonctionne depuis plus de deux ans maintenant.

1 « J'aime »
6

Je pense que cela est dû au paramètre du site discourse connect overrides avatar.

image
image1061×141 8.87 KB

Remplace l’avatar de l’utilisateur par la valeur du payload DiscourseConnect. Si activé, les utilisateurs ne seront pas autorisés à télécharger des avatars sur Discourse.

Sur ma machine locale, avec ce paramètre désactivé, j’obtiens une réponse HTTP 200 lors de la mise à jour de l’avatar via l’API :

curl -i -sS -X PUT "http://localhost:4200/u/10614bb2d4eacd328c45/preferences/avatar/pick.json"  \
-H "Content-Type: multipart/form-data"  \
-H "Api-Key: 6cea489d21282803c446fd2e9d236901c3d186f36079911833db4b57c43c01d5"  \
-H "Api-Username: blake.erickson"  \
-F "upload_id=57"  \
-F "type=uploaded"

HTTP/1.1 200 OK

Et j’obtiens un 422 avec ce paramètre activé :

curl -i -sS -X PUT "http://localhost:4200/u/021ca796a01ad178bc52/preferences/avatar/pick.json"  \
-H "Content-Type: multipart/form-data"  \
-H "Api-Key: 6cea489d21282803c446fd2e9d236901c3d186f36079911833db4b57c43c01d5"  \
-H "Api-Username: blake.erickson"  \
-F "upload_id=57"  \
-F "type=uploaded"

HTTP/1.1 422 Unprocessable Entity
1 « J'aime »
8

Salut Blake. Merci d’avoir donné un coup de main.

L’activer ou le désactiver ne change malheureusement rien.

1 « J'aime »
10

Je n’ai pas encore de réponse, mais je voulais juste vous faire savoir que c’est sur ma liste à examiner. J’ai une configuration SSO que je peux tester localement, afin que nos paramètres correspondent. Il semble que nous devrions respecter ce paramètre de site, ce qui pourrait être un changement récent apporté par quelqu’un, mais peut-être pourrions-nous ajouter un remplacement d’API.

1 « J'aime »
11

Merci beaucoup, Blake. N’hésitez pas à me faire savoir si je peux vous aider en quoi que ce soit.

1 « J'aime »
12

Une autre raison d’un 422 de cette méthode peut être si le paramètre allow_uploaded_avatars est faux. Je parie que c’est le problème.

1 « J'aime »
13

Salut Richard ! Merci pour ton apport.

J’y ai pensé aussi, mais ça n’a pas fonctionné. De plus, ce problème est apparu soudainement. Personne n’a rien changé (je suis le seul administrateur, donc aucune chance que quelqu’un ait pu modifier des paramètres), aucun changement de code sur le site principal, rien.

14

Pouvez-vous me dire quel est le réglage de allow_uploaded_avatars ? Ce n’est plus un simple réglage vrai/faux, mais il est défini sur un certain niveau de confiance. Pouvez-vous également me dire quel est le niveau de confiance de l’utilisateur qui essaie de changer son avatar ? Et êtes-vous sur la dernière version de Discourse ?

Voici le code pour choisir un avatar et les lignes qui renvoient des réponses 422.

image
image1168×1344 157 KB

Non pas que cela ne puisse pas être autre chose au plus profond de la base de code, mais c’est probablement l’un de ces 3. Le premier a à voir avec discourse_connect_overrides_avatar et apparemment nous avons écarté celui-là. Je ne pense pas que ce soit le deuxième car votre commande curl semble correcte et inclut le type “uploaded”. Il pourrait encore s’agir du troisième avec le réglage allow_uploaded_avatars, c’est pourquoi j’aimerais savoir quel est le réglage que vous avez pour celui-ci.

15

Je l’avais désactivé jusqu’à ce que ce problème commence. Ensuite, je l’ai changé en 0: nouveau membre.

Mais le désactiver a toujours fonctionné pour moi. Je ne veux pas que les utilisateurs téléchargent depuis le forum, mais plutôt depuis le site Web qui utilise l’authentification unique (SSO). Cependant, le changer en 0: nouveau membre ne change rien. J’obtiens toujours la même erreur :frowning:

image
image809×674 45.6 KB

16

Je ne trouve aucune mise à jour récente qui aurait empêché les avatars de fonctionner via l’API alors que tous les paramètres du site les bloquent. Quoi qu’il en soit, si vous utilisez SSO (ou DiscourseConnect), vous devriez utiliser la route API /admin/users/sync_sso pour mettre à jour l’avatar des utilisateurs et non la route UI (/u/username/preferences/avatar/pick).

Et passez ces paramètres dans le corps de la requête :

avatar_url: "url-de-l'image",
avatar_force_update: "true"
17

Salut Blake. Merci beaucoup pour ton aide continue sur ce sujet.

Je ne trouve aucune information sur ce point de terminaison dans la documentation de l’API. Est-ce quelque chose de nouveau ?

De plus, comme je l’ai indiqué précédemment, la mise à jour de l’avatar fonctionnait bien depuis plusieurs mois en utilisant le point de terminaison /u/username/preferences/avatar/pick, ce qui est vraiment étrange. Cela vient tout simplement de cesser de fonctionner. Cela me laisse vraiment perplexe.

18

Oui, cela devrait vraiment être dans la documentation, ce n’est pas nouveau, c’est juste différent de tous les autres points d’accès.

Vous pouvez trouver des informations ici : Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)

Et aussi comment la gemme ruby discourse_api utilise le point d’accès sync_sso : discourse_api/lib/discourse_api/single_sign_on.rb at main · discourse/discourse_api · GitHub et discourse_api/lib/discourse_api/api/sso.rb at main · discourse/discourse_api · GitHub

Il devra utiliser le même secret sso que votre fournisseur sso utilise.

19

Merci, Blake.

Cela n’a toujours aucun sens pour moi que les choses aient cessé de fonctionner d’elles-mêmes et que je reçoive des erreurs 422 à tout bout de champ, même avec ce point de terminaison.

Je vais essayer de trouver une solution différente.

Merci beaucoup pour votre temps.

1 « J'aime »