Endpoint API users/by-external/ fallisce con header di autorizzazione, funziona senza

Bug
1

A partire dal 24 marzo, sembra esserci stato un cambiamento nel modo in cui l’API di Discourse risponde alle richieste.

Non sono state apportate modifiche al codice da parte nostra e la Api-Key è ancora valida, ma uno dei nostri servizi backend che tenta di ottenere informazioni sull’utente ha iniziato a fallire quando raggiunge users/by-external/{id}.json.

Inviamo gli header Api-Key e Api-Username con queste richieste, che dovrebbero essere obbligatori, secondo la documentazione. Queste richieste hanno funzionato correttamente per anni.

Ora, tutte le richieste effettuate a questo endpoint falliscono con un 403 e il corpo della risposta:

{
    "errors": [
        "Non sei autorizzato a visualizzare la risorsa richiesta."
    ],
    "error_type": "invalid_access"
}

Questo accade anche se provo a richiedere /u/{username}.json.

Sorprendentemente, quando NON invio gli header, queste richieste che, secondo la documentazione, richiedono questi header di autenticazione, rispondono effettivamente con i dati richiesti, come se fossero autenticate.

Ho anche provato a inviare una Api-Key errata e la risposta è leggermente diversa:

{
    "errors": [
        "Non sei autorizzato a visualizzare la risorsa richiesta. L'username o la chiave API non sono validi."
    ],
    "error_type": "invalid_access"
}

Ciò mi dice che la chiave viene accettata, ma segnala erroneamente che non concede l’accesso alla risorsa, mentre concede pieno accesso alle richieste non autenticate.

Ho anche appena testato con una Api-Key nuova di zecca con opzioni globali / tutti gli utenti e ottengo gli stessi risultati.

4 Mi Piace
10

Dopo aver lavorato su questo con @Tim_Scaffidi, ci siamo resi conto che l’utente passato per Api-Username era stato automaticamente disattivato da SiteSetting.invalidate_inactive_admin_email_after_days. Probabilmente c’è un bug correlato a questa impostazione in cui le chiamate API effettuate da un utente non aggiornano l’attività di “accesso” di tale utente.

7 Mi Piace
15

Ho esaminato nuovamente la questione per vedere se ci fosse del codice da modificare per migliorare le cose, ma poiché il problema si è verificato solo perché veniva utilizzata una chiave API “Tutti gli utenti”, non credo che dovremmo modificare nulla a livello di codice. L’opzione migliore per evitare la disattivazione dell’utente è utilizzare una chiave API “Utente singolo” in modo da poter controllare last_used_at sul record della chiave API invece di provare a controllare last_seen_at sul record dell’utente.

1 Mi Piace