Benutzerauswahl für Avatare über API funktioniert nicht mehr

[Spac3Rat (Sérgio Costa)]

Hallo zusammen. Ich verwende SSO in meinem Forum und Avatare werden von meiner Website gesteuert.

Bis vor ein paar Tagen funktionierte der Avatar-Upload/-Update von der Website zu Discourse über die API. Jetzt erhalte ich einen 422 – Unprocessable Entity-Fehler.

Ich habe versucht, das Problem zu debuggen, einige Tests mit Postman durchgeführt und habe die gleichen Probleme. Die Anfrage, die ich stelle, ist unten aufgeführt (mit URL, Benutzername und API-Schlüssel natürlich entfernt).

Weiß jemand von euch, ob es ein Problem mit diesem Teil von Discourse gibt?

Vielen Dank im Voraus.

Mein Beispiel:

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"
}'

[Spac3Rat (Sérgio Costa)]

Gibt es niemanden? Hat niemand das gleiche Problem festgestellt?

[mattdm (Matthew Miller)]

Hängt das wahrscheinlich mit der Änderung der API zusammen, um direkte Uploads nach S3 zu ermöglichen?

[Spac3Rat (Sérgio Costa)]

Ich glaube, das würde den eigentlichen Upload beeinträchtigen, nicht die Zuweisung des Avatars an den Benutzer.

Ich kann die Datei ohne Probleme hochladen. Wenn ich den API-Aufruf mache, um anzugeben, welche Datei als Avatar verwendet werden soll, bekomme ich dort den Fehler, und das geschah aus heiterem Himmel.

[Spac3Rat (Sérgio Costa)]

Ich versuche mein Glück und pushe dies ein letztes Mal. Es ist seltsam, dass niemand das gefunden hat. Ich bin sicher, dass es kein Codierungsproblem ist, da es seit über zwei Jahren funktioniert.

[blake (Blake Erickson)]

Ich glaube, das liegt an der Website-Einstellung discourse connect overrides avatar.

Überschreibt das Benutzer-Avatar mit dem Wert aus der DiscourseConnect-Nutzlast. Wenn aktiviert, dürfen Benutzer keine Avatare in Discourse hochladen.

Lokal habe ich mit dieser Einstellung deaktiviert eine HTTP-Antwort 200 erhalten, wenn ich den Avatar über die API aktualisiere:

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

Und ich erhalte 422 mit dieser Einstellung aktiviert:

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

[Spac3Rat (Sérgio Costa)]

Hallo Blake. Danke für deine Hilfe.

Leider macht es keinen Unterschied, ob ich es aktiviere oder deaktiviere.

[blake (Blake Erickson)]

Ich habe noch keine Antwort, wollte Ihnen aber nur mitteilen, dass dies auf meiner Liste steht, um es zu untersuchen. Ich habe eine SSO-Einrichtung, die ich lokal testen kann, damit unsere Einstellungen übereinstimmen. Es scheint, dass wir diese Website-Einstellung respektieren sollten, was eine kürzlich vorgenommene Änderung sein könnte, aber vielleicht könnten wir eine API-Überschreibung hinzufügen.

[Spac3Rat (Sérgio Costa)]

Vielen Dank, Blake. Bitte lassen Sie mich wissen, wenn ich behilflich sein kann.

[RGJ (Richard - Communiteq)]

Ein weiterer Grund für einen 422 von dieser Methode kann sein, wenn die Einstellung allow_uploaded_avatars false ist. Ich wette, das ist das Problem.

[Spac3Rat (Sérgio Costa)]

Hallo Richard! Danke für deine Eingabe.

Ich habe auch darüber nachgedacht, aber es hat nicht funktioniert. Außerdem trat dieses Problem aus heiterem Himmel auf. Niemand hat etwas geändert (ich bin der einzige Administrator, daher gibt es keine Chance, dass jemand Einstellungen geändert hat), keine Codeänderungen auf der Hauptwebsite, nichts.

[blake (Blake Erickson)]

Können Sie mir mitteilen, was Sie für allow_uploaded_avatars eingestellt haben? Es ist nicht mehr nur eine True/False-Einstellung, sondern auf ein bestimmtes Vertrauensniveau gesetzt. Und können Sie mir mitteilen, welches Vertrauensniveau der Benutzer hat, der versucht, seinen Avatar zu ändern? Und sind Sie auf der neuesten Version von Discourse?

Hier ist der Code zum Auswählen eines Avatars und die Zeilen, die 422-Antworten zurückgeben.

Nicht, dass es nicht etwas anderes tief im Code sein könnte, aber es ist wahrscheinlich eines dieser 3. Das erste hat mit discourse_connect_overrides_avatar zu tun und anscheinend haben wir das ausgeschlossen. Ich glaube nicht, dass es das zweite ist, weil Ihr Curl-Befehl korrekt aussieht und den Typ „uploaded“ enthält. Es könnte immer noch das dritte mit der Einstellung allow_uploaded_avatars sein, weshalb ich wissen möchte, wie Sie diese eingestellt haben.

[Spac3Rat (Sérgio Costa)]

Ich hatte es deaktiviert, bis dieses Problem auftrat. Dann habe ich es auf 0:neuer Benutzer geändert.

Aber es war immer deaktiviert und hat für mich funktioniert. Ich möchte nicht, dass Benutzer tatsächlich aus dem Forum hochladen, sondern von der Website, die SSO verwendet. Dennoch ändert die Änderung auf 0:neuer Benutzer nichts. Ich erhalte immer noch die gleiche Fehlermeldung

[blake (Blake Erickson)]

Ich kann keine kürzliche Aktualisierung finden, die Avatare über die API gestoppt hätte, wenn alle Website-Einstellungen sie blockieren. Unabhängig davon, wenn Sie SSO (oder DiscourseConnect) verwenden, sollten Sie die API-Route /admin/users/sync_sso verwenden, um den Avatar der Benutzer zu aktualisieren, nicht die UI-Route (/u/username/preferences/avatar/pick).

Und übergeben Sie diese Parameter im Anforderungskörper:

avatar_url: "url-of-image",
avatar_force_update: "true"

[Spac3Rat (Sérgio Costa)]

Hallo Blake. Vielen Dank für Ihre anhaltende Hilfe in dieser Angelegenheit.

Ich kann keine Informationen über diesen Endpunkt in der API-Dokumentation finden. Ist das etwas Neues?

Außerdem, wie ich bereits erwähnt habe, funktionierte das Avatar-Update mehrere Monate lang einwandfrei über den Endpunkt /u/username/preferences/avatar/pick, was wirklich seltsam ist. Es hat einfach aufgehört zu funktionieren. Das verwirrt mich wirklich.

[blake (Blake Erickson)]

Ja, das sollte wirklich in der Dokumentation stehen, es ist nichts Neues, nur anders als alle anderen Endpunkte.

Hier finden Sie einige Informationen: Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)

Und auch, wie das Ruby-Gem discourse_api den Endpunkt sync_sso verwendet: discourse_api/lib/discourse_api/single_sign_on.rb at main · discourse/discourse_api · GitHub und discourse_api/lib/discourse_api/api/sso.rb at main · discourse/discourse_api · GitHub

Es muss dasselbe SSO-Geheimnis verwendet werden, das Ihr SSO-Anbieter verwendet.

[Spac3Rat (Sérgio Costa)]

Danke, Blake.

Mir ist immer noch nicht klar, warum die Dinge einfach von selbst aufgehört haben zu funktionieren und ich überall 422-Fehler bekomme, selbst bei diesem Endpunkt.

Ich werde versuchen, eine andere Lösung zu finden.

Vielen Dank für Ihre Zeit.