Codice di risposta HTTP per proxy con risorsa di connessione scaduta

Question

Codice di risposta HTTP per proxy con risorsa di connessione scaduta

#1 da (1 voti)

0

Sto creando un servizio che funge da proxy per fornitori di dati di terze parti per l'utente finale. Il mio servizio utilizza token per l'autorizzazione e se l'utente non ha un token valido risponde con 401 Unauthorized . Se il token è valido ma viene negato l'accesso alla risorsa, il mio servizio risponde con 403 Forbidden .

Il servizio recupera dati da fornitori di dati di terze parti. Questi fornitori di dati utilizzano gli stessi codici di risposta (401/403). Quando tale token è scaduto, l'utente finale deve immettere nuovamente le proprie credenziali per quel servizio in modo che il mio servizio possa richiedere nuovi token dai provider di terze parti.

Se inoltro il 401/403 dal fornitore di dati di terze parti al mio utente finale, non sarà in grado di sapere se l'autorizzazione non è stata eseguita nei confronti del mio servizio o della terza parte. I framework che sto usando non mi permettono di cambiare il messaggio né di inviare un corpo con la risposta.

Ho riflettuto su quale codice di stato posso utilizzare e ho pensato a 511 Network Authentication Required . Questo codice è utilizzato da "proxy" e il mio servizio funge da proxy, anche se forse non nel modo in cui un proxy di rete "normale" fa.

Vorrebbe 511 essere un codice di stato ragionevole da usare o c'è qualcosa di meglio?

rest http

posta span 20.12.2017 - 10:06

fonte

1 risposta

Leggi altre domande sui tag rest http

Come deviare il traffico IP di 1 sito per testare il nuovo codice prima della distribuzione Possiamo usare multi tenancy dello schema condiviso (usando la colonna tenant_id per scope) combinato con un approccio a schema separato

score 1 · Accepted Answer

Non penso che il codice 511 sia appropriato per quello che descrivi. Il caso d'uso principale per quel codice è un "captive portal" come la penna che si tiene in una caffetteria prima di accettare i termini di utilizzo e / o l'accesso alla pagina web del coffee shop.

Il tuo uso è praticamente ciò che oauth è progettato per gestire; un'applicazione client che interagisce con i server di risorse per conto di un proprietario di risorse.

Ci sono due punti di autenticazione, acquisizione di autenticazione / accesso al token di accesso e acquisizione di token di aggiornamento. Presumibilmente, hai capito come autenticare l'utente al primo accesso ai server delle risorse.

Quando il token di accesso scade, è necessario utilizzare un token di aggiornamento per richiedere un nuovo token di accesso (per conto dell'utente) in modo che le richieste attuali e future possano procedere senza l'interazione del proprietario della risorsa. Se i server di autenticazione per le risorse a cui si sta accedendo forniscono token di aggiornamento, è necessario conservarli e utilizzarli per acquisire nuovi token di accesso quando le richieste non riescono (e non inviare un 401 indietro).

I server di autorizzazione non sono obbligati a inviare token di aggiornamento. In tal caso, un 401 da un server delle risorse dovrebbe attivare nuovamente il flusso di autorizzazione iniziale (per recuperare un nuovo token di accesso). Normalmente, si tratta di un reindirizzamento 302 al server di autorizzazione con client_id, scope, ecc. So che hai detto che non puoi modificare il corpo della risposta ma, dato che stai considerando il codice di risposta 511, devi essere in grado di emettere un 302.

Suggerirei, se in effetti stai utilizzando oauth anche per la tua app, che non invii mai un 401 per un token scaduto, ma usi sempre il token di aggiornamento per riottenere l'accesso al server delle risorse (se disponibile) o reindirizzare al punto di autorizzazione appropriato per continuare la richiesta.