Come dovrei specificare le posizioni in cui i clienti possono risolvere i problemi di autorizzazione in un'API REST?

Question

Come dovrei specificare le posizioni in cui i clienti possono risolvere i problemi di autorizzazione in un'API REST?

#1 da (2 voti)
#2 da (0 voti)

3

Sto lavorando a una progettazione API in cui l'autenticazione dell'utente verrà verificata dalla presenza di un ticket di autenticazione moduli valido in un cookie di sessione. Tuttavia, esistono ulteriori livelli di accesso che possono esistere per particolari URL di risorse. Quando si tenta di accedere a quelli, sembra che restituire un 401 sarebbe la risposta più appropriata.

Tuttavia, generalmente gestiamo i 401 reindirizzando a una pagina di accesso. Non sarebbe una valida linea di condotta per i clienti su determinate risorse, laddove è richiesto un ulteriore passaggio (ad es. Convalida e-mail, registrazione per un ruolo particolare).

C'è un modo standard per comunicare dove andare dopo quando rispondi con un 401? Sono tentato di includere qualcosa nell'intestazione Location, ma ciò sembra appropriato solo per 302 dopo un POST. Sono anche riluttante a utilizzare gli URL per specificare dove andare, poiché i client potrebbero non essere limitati ai browser.

eventuali buoni esempi o documenti standard a cui posso fare riferimento in questo?

rest http http-response authorization

posta Brandon Linton 03.12.2013 - 19:05

fonte

2 risposte

0

Ho sempre considerato i reindirizzamenti come parte della convenienza per l'interfaccia utente o l'agente dell'interfaccia utente. Mentre l'API REST è più simile a una normale funzione API destinata ai client che sono stati codificati specificamente per comunicare con esso.

Proprio come molte funzioni del sistema operativo potrebbero non funzionare con "accesso negato" e non reindirizzare l'utente verso una risorsa di autenticazione, non mi aspetto che l'API REST possa reindirizzarmi. Se qualcuno codifica il client per parlare con il tuo server REST, quel client deve anche essere codificato per eseguire l'autenticazione corretta in primo luogo.

Quindi la mia risposta sarebbe quella di rispondere con 401, o forse anche con 403 vietato per distinguere tra client che non sono autenticati e quelli che sono autenticati ma non hanno le autorizzazioni corrette. E possibilmente includere una stringa di testo leggibile dall'uomo che indica il motivo per l'autenticazione / l'errore di autorizzazione, ma non preoccuparti di eventuali reindirizzamenti.

risposta data 03.12.2013 - 19:55

fonte

Leggi altre domande sui tag rest http http-response authorization

Serve un algoritmo di ottimizzazione TFS merging - come tenere traccia di quali modifiche entrano in MAIN?

score 2 · Accepted Answer

Non vedo nulla nella intestazione di posizione RFC-2616 che limita il suo utilizzo 3xx o 201 risposte di stato HTTP. Sono d'accordo che la risposta 401 sarebbe appropriata dal momento che la risposta di stato HTTP 403 implica che non c'è ricorso anche quando è possibile un'autenticazione successiva. Quello che stai suggerendo è una variazione specifica dell'applicazione sul protocollo di autenticazione HTTP di base .

Questo StackOverflow risponde a una domanda simile fornisce un esempio che include la posizione come parte del contenuto dell'intestazione WWW-Authenticate richiesto in una risposta 401 anziché nell'intestazione Location separata . Credo che entrambi gli approcci rispettino la RFC-2616 & Specifiche RFC-2617 ma vorrei scegliere di incorporare la posizione nel contenuto dell'intestazione dell'autenticazione WWW a causa della sua semplicità di implementazione dal momento che mantiene tutte le informazioni di autenticazione specifiche dell'applicazione in un unico luogo.