API-Endpunkt users/by-external/ schlägt mit Autorisierungsheadern fehl, funktioniert ohne

Seit dem 24. März scheint sich die Art und Weise, wie die Discourse API auf Anfragen reagiert, geändert zu haben.

Auf unserer Seite wurden keine Codeänderungen vorgenommen und der Api-Key ist weiterhin gültig, aber einer unserer Backend-Dienste, der versucht, Benutzerinformationen abzurufen, begann beim Aufruf von users/by-external/{id}.json zu fehlschlagen.

Wir senden die Header Api-Key und Api-Username mit diesen Anfragen, die gemäß der Dokumentation erforderlich sein sollten. Diese Anfragen funktionieren seit Jahren einwandfrei.

Jetzt schlagen alle Anfragen an diesen Endpunkt mit einem 403 und dem Antwortkörper fehl:

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

Dies geschieht auch, wenn ich versuche, /u/{username}.json anzufordern.

Erstaunlicherweise, wenn ich die Header NICHT sende, antworten diese Anfragen, die laut Dokumentation diese Authentifizierungsheader erfordern, tatsächlich mit den angeforderten Daten, als wären sie authentifiziert.

Ich habe auch versucht, einen falschen Api-Key zu senden, und die Antwort lautet mit einer leicht anderen Meldung:

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

Dies sagt mir, dass der Schlüssel akzeptiert wird, aber fälschlicherweise meldet, dass er keinen Zugriff auf die Ressource gewährt, während nicht authentifizierte Anfragen vollen Zugriff erhalten.

Ich habe auch gerade mit einem brandneuen Api-Key mit allen Benutzer- / globalen Optionen getestet und erhalte die gleichen Ergebnisse.

4 „Gefällt mir“

Nachdem wir dies mit @Tim_Scaffidi durchgearbeitet hatten, stellten wir fest, dass der Benutzer, der für Api-Username übergeben wurde, von SiteSetting.invalidate_inactive_admin_email_after_days automatisch deaktiviert worden war. Wahrscheinlich gibt es einen Fehler im Zusammenhang mit dieser Einstellung, bei dem API-Aufrufe, die von einem Benutzer getätigt werden, nicht die “Anmelde”-Aktivität dieses Benutzers aktualisieren.

7 „Gefällt mir“

Ich habe mir das noch einmal angesehen, um zu prüfen, ob es Code gab, der geändert werden sollte, um Dinge zu verbessern, aber da das Problem nur auftrat, weil ein API-Schlüssel für „Alle Benutzer“ verwendet wurde, glaube ich nicht, dass wir am Code etwas ändern sollten. Die beste Option, um die Deaktivierung von Benutzern zu vermeiden, ist die Verwendung eines API-Schlüssels für „Einzelbenutzer“, damit wir das last_used_at im API-Schlüssel-Datensatz überprüfen können, anstatt zu versuchen, last_seen_at im Benutzerdatensatz zu überprüfen.

1 „Gefällt mir“