Codice di stato HTTP corretto quando la risorsa è disponibile ma non accessibile a causa delle autorizzazioni

Sto costruendo un protocollo RESTful per le applicazioni Dynamic Carpooling, per la mia tesi di Computer Science.Codice di stato HTTP corretto quando la risorsa è disponibile ma non accessibile a causa delle autorizzazioni

Nel protocollo devo anche specificare formalmente il codice di stato HTTP per ogni operazione. Ho questo problema "relativo alla privacy". Supponiamo la seguente:

GET /api/persons/angela/location

Recupera la posizione attuale dell'utente "angela". È ovvio che non tutti dovrebbero essere in grado di ottenere un risultato. Solo la stessa angela e un possibile guidatore che la sceglieranno dovrebbero saperlo.

Non riesco a decidere se restituire un 404 non trovato o un 401 Proibito qui.

Eventuali suggerimenti? Quale sarebbe la migliore e perché?

fonte

2010-08-23 dgraziotin

Un 404 è completamente errato qui poiché indica che il record non esiste affatto. – You

Secondo Wikipedia (e RFC 2616), un codice 401 viene utilizzato quando esiste una pagina ma richiede l'autenticazione; 403 è per una pagina in cui l'autenticazione non cambierà nulla. (In natura, 403 di solito significa che le autorizzazioni su qualcosa sono errate, mentre un 401 chiederà all'utente un nome utente/password). 404 è per cui il documento semplicemente non esiste.

Nel tuo caso, sembra che 401 sia il codice più appropriato, poiché esiste un modo per autenticare gli utenti che hanno accesso alla pagina.

fonte

2010-08-23 12:30:22 Phil

Buono! Abbastanza le operazioni di protocollo intero richiedono autenticazioni. Ho casi in cui le risorse sono disponibili ma non possono essere recuperate a causa dei diritti degli utenti e anche i casi in cui le risorse non sono disponibili perché sono state precedentemente eliminate. Entrambi i casi sono in operazioni autenticate. Vuoi andare per un 401 nel primo caso e un 404 per il secondo caso? : la risorsa esiste ma non è possibile accedervi -> 401 risorsa inesistente -> 404 – dgraziotin

Sì, se una risorsa è stata eliminata, un 404 è appropriato se successivamente viene effettuato un tentativo di accesso. – Phil

Buona risposta, ma preferirei "secondo Wikipedia" dire "secondo RFC 2616" http://tools.ietf.org/html/rfc2616#section-10.4.2;) – Day

Definitivamente NON 404. 404 non è stato trovato.
401 accesso negato.
403 è vietato.

vorrei andare con 401

fonte

2010-08-23 12:33:03 DmitryK

401 è * non * accesso negato.È "non connesso e accesso richiesto". –

@EricStein Secondo RFC 2616 (http://tools.ietf.org/html/rfc2616#section-10.4.2), "Se la richiesta includeva già le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per quelle credenziali . " Quindi 401 è in realtà negato l'accesso. –

-1

Se credenziali di autorizzazione sono forniti nella richiesta e il richiedente non dispone delle autorizzazioni per accedere a questa risorsa allora si dovrebbe tornare 403.

Se credenziali di autorizzazione sono forniti nel richiesta quindi si dovrebbe restituire 401.

fonte

2010-08-23 12:51:53

Se nella richiesta sono fornite le credenziali di autorizzazione e il richiedente non dispone delle autorizzazioni per accedere a questa risorsa, è necessario restituire 401 non un 403. RFC 2616 dice esplicitamente che per un 403 "L'autorizzazione non sarà d'aiuto e la richiesta NON DEVE essere ripetuta "(http://tools.ietf.org/html/rfc2616#section-10.4.4). Quindi se ci sono credenziali valide che darebbero il permesso di accedere alla risorsa, non restituire un 403. – Day

@Day Hai assolutamente ragione. La mia risposta è sbagliata. Hmm, impari qualcosa di nuovo ogni giorno. –

Nessun problema. Che ne dici di avere una pugnalata alla mia spin off domanda http://stackoverflow.com/q/4038981/445073 :) – Day

Per me userò 400 richiesta Bad.
Perché la mia applicazione non andrà risorse non accessibili in modo programmatico.
Filtrare il permesso degli utenti e nascondere risorse non accessibili è una buona esperienza utente secondo me. Se il mio server ha ricevuto una richiesta inaccessibile che significa che qualcuno sta cercando di fare qualcosa.
Ecco perché scelgo 400 - Richiesta non valida nelle mie applicazioni.

fonte

2016-09-11 02:24:05 jeefo

Non sono d'accordo. rispondere con 400 Bad Request per richieste valide è un'API non funzionante. 400 Bad Request significa che qualcosa non va nella richiesta. Chiunque usi la tua API penserà che la richiesta sia sbagliata, quando in realtà la richiesta è giusta, questo è letteralmente ciò che sono 401 e 403. Semplifica il debug delle cose. –

Come ho detto, i normali utenti non richiedono mai risorse non accessibili. Se il mio server ha ricevuto una richiesta inaccessibile, il che significa che qualche persona subdolo tenta di hackerare risorse non accessibili. Inoltre non risponderò mai il codice di errore per le richieste valide. – jeefo

In generale non dovresti mai fare ipotesi su ciò che gli utenti normali faranno e non faranno. L'autenticazione non è necessariamente parte della richiesta. Se sei preoccupato per le persone subdole, la soluzione corretta non è la rottura intenzionale dell'HTTP (sicurezza per oscurità). La soluzione corretta è mettere un firewall davanti alla tua API, in modo che le persone subdole non possano nemmeno sondare la tua API in primo luogo. –

Codice di stato HTTP corretto quando la risorsa è disponibile ma non accessibile a causa delle autorizzazioni

risposta

Problemi correlati