Выбор аватара пользователя через API больше не работает

[Spac3Rat (Sérgio Costa)]

Всем привет. Я использую SSO на своем форуме, и аватары управляются моим сайтом.

До нескольких дней назад загрузка/обновление аватара с сайта в Discourse через API работала. Сейчас я получаю ошибку 422 — Unprocessable Entity.

Я пытался отладить проблему, провел тесты с помощью Postman, но столкнулся с теми же трудностями. Мой запрос приведен ниже (конечно, URL, имя пользователя и API-ключ удалены).

Знает ли кто-нибудь из вас, есть ли проблема с этой частью Discourse?

Заранее спасибо.

Мой пример:

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)]

Кто-нибудь? Разве никто не столкнулся с той же проблемой?

[mattdm (Matthew Miller)]

Это, вероятно, связано с изменением API для прямой загрузки в S3?

[Spac3Rat (Sérgio Costa)]

Я думаю, что это будет мешать самой загрузке, а не назначению аватара пользователю.

Я могу загрузить файл без каких-либо проблем. Ошибка возникает, когда я делаю вызов к API, чтобы указать, какой файл использовать в качестве аватара. Это началось внезапно, без видимых причин.

[Spac3Rat (Sérgio Costa)]

Решил попробовать ещё раз и поднять это в последний раз. Странно, что никто не нашёл этого. Я уверен, что проблема не в коде, так как всё работало уже несколько лет.

[blake (Blake Erickson)]

Я думаю, это связано с настройкой сайта «discourse connect overrides avatar».

Переопределяет аватар пользователя значением из полезной нагрузки DiscourseConnect. Если эта опция включена, пользователям не будет разрешено загружать аватары в Discourse.

На моей локальной машине, когда эта настройка снята, я получаю HTTP-ответ 200 при обновлении аватара через 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

А когда эта настройка включена, я получаю ответ 422:

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)]

Привет, Блейк. Спасибо, что подключился.

К сожалению, включение или отключение этого ничего не меняет.

[blake (Blake Erickson)]

У меня пока нет ответа, но я хотел сообщить, что это уже в моем списке задач. У меня есть локальная настройка SSO для тестирования, чтобы наши параметры совпадали. Похоже, мы должны учитывать эту настройку сайта, что может быть результатом недавнего изменения, но, возможно, мы могли бы добавить переопределение через API.

[Spac3Rat (Sérgio Costa)]

Большое спасибо, Блейк. Дайте знать, если я смогу чем-то помочь.

[RGJ (Richard - Communiteq)]

Ещё одна причина получения ответа 422 от этого метода может заключаться в том, что настройка allow_uploaded_avatars имеет значение false. Скорее всего, дело именно в этом.

[Spac3Rat (Sérgio Costa)]

Привет, Ричард! Спасибо за твой вклад.

Я тоже об этом подумал, но это не сработало. Кроме того, эта проблема возникла ниоткуда. Никто ничего не менял (я единственный администратор, так что никто не мог изменить настройки), никаких изменений в коде основного сайта, ничего.

[blake (Blake Erickson)]

Не могли бы вы сообщить, какое значение установлено для allow_uploaded_avatars? Это больше не просто настройка «истина/ложь», а зависит от определённого уровня доверия. Также подскажите, пожалуйста, какой уровень доверия у пользователя, пытающегося изменить свой аватар? И используете ли вы последнюю версию Discourse?

Ниже приведён код выбора аватара и строки, возвращающие ответы с кодом 422.

Хотя проблема может скрываться где-то глубоко в коде, скорее всего, дело в одном из этих трёх мест. Первое связано с discourse_connect_overrides_avatar, и, как мы выяснили, оно не является причиной. Я не думаю, что это второе место, так как ваша команда curl выглядит корректно и включает тип «uploaded». Возможно, проблема в третьем случае, связанном с настройкой allow_uploaded_avatars, поэтому мне важно знать, какое значение у вас для неё установлено.

[Spac3Rat (Sérgio Costa)]

У меня это было отключено, пока не началась эта проблема. Затем я изменил настройку на 0:new user.

Но у меня всегда работало отключение. Я не хочу, чтобы пользователи загружали файлы напрямую с форума, а только с веб-сайта, использующего SSO. Тем не менее, изменение настройки на 0:new user ничего не меняет. Я всё ещё получаю ту же ошибку

[blake (Blake Erickson)]

Я не могу найти никаких недавних обновлений, которые могли бы отключить работу аватаров через API, даже если все настройки сайта запрещают их использование. В любом случае, если вы используете SSO (или DiscourseConnect), для обновления аватара пользователя следует использовать маршрут API /admin/users/sync_sso, а не маршрут интерфейса (/u/username/preferences/avatar/pick).

Также передайте следующие параметры в теле запроса:

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

[Spac3Rat (Sérgio Costa)]

Привет, Блейк. Большое спасибо за вашу постоянную помощь в этом вопросе.

Я не могу найти никакой информации об этой конечной точке в документации API. Это что-то новое?

Также, как я уже указывал ранее, обновление аватара работало без сбоев в течение нескольких месяцев с использованием конечной точки /u/username/preferences/avatar/pick, что действительно странно. Оно просто перестало работать. Это меня очень озадачивает.

[blake (Blake Erickson)]

Да, это действительно должно быть в документации, хотя это не новинка — просто отличается от всех остальных эндпоинтов.

Некоторую информацию можно найти здесь: Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)

А также посмотреть, как ruby-гем discourse_api использует эндпоинт sync_sso: discourse_api/lib/discourse_api/single_sign_on.rb at main · discourse/discourse_api · GitHub и discourse_api/lib/discourse_api/api/sso.rb at main · discourse/discourse_api · GitHub

Вам потребуется использовать тот же секрет SSO, что и ваш провайдер SSO.

[Spac3Rat (Sérgio Costa)]

Спасибо, Блейк.

Мне всё ещё непонятно, почему всё просто перестало работать само по себе и я получаю ошибки 422 направо и налево, даже с этим эндпоинтом.

Я попробую найти другое решение.

Огромное спасибо за ваше время.