User avatar selection through API no longer working

dev
1

Hi everyone. I am using SSO on my forum and avatars are controlled by my website.

Until a few days ago, avatar upload/update from the website to the Discource, via API was working. I now get a 422 - Unprocessable Entity error.

I’ve tried to debug the issue, did some testing with Postman and I have the same issues. The request I am doing is below (with url, username and api_key removed, of course).

Does any of you know if there’s any issue with this portion of Discourse?

Thank you in advance.

My example:

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

Anyone? Isn’t there anyone that has found the same problem?

3

This is probably related to the change to the API to do direct uploads to S3?

4

I think that would interfere with the actual upload, not the assignment of the avatar to the user.

I can upload the file without any issue. When I make the call to the API to indicate which file to use as an avatar, that’s where I get the error and that started out of the blue.

1 Like
5

I’m trying my luck and boost this one last time. It’s odd that no one has found this. I am sure it’s not a coding issue since it has been working for over a couple of years now.

1 Like
6

I think this is due to the discourse connect overrides avatar site setting.

image
image1061×141 8.87 KB

Overrides user avatar with value from DiscourseConnect payload. If enabled, users will not be allowed to upload avatars on Discourse.

On my local with that unchecked I get a 200 http response when updating the avatar via the 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

And I get a 422 with that setting checked:

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 Like
8

Hi Blake. Thanks for pitching in.

Enable or disabling it makes no difference, unfortunately.

1 Like
10

I don’t have an answer yet, but just wanted to let you know that this is on my list to look into. I have a sso setup I can test locally, so that our settings match. It seems like we should be respecting that site setting which could be a change someone made recently, but maybe we could add an API override.

1 Like
11

Thank you very much, Blake. Please let me know if there’s anything I can help with.

1 Like
12

Another reason for a 422 from that method can be if the allow_uploaded_avatars setting is false. I bet that’s the issue.

1 Like
13

Hi Richard! Thanks for your input.

I thought about that as well but it didn’t work. Also, this issue appeared out of the blue. No one changed anything (I am the only admin so there’s no chance someone could have switched any settings), no code changes on the main website, nothing.

14

Can you let me know what you have set for allow_uploaded_avatars? It no longer is just a true/false setting, but is set to a certain trust level. And can you let me know what the trust level is of the user trying to change their avatar? And are you on the latest version of Discourse?

Here is the code for picking an avatar and the lines that return 422 responses.

image
image1168×1344 157 KB

Not that it couldn’t be something else deep in the codebase, but it likely is one of these 3. The first one has to do with discourse_connect_overrides_avatar and apparently we ruled that one out. I don’t think it is the second one because your curl command looks correct and includes the “uploaded” type. It could possibly still be the third one with the allow_uploaded_avatars setting which is why I’d like to know what you have that one set to.

15

I had it disabled until this problem started. Then I changed it to 0:new user.

But having it disabled always worked for me. I don’t want users to actually upload from the forum, but rather from the website which uses SSO. Still, changing it to 0:new user doesn’t change anything. I still get the same error :frowning:

image
image809×674 45.6 KB

16

I’m not able to find any recent update that would have stopped avatars to work via the api when all the site settings have them blocked. Regardless, if you are using SSO (or DiscourseConnect), you should be using the /admin/users/sync_sso api route to update the users avatar not the UI route (/u/username/preferences/avatar/pick).

And pass in these params in the request body:

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

Hi Blake. Thank you very much for your continued help on this matter.

I can’t find any information about that endpoint in the API documentation. Is that something new?

Also, like I indicated before, avatar update was working fine for several months using the /u/username/preferences/avatar/pick endpoint, which is really odd. It just stopped working. That really puzzles me.

18

Ya, it really should be in the docs, its not new though, its just different than all the other endpoints.

You can find some info here: DiscourseConnect - Official Single-Sign-On for Discourse (sso)

And also how the discourse_api ruby gem uses the sync_sso endpoint: discourse_api/single_sign_on.rb at main · discourse/discourse_api · GitHub and discourse_api/sso.rb at main · discourse/discourse_api · GitHub

It will need to use the same sso secret that your sso provider is using.

19

Thanks, Blake.

It still doesn’t make sense to me that things just stopped working on their own and I get 422 errors left and right, even with that endpoint.

I’ll try to find a different solution.

Thank you very much for your time.

1 Like