Pensi che avrebbe senso saltare gli script javascript di rilevamento del browser quando qualcuno utilizza l’endpoint
https://sitename.com/user-api-key/new
? È molto probabile che vengano reindirizzati lì da un’app, quindi controllare se il loro motore javascript è all’altezza ha poco senso e blocca solo gli utenti che desiderano generare una chiave API per l’uso in-app.
Ma devi ancora accedere affinché funzioni
Sì, questo è il problema, quando user-api-key/new ti reindirizza a una pagina di accesso, inizia a controllare il tuo browser e invece di consentire l’accesso per generare una chiave API, si lamenta che il tuo browser è troppo vecchio, forse salta quei controlli se l’utente è qui solo per generare una chiave API?
Sì, questo è il problema, è una sorta di richiesta di un modo per accedere senza JavaScript, il che è incredibilmente complesso date le enormi quantità di opzioni di autenticazione che supportiamo e le misure di prevenzione dello spam.
Non ha bisogno di essere javascriptless, solo che i moduli di accesso non necessitano di tutti gli effetti speciali utilizzati altrove sul sito? Almeno per il passthrough verso auth/oauth2_basic non sembra essere necessario poiché il 99% viene fatto con header e reindirizzamenti. Ho un’app su SailfishOS che funziona perfettamente con i .json e passando la api-key, il che è ottimo dato che il browser lì è basato su esr78 firefox e viene bloccato nella maggior parte delle istanze di discourse, ma l’unico modo per ottenere una api-key sembra essere inserire manualmente un URL di oltre 200 caratteri sul desktop, per poi incollare il codice risultante sul telefono per decodificarlo, assolutamente ridicolo.
5 messaggi sono stati spostati in un nuovo argomento: Le chiavi API utente dovrebbero utilizzare il padding OAEP
Ciao ragazzi. Stavo usando le chiavi API utente per accedere tramite un client di terze parti. Funzionava bene. Ma ora ricevo un messaggio di errore su alcuni siti
Il messaggio è
Oops
Il software che alimenta questo forum di discussione ha riscontrato un problema imprevisto. Ci scusiamo per l'inconveniente.
Informazioni dettagliate sull'errore sono state registrate e generata una notifica automatica. Ci daremo un'occhiata.
Non è necessaria alcuna ulteriore azione. Tuttavia, se la condizione di errore persiste, è possibile fornire ulteriori dettagli, inclusi i passaggi per riprodurre l'errore, pubblicando un argomento di discussione nella categoria di feedback del sito.
C’è stato un cambiamento in questa funzionalità nelle ultime versioni?
Intendi “accedere”? Penso che Discourse Connect sia probabilmente un modo migliore per farlo, anche se non so cosa stai facendo esattamente.
Dovrai controllare i log per ottenere maggiori informazioni sull’errore.
Sto eseguendo un’interfaccia utente personalizzata, quindi devo eseguire azioni per conto dell’utente. Per questo sto usando le chiavi API utente.
Per questo sto usando il seguente URL
https://discussion.fedoraproject.org/user-api-key/new?auth_redirect=discourse%3A%2F%2Fauth_redirect&application_name=DisCorkie&client_id=019695ed-8b7e-71b1-b55e-7efe8be1e9ae&scopes=read%2Cwrite%2Cnotifications%2Cpush%2Csession_info&push_url=https%3A%2F%2Fherxbktlunuawewahana.supabase.co%2Ffunctions%2Fv1%2Fdiscourse-webhook&public_key=-----BEGIN+PUBLIC+KEY-----%0AMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkD%2BNgNuAMv2ZSSR95V1B%0Afla9n3HbCPxAFB5%2B%2BitC9hlWEOfXZPToWAax5DuNUitzikLVWrldyRe%2BfgtS5F3Q%0AGvuzCtnFwyBNoIkuUva8uCzQ4K7T9RgnWIIfNsx2ONuk2GLhEeLUgb46F8VULbD3%0A4eExqEYoGK7tBxr3%2FnVYO%2FogOaibzhoZRiSh69gq6ptXWN9Pka%2Fb3%2Fp2hWF5MSwG%0AK39LiZKOzaga%2BsA0lA0BgdAw7rvnUBfpikL33mqtEJ6JDPhG5KIvBxY2m18T63cX%0AKakxrmZzWwibN%2Bzboe51Z49gtxJIiybaj5Yn7izPj39DKwiv5k%2FaSWFAe8FO0doQ%0AxVoh9qVhlvPq3DdLhcjC0djVNti3X%2BYC2bwUDSp%2BFhrLh%2BsYribCAp6P8TyZ5TZy%0Aw0WnDCatK%2FzPq53Fja2OUa5N43Zr4rSiyQMSdBaeOJwF33nOAHwztkDwOJvSh6fx%0Ag2mTR15Qe%2FRh6yY4fB610mcut%2BBU1oV4SEbxHYyroTaS06oO6k4EmvgJTiWK%2BVVC%0AfMGgFvoPXktKckK0q7xj32PiSTVlYURb27ap7yAHzFKePYkJdo0Sd3Jzghe1RdSg%0A4teQs4VecqIe%2Bv6p7BurFgwlKZyWN0n89u8%2BXihwwwOcVp1UHblqbl%2FKYi5%2BgK6O%0AyahsLRGMGllNIsqarYCZ9nkCAwEAAQ%3D%3D%0A-----END+PUBLIC+KEY-----%0A&nonce=-1646128802
Dove
PARAMETRI
auth_redirect: discourse://auth_redirect
application_name: DisCorkie
client_id: 019695ed-8b7e-71b1-b55e-7efe8be1e9ae
scopes: read,write,notifications,push,session_info
push_url: https://herxbktlunuawewahana.supabase.co/functions/v1/discourse-webhook
public_key:
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkD+NgNuAMv2ZSSR95V1B
fla9n3HbCPxAFB5++itC9hlWEOfXZPToWAax5DuNUitzikLVWrldyRe+fgtS5F3Q
GvuzCtnFwyBNoIkuUva8uCzQ4K7T9RgnWIIfNsx2ONuk2GLhEeLUgb46F8VULbD3
4eExqEYoGK7tBxr3/nVYO/ogOaibzhoZRiSh69gq6ptXWN9Pka/b3/p2hWF5MSwG
K39LiZKOzaga+sA0lA0BgdAw7rvnUBfpikL33mqtEJ6JDPhG5KIvBxY2m18T63cX
KakxrmZzWwibN+zboe51Z49gtxJIiybaj5Yn7izPj39DKwiv5k/aSWFAe8FO0doQ
xVoh9qVhlvPq3DdLhcjC0djVNti3X+YC2bwUDSp+FhrLh+sYribCAp6P8TyZ5TZy
w0WnDCatK/zPq53Fja2OUa5N43Zr4rSiyQMSdBaeOJwF33nOAHwztkDwOJvSh6fx
g2mTR15Qe/Rh6yY4fB610mcut+BU1oV4SEbxHYyroTaS06oO6k4EmvgJTiWK+VVC
fMGgFvoPXktKckK0q7xj32PiSTVlYURb27ap7yAHzFKePYkJdo0Sd3Jzghe1RdSg
4teQs4VecqIe+v6p7BurFgwlKZyWN0n89u8+XihwwwOcVp1UHblqbl/KYi5+gK6O
yahsLRGMGllNIsqarYCZ9nkCAwEAAQ==
-----END PUBLIC KEY-----
nonce:-1646128802
Viene reindirizzato a /login, il browser chiama /session/csrf con successo, finora nessun problema.
Tuttavia, quando il browser chiama /auth/oauth2_basic ricevo un errore 500.
La risposta è questo messaggio di errore e nessuna informazione aggiuntiva.
Discourse hub esegue un flusso di autenticazione simile ma funziona. C’è qualcosa che mi sfugge?
Qualcosa in /logs?
Dopo alcune indagini ho scoperto che questo problema si verificava perché stavo usando chiavi da 4096 bit. Le ho cambiate in 2048 e ha ricominciato a funzionare correttamente.
Questa dimensione della chiave è un requisito? È documentata da qualche parte?