2013-09-16 17 views
10

Ho un'app che sto scrivendo che autentica contro un server di autorizzazione Oauth 2.0. Mi piacerebbe testare le parti accessibili solo dopo aver effettuato l'accesso, ma il server Oauth è una dipendenza esterna che complica e rende fragile i miei test.Mocking dei provider Oauth durante il test

Qualche suggerimento su come dovrei fare questo? Cosa pratica l'industria per qualcosa di simile? Il mio istinto è di prendere in giro in qualche modo il server in modo che consenta l'accesso alle risorse protette.

Se è importante, questa è una webapp Python scritta utilizzando Flask.

Sto utilizzando un server oauth personalizzato che verrà eseguito sul mio dominio e mentre è possibile aggiungere alcune funzionalità di sandboxing come suggerito da FoxMask, preferirei molto poter eseguire il test senza richiedere un server aggiuntivo in esecuzione.

+0

in genere, l'Oauth "esterno" (come per il servizio Twitter, Evernote, ecc.) Fornisce un sanbox per i nostri test. Non ne hai trovato uno per quello scopo? –

+0

Ma avrebbero ancora bisogno di autenticarsi contro di loro? Solo che ti inviano false credenziali per il test? –

+0

sì certo che lo richiedono.si hanno restituito credenziali fittizie o equivalenti. Evernote, ad esempio, fornisce chiavi speciali solo a scopo di test. E questo fa il trucco per completare il nostro sviluppo con l'API. Una volta che arricherai il tuo dev per avviare la produzione, otterrai una nuova chiave API per la produzione. –

risposta

8

dal consumatore (cioè l'applicazione) lato, il processo OAuth2 può essere separato in due parti:

  1. il reindirizzamento dalla vostra applicazione per il provider OAuth2 "autorizzare" URL
  2. lo scambio del "codice" restituito dal fornitore OAuth2 per un token di accesso

per 1 tutto ciò che serve per testare # è che quando si richiama il percorso che avvia il processo di autenticazione la risposta restituito è un redirect al provider OAuth2. Questo è facilmente realizzabile con Flask's test client. La risposta dovrebbe avere un codice di stato di 302 e un'intestazione "Location" impostata sull'URL di autorizzazione per il provider OAuth2. Tieni presente che non è necessario che il fornitore sia attivo, stai solo testando che la risposta è un reindirizzamento, ma non è necessario reindirizzare effettivamente.

Il test per il n. 2 è un po 'più impegnativo. L'app Flask ha un URL speciale che è designato come "URL di reindirizzamento" per il provider OAuth2 che ti restituisce il codice di autorizzazione. Puoi semplicemente richiamare questo URL con il client di prova Flask che passa un codice simulato e che non ha alcun problema.

Il problema è che nella funzione di visualizzazione che gestisce l'URL di reindirizzamento è necessario richiamare il provider OAuth2 per scambiare il codice di autenticazione per un token di accesso e ciò avviene in modo sincrono. Per impedire che questa transazione avvenga, è necessario controllare lo app.config['TESTING'] e in tal caso saltare la richiesta effettiva e sostituirla con una risposta falsa che include un token di accesso fittizio.

Da quel momento in poi sarà necessario anche falsificare eventuali chiamate aggiuntive nel provider OAuth2 che inviano il token di accesso per richiedere dati.

Se si utilizza una libreria client OAuth2 nell'app Flask, può essere più semplice creare il fornitore fittizio senza dover creare eccezioni di test nell'applicazione. Nel mio caso sto usando rauth e per questo ho creato una sottoclasse della classe OAuth2Service che sovrascrive i metodi corretti e risponde con dati falsi che ho catturato da una sessione reale. Poi nella mia installazione di prova creo semplicemente il servizio di simulazione e l'applicazione viene ingannata nel pensare che stia parlando con un vero server.

Spero che questo aiuti.

+0

Quindi per la sottoclasse di OAuth2Service, devi separare sufficientemente la creazione della sessione in modo da poter stabilire quale versione di OAuth2Service istanziare per i test? – Basil