32

Sto creando un servizio RESTful per fornire dati a un'applicazione Web. Ho due domande correlate su questo.Autorizzazione in API HTTP RESTful, 401 Autenticazione WWW

1. Come gestire richieste non autorizzate?

io ho intenzione di rispondere alle richieste con i seguenti codici:

  • è la risorsa aperta e ha trovato? 200 OK
  • È necessario essere autenticati per accedere alle risorse? 401 Non autorizzato
  • Non hai accesso a una categoria di risorse? 403 Forbidden
  • Hai accesso a una categoria di risorse, ma non a questa risorsa specifica? 404 non trovato per impedire alle persone di conoscere l'esistenza di una risorsa a cui non hanno accesso.
  • La risorsa non esiste? 404 Not Found

E 'questo un modo consigliato per un servizio RESTful comportarsi?

2. Quale intestazione WWW-Authenticate deve fornire 401 risposte?

ho letto su Wikipedia (probabilmente non la risorsa più accurata, ma funziona per me) che una risposta 401 must includere un'intestazione WWW-Authenticate, tuttavia dopo ulteriori ricerche non ho potuto davvero trovare qualsiasi risorsa che ha dichiarato ciò che questo valore significa e cosa dovrebbe essere.

Ho trovato diverse domande su SO e argomenti del forum su questa intestazione e sembrano tutte relative a OAuth, suggeriscono di non utilizzare codici di stato 401 o di dire che si può semplicemente inventare qualcosa.

Qual è il valore corretto che deve contenere questa intestazione?

risposta

19

per rispondere alle vostre domande:

Come a trattare le richieste non autorizzate?

Il modo in cui l'hai descritto è praticamente il modo consigliato per un servizio RESTful. Per quanto posso vedere, non c'è assolutamente nulla di sbagliato in questo.

Quale intestazione WWW-Authenticate deve fornire 401 risposte?

In generale l'intestazione WWW-Authenticate indica al client il tipo di autenticazione che il server accetterà. Se il cliente fa una richiesta non autorizzata, il che significa che sta inviando una richiesta con un'intestazione Authorization mancante o non valida, il server utilizzerà WWW-Authenticate per comunicare al client quale schema di autenticazione accetterà (ovvero Basic, Digest o OAuth) e per quale ambito .

Immagina come una sorta di domanda di identificazione o di sfida da parte del server, ad esempio "Chi sei?" oppure "Dimostra chi sei fornendo le credenziali nel modo seguente!".

Per esempio: WWW-Authenticate: Basic realm="My App"

Qui il server indica al client che usa uno schema di autenticazione di nome di base. Il regno non è altro che una stringa che identifica uno spazio protetto sul server.

+0

Quindi, nello scenario in cui dispongo di un servizio Web che fornisce dati per un'applicazione Web, che aspetto ha l'intestazione? Qualcosa in termini di 'Forms realm =" http://my.domain.com/ "'? – Aidiakapi

+1

Sì, potrebbe essere simile a questo. Il regno non ha bisogno di essere il nome di dominio. Può essere qualsiasi stringa. Il valore identifica solo un gruppo di risorse che condividono le credenziali. In questo modo è possibile raggruppare le risorse protette su un server in più spazi di protezione, ciascuno con il proprio schema di autenticazione e/o database di autorizzazione. – benjiman

0

Sulla base della mia ricerca (su google) ho deciso di inviare: Newauth realm = "usa token di accesso".

Il sito Web http://greenbytes.de/tech/tc/httpauth/#unknown ha casi di test per diversi metodi di autenticazione e non ho trovato nulla che descrive 'get auth token' e quindi penso che sia un 'Newauth'.

Importante anche per me: questo non crea un prompt di accesso sul lato client.

+1

I nuovi schemi dovrebbero essere registrati. –

+0

@ JulianReschke avete qualche informazione su come farlo? O dove hai trovato quelle informazioni (probabilmente qualche pagina rfc?)? Come lo faresti su un'API REST? – sigi

+0

È tutto descritto nella RFC 7235. –

Problemi correlati