API endpoint users/by-external/ не работает с заголовками авторизации, работает без них

Внести вклад Ошибка
1

Начиная с 24 марта, похоже, изменился способ ответа API Discourse на запросы.

С нашей стороны никаких изменений в коде не вносилось, и Api-Key по-прежнему действителен, однако один из наших бэкенд-сервисов, пытающийся получить информацию о пользователе, начал выдавать ошибку при обращении к users/by-external/{id}.json.

В этих запросах мы отправляем заголовки Api-Key и Api-Username, которые, согласно документации, являются обязательными. Эти запросы корректно работали в течение многих лет.

Теперь все запросы к этой конечной точке завершаются ошибкой 403 с следующим телом ответа:

{
    "errors": [
        "You are not permitted to view the requested resource."
    ],
    "error_type": "invalid_access"
}

Это также происходит, если я пытаюсь запросить /u/{username}.json.

Удивительно, но когда я НЕ отправляю заголовки, эти запросы, которые согласно документации требуют заголовков аутентификации, фактически возвращают запрошенные данные, как будто они были аутентифицированы.

Я также пробовал отправлять неверный Api-Key, и в ответ получал немного другое сообщение:

{
    "errors": [
        "You are not permitted to view the requested resource. The API username or key is invalid."
    ],
    "error_type": "invalid_access"
}

Это говорит о том, что ключ принимается, но ошибочно сообщается, что он не предоставляет доступа к ресурсу, в то время как неаутентифицированные запросы получают полный доступ.

Я также только что протестировал ситуацию с новым Api-Key, имеющим опции all-users / global, и получил тот же результат.

4 лайка
10

После обсуждения этого вопроса с @Tim_Scaffidi мы поняли, что пользователь, переданный в параметре Api-Username, был автоматически деактивирован настройкой SiteSetting.invalidate_inactive_admin_email_after_days. Вероятно, существует ошибка, связанная с этой настройкой: API-вызовы, выполненные пользователем, не обновляют информацию о его «входе» в систему.

7 лайков
15

Я снова изучил этот вопрос, чтобы понять, есть ли код, который следует изменить для улучшения ситуации. Однако, поскольку проблема возникла только из-за использования API-ключа «Все пользователи», я не считаю, что нам нужно что-либо менять в коде. Лучший способ избежать деактивации пользователя — использовать API-ключ «Один пользователь», чтобы мы могли проверять поле last_used_at в записи API-ключа вместо попытки проверить last_seen_at в записи пользователя.

1 лайк