APIエンドポイントusers/by-external/が認証ヘッダー付きで失敗し、認証ヘッダーなしでは動作します

バグ
1

3月24日から、Discourse APIがリクエストに応答する方法に変更があったようです。

こちら側でコードの変更は行っておらず、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でもテストしましたが、結果は同じでした。

「いいね！」 4
10

@Tim_Scaffidiさんとこの件についてやり取りした結果、Api-Usernameとして渡されたユーザーがSiteSetting.invalidate_inactive_admin_email_after_daysによって自動的に非アクティブ化されていたことが判明しました。API呼び出しがそのユーザーの「ログイン」アクティビティを更新していない、この設定に関連するバグがある可能性があります。

「いいね！」 7
15

もう一度確認しましたが、改善のために変更すべきコードは見つかりませんでした。この問題は「All Users」APIキーが使用されていたためにのみ発生したため、コードを変更する必要はないと思います。ユーザーの無効化を回避する最善の方法は、「Single User」APIキーを使用することです。これにより、ユーザーレコードの last_seen_at を確認しようとする代わりに、APIキーレコードの last_used_at を確認できます。

「いいね！」 1