Benutzer-API-Schlüssel: Doppelter client_id führt zu einem internen Serverfehler

Fehler
1

Wenn user-api-key/new mit einer client_id aufgerufen wird, die bereits von einem anderen Benutzer verwendet wird, löst das Forum einen RecordNotUnique-Fehler aus und schlägt stillschweigend mit einem internen Serverfehler fehl.

image
image1347×197 10.5 KB

ActiveRecord::RecordNotUnique (PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint \"index_user_api_keys_on_client_id\"
DETAIL:  Key (client_id)=(893e0230d52455ea9b729334) already exists.
)
(eval):105:in `exec_params'
app/controllers/user_api_keys_controller.rb:66:in `create'

Dies könnte mit etwas weniger stillschweigendem Verhalten fehlschlagen, das den Benutzer darüber informiert, dass bereits ein API-Schlüssel mit dieser Client-ID vorhanden ist.

Das bringt mich jedoch zur zweiten Frage: Sollten sich User-API-Schlüssel so verhalten? Sollte die Client-ID zwischen allen Benutzern eindeutig sein?

5 „Gefällt mir“
2

Schneller Anstoß zur Sichtbarkeit. Wir sehen diese immer noch ziemlich häufig in unserem /logs-Endpunkt:

image

3 „Gefällt mir“
7

Vielen Dank für die Meldung. Ich habe jedoch ein paar Fragen, damit ich das untersuchen kann.

Können Sie mir eine einfache Reproduktion dafür geben, damit ich das lokal debuggen kann? Was ist Ihr Anwendungsfall für user-api-keys? Verwenden Sie die Discourse Hub Mobile App oder etwas anderes?

1 „Gefällt mir“
8

Ich bin mir nicht sicher, was Sie als Reproduktion bevorzugen, aber dieser PHP-Code kann es gut reproduzieren.

Code 

// openssl genrsa -out keypair.pem 2048
$keypair = openssl_pkey_get_private(file_get_contents("keypair.pem"));

// Holen Sie sich den öffentlichen Schlüssel
$public = openssl_pkey_get_details($keypair)["key"];

// Erstellen Sie die Abfrage
$query = http_build_query([
    "auth_redirect" => "https://localhost/redirect",
    "application_name" => "Test repro",
    "client_id" => "7624a5376b7f52eb403a",
    "scopes" => "session_info",
    "nonce" => bin2hex(random_bytes(16)),
    "public_key" => $public
]);

$url = "https://forum.cfx.re/user-api-key/new?" . $query;
header("Location: " . $url);

Die erste und wiederholte Autorisierung wird als erster Benutzer erfolgreich sein. Wenn sie für einen anderen Benutzer ohne Änderung der client_id erneut verwendet wird, schlägt sie fehl.
image

Benutzer-API-Schlüssel werden verwendet, um dem Benutzer die Verwendung seines Forenkontos im Spielclient zu ermöglichen, damit er aus dem Spiel heraus posten kann. Wir haben auch viele Benutzer, die sie verwenden, um sich mit Forenkonto bei ihren eigenen Websites zu authentifizieren.

Während die client_id für die Spielclients eindeutig sein sollte, sodass jeder Client als separater Client im Apps-Bildschirm aufgeführt wird. Für den Website-Anwendungsfall möchten Sie eine client_id haben, damit nicht jede Anmeldung separat aufgeführt wird.

3 „Gefällt mir“
9

Wurde das geklärt?

10

Gibt es ein Update dazu? Es ist immer noch unklar, ob die client_id global eindeutig sein sollte und nicht pro Benutzer.

1 „Gefällt mir“
11

Es sollte global eindeutig sein.

12

Wie sollte das für Anwendungsfälle implementiert werden, bei denen eine Website kein eigenes Authentifizierungssystem für Benutzer hat und keine mehreren Benutzer-API-Anwendungen erstellen sollte?

2 „Gefällt mir“
13

Cookie setzen? Oder ihn durch Hashing von etwas bestimmen, das den Benutzer identifiziert (plus etwas „Geheimes“, damit externe Parteien ihn nicht replizieren können)

14

Wenn die Anwendung, die Benutzer authentifiziert, auf mehreren Computern verwendet werden soll und vor der Authentifizierung keine Benutzerdaten vorhanden sind, ist dies unmöglich.

15

Ich verstehe nicht, wie das mit dem OP zusammenhängt, da dies einen Fall beschreibt, in dem eine Client-ID von mehreren Benutzern gemeinsam genutzt wird, während Ihr Fall beschreibt, dass ein Benutzer mehrere Client-IDs hat.

Es wird Client-ID und nicht Benutzer-ID genannt, weil ein Benutzer mehrere Clients haben kann!

16

In den meisten Standards wie OAuth wird die Client-ID als „App-Identifikator“ beschrieben und kann für alle Benutzer verwendet werden (nicht nur für einen). Zum Beispiel verwenden Ihre Social-Login-Funktionen im Forum immer dieselbe Client-ID.

Da Benutzer-API-Schlüssel jedoch hauptsächlich für Clients wie Discourse-Apps konzipiert zu sein scheinen, wurden sie möglicherweise so konzipiert, dass sie eindeutig sind. Es wäre gut zu wissen, ob dies der Fall ist.

Die Beantwortung des oben genannten würde klären, ob in user_api_keys.rb eine Prüfung fehlt oder ein falscher Index in der Datenbank vorhanden ist. Denn derzeit führen diese Anfragen zu einem beängstigenden 500-Fehler und werden in unserem /logs-Endpunkt angezeigt.

1 „Gefällt mir“
17

Gibt es Neuigkeiten dazu? Wir sehen immer noch, dass Benutzer damit Probleme haben.

1 „Gefällt mir“
18

Der Fehler sollte besser sein, ja, aber die client_id muss eindeutig sein.

Wenn Sie Benutzer auf diese Weise senden, müssen Sie eine eindeutige ID in Ihrem API-Aufruf generieren. Der Index ist korrekt, 1 Benutzer kann N client_ids haben.