Cosa aspettarsi quando il verificatore è sbagliato

Question

Lasciami spiegare prima il mio scenario. Sto usando Scribe per connettermi tramite OAuth a un'API non direttamente supportata da scriba. Detto questo, il server a cui mi sto collegando richiede di inserire un numero di 4 cifre come passaggio finale per poter creare AccessToken.

Mentre questo funziona alla grande, quando l'utente inserisce le 4 cifre errate, l'app rimane in esecuzione per sempre, non viene lanciato alcun errore o eccezione (per mia comprensione). Questo è il codice che sto usando:

//verifierString has the 4-digit number
verifier = new Verifier(verifierString);
Logger.debug("Trading the Request Token for an Access Token...");
accessToken = service.getAccessToken(requestToken, verifier);

L'app rimane a GetAccessToken per sempre. Mi chiedo se esiste un modo per controllarlo, dal momento che è molto probabile che gli utenti inseriscano il 4 cifre. Ho controllato il codice per GetAccessToken, Oauth 1.0 dato che è quello che sto usando:

public Token getAccessToken(Token requestToken, Verifier verifier)
{
    config.log("obtaining access token from " + api.getAccessTokenEndpoint());
    OAuthRequest request = new OAuthRequest(api.getAccessTokenVerb(), api.getAccessTokenEndpoint());
    request.addOAuthParameter(OAuthConstants.TOKEN, requestToken.getToken());
    request.addOAuthParameter(OAuthConstants.VERIFIER, verifier.getValue());
    config.log("setting token to: " + requestToken + " and verifier to: " + verifier);
    addOAuthParams(request, requestToken);
    appendSignature(request);
    Response response = request.send();
    return api.getAccessTokenExtractor().extract(response.getBody());
}

Sembra solo che Send () lanci una runtimeException, ma non sia sicuro che catturarlo dal mio codice sia il modo giusto per farlo ... qualche suggerimento?

Grazie ! Alex

Answer 1

Se provi qualcuno scribe Esempi vedrai che inserire un codice Verifier sbagliato si traduce in un immediato OAuthException (Nota che è un OAuthException Tuttavia, come lo dichiari correttamente eredita da RuntimeException, questo è per progettazione poiché sono al 100% contro le eccezioni controllate).

Il problema è sul lato server, per quello che dici che mantiene aperta la connessione HTTP a lungo o forse anche per sempre, fino a quando non si verifica il timeout di connessione predefinito.

Forse se chiedi nei forum API otterrai una risposta migliore, anche usando Scribe debug La modalità (nuova da 1.3.0) aiuta a diagnosticare la maggior parte dei problemi.