Seleção de avatar do usuário via API não funciona mais

Olá a todos. Estou usando SSO no meu fórum e os avatares são controlados pelo meu site.

Até alguns dias atrás, o upload/atualização de avatares do site para o Discourse, via API, estava funcionando. Agora recebo um erro 422 - Unprocessable Entity.

Tentei depurar o problema, fiz alguns testes com o Postman e estou tendo os mesmos problemas. A solicitação que estou fazendo está abaixo (com URL, nome de usuário e api_key removidos, é claro).

Algum de vocês sabe se há algum problema com esta parte do Discourse?

Agradeço antecipadamente.

Meu exemplo:

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

Alguém? Não há ninguém que tenha encontrado o mesmo problema?

Isso provavelmente está relacionado à mudança na API para fazer uploads diretos para o S3?

Eu acho que isso interferiria com o upload real, não com a atribuição do avatar ao usuário.

Consigo fazer o upload do arquivo sem problemas. Quando faço a chamada para a API para indicar qual arquivo usar como avatar, é aí que recebo o erro e isso começou do nada.

1 curtida

Estou tentando minha sorte e impulsionando isto mais uma vez. É estranho que ninguém tenha encontrado isto. Tenho certeza de que não é um problema de codificação, pois tem funcionado por mais de dois anos.

1 curtida

Eu acho que isso se deve à configuração do site discourse connect overrides avatar.

Substitui o avatar do usuário pelo valor da carga útil do DiscourseConnect. Se ativado, os usuários não poderão fazer upload de avatares no Discourse.

Na minha máquina local, com essa opção desmarcada, recebo uma resposta http 200 ao atualizar o avatar pela 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

E recebo um 422 com essa configuração marcada:

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 curtida

Oi Blake. Obrigado por ajudar.

Ativá-lo ou desativá-lo não faz diferença, infelizmente.

1 curtida

Ainda não tenho uma resposta, mas queria apenas informar que isso está na minha lista para investigar. Tenho uma configuração de SSO que posso testar localmente, para que nossas configurações coincidam. Parece que devemos respeitar essa configuração do site, o que pode ser uma mudança que alguém fez recentemente, mas talvez possamos adicionar um substituto de API.

1 curtida

Muito obrigado, Blake. Por favor, me avise se houver algo em que eu possa ajudar.

1 curtida

Outro motivo para um 422 desse método pode ser se a configuração allow_uploaded_avatars for falsa. Aposto que esse é o problema.

1 curtida

Olá Richard! Obrigado pela sua contribuição.

Eu pensei sobre isso também, mas não funcionou. Além disso, esse problema apareceu do nada. Ninguém mudou nada (eu sou o único administrador, então não há chance de alguém ter alterado alguma configuração), nenhuma alteração de código no site principal, nada.

Pode me informar o que você definiu para allow_uploaded_avatars? Não é mais apenas uma configuração verdadeiro/falso, mas está definida para um certo nível de confiança. E você pode me informar qual é o nível de confiança do usuário que está tentando alterar seu avatar? E vocês estão na versão mais recente do Discourse?

Aqui está o código para escolher um avatar e as linhas que retornam respostas 422.

Não que não possa ser outra coisa no fundo do código, mas provavelmente é um destes 3. O primeiro tem a ver com discourse_connect_overrides_avatar e aparentemente descartamos esse. Não acho que seja o segundo porque seu comando curl parece correto e inclui o tipo “uploaded”. Possivelmente ainda pode ser o terceiro com a configuração allow_uploaded_avatars, que é por isso que eu gostaria de saber o que você definiu para essa configuração.

Eu o tinha desativado até que este problema começasse. Então, mudei para 0:novo usuário.

Mas desativá-lo sempre funcionou para mim. Eu não quero que os usuários façam upload do fórum, mas sim do site que usa SSO. Ainda assim, mudar para 0:novo usuário não muda nada. Eu ainda recebo o mesmo erro :frowning:

Não consigo encontrar nenhuma atualização recente que tenha impedido o funcionamento de avatares via API quando todas as configurações do site os bloqueiam. De qualquer forma, se você estiver usando SSO (ou DiscourseConnect), deverá usar a rota da API /admin/users/sync_sso para atualizar o avatar dos usuários, e não a rota da interface do usuário (/u/username/preferences/avatar/pick).

E passe estes parâmetros no corpo da solicitação:

avatar_url: "url-da-imagem",
avatar_force_update: "true"

Olá Blake. Muito obrigado pela sua ajuda contínua neste assunto.

Não consigo encontrar nenhuma informação sobre esse endpoint na documentação da API. É algo novo?

Além disso, como indiquei antes, a atualização do avatar estava funcionando bem por vários meses usando o endpoint /u/username/preferences/avatar/pick, o que é realmente estranho. Simplesmente parou de funcionar. Isso realmente me intriga.

Sim, realmente deveria estar na documentação, não é novidade, é apenas diferente de todos os outros endpoints.

Você pode encontrar algumas informações aqui: Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)

E também como a gem ruby discourse_api usa o endpoint sync_sso: discourse_api/lib/discourse_api/single_sign_on.rb at main · discourse/discourse_api · GitHub e discourse_api/lib/discourse_api/api/sso.rb at main · discourse/discourse_api · GitHub

Será necessário usar o mesmo segredo sso que seu provedor sso está usando.

Obrigado, Blake.

Ainda não faz sentido para mim que as coisas simplesmente pararam de funcionar sozinhas e eu recebo erros 422 sem parar, mesmo com esse endpoint.

Vou tentar encontrar uma solução diferente.

Muito obrigado pelo seu tempo.

1 curtida