Pentru o pagină web care există, dar pentru care un utilizator care nu dispune de suficiente privilegii, (nu sunt logat sau nu aparțin corespunzătoare grupului de utilizatori), ceea ce este adecvat de răspuns HTTP pentru a servi? 401? 403? Altceva? Ceea ce am'am citit pe fiecare de până acum e't foarte clar diferența dintre cele două. Ce cazuri de utilizare sunt adecvate pentru fiecare răspuns?
O explicație clară din Daniel Irvine:
Nu's o problemă cu 401 Neautorizate, codul de stare HTTP pentru autentificare erori. Și tocmai asta e: e pentru autentificare, nu autorizație. Primirea unui 401 răspuns este serverul spus, "tu nu ești autentificați–fie nu legalizate sau autentificate incorect–dar te rog reauthenticate și încercați din nou." Pentru a te ajuta, acesta va include întotdeauna un WWW-Authenticate antet care descrie cum pentru a autentifica.
Acesta este un răspuns, în general, returnat de serverul dvs. de web, nu dvs. de web aplicație.
este, de asemenea, ceva foarte temporară; server te rog să încerci din nou.
Deci, pentru autorizare folosesc 403 Forbidden de răspuns. E permanent, legat de cererea mea logica, si e mai beton răspuns decât un 401.
Primirea unui 403 răspuns este serverul spus, "îmi pare rău. Stiu cine ești–eu cred că ești cine spui–dar pur si simplu nu au permisiunea de a accesa această resursă. Poate daca ai cere sistemul administrator frumos, veți obține permisiunea. Dar te rog, nu te obosi mă din nou până când situația se schimbă."
În rezumat, o 401 Neautorizate răspunsul ar trebui să fie utilizate pentru lipsă sau rău de autentificare, și o 403 Forbidden răspunsul ar trebui să fie utilizate după aceea, atunci când utilizatorul este autentificat, dar nu este autorizat să de a efectua operațiunea solicitată pe dat de resurse.
Un alt frumos pictorial format de cât de coduri de stare http ar trebui să fie utilizate.
A se vedea RFC2616:
401 Neautorizate:
Dacă cererea a inclus deja Autorizație de acreditare, apoi 401 răspuns indică faptul că autorizația a fost refuzat pentru aceste acreditări.
403 Forbidden:
server cererea de înțeles, dar refuză să-l îndeplinească.
Update
La caz de utilizare, se pare că utilizatorul nu este autentificat. Mi-ar reveni 401.
Ceva alte răspunsurile sunt lipsă este că trebuie să se înțeleagă că de Autentificare și Autorizare în contextul RFC 2616 se referă NUMAI la HTTP Authentication protocol de RFC 2617. Autentificare prin scheme afara de RFC2617 nu este acceptată în coduri de stare HTTP și nu sunt luate în considerare atunci când se decide dacă să utilizeze 401 sau 403.
Neautorizate indică faptul că clientul nu este RFC2617 autentificate și serverul inițiază procesul de autentificare. Interzis indică fie faptul că clientul este RFC2617 autentificate și nu au autorizație sau că serverul nu suportă RFC2617 pentru resursele solicitate.
Adică dacă ai propria ta roll-ti propriul proces de autentificare și nu utilizați sau nu Autentificarea HTTP, 403 este întotdeauna răspunsul adecvat și 401 nu ar trebui să fie utilizate.
Din RFC2616
10.4.2 401 Neautorizate
cererea necesită autentificarea utilizatorului. Răspunsul TREBUIE să includă o WWW-Authenticate câmp de antet (secțiunea 14.47) conțin o provocare aplicabile resursele solicitate. Clientul POATE repeta la cerere, o Autorizație potrivit câmp de antet (secțiunea 14.8).
și
10.4.4 403 Forbidden server cererea de înțeles, dar refuză să-l îndeplinească. Autorizația nu va ajuta și cererea NU ar TREBUI să fie repetate.
Primul lucru de a păstra în minte este că "Autentificare" și "Autorizare", în contextul acestui document se referă în mod specific la HTTP protocoale de Autentificare de la RFC 2617. Acestea nu se referă la orice roll-ta-proprii protocoale de autentificare poate fi creat folosind paginile de login, etc. Voi folosi "login" pentru a se referi la autentificare și autorizare prin alte metode decât RFC2617
Deci, diferența reală nu este ceea ce este problema sau chiar dacă există o soluție. Diferența este ce server se așteaptă clientul să facă în continuare.
401 indică faptul că resursa nu poate fi prevăzută, dar serverul este SOLICITAREA pe care clientul vă conectați prin HTTP Autentificare și-a trimis răspuns anteturile de a iniția procesul. Eventual există autorizații care va permite accesul la resurse, eventual, nu sunt, dar las's a-i dea un try și a vedea ce se întâmplă.
403 indică faptul că resursa nu poate fi prevăzută și nu există, pentru utilizatorul curent, nici o modalitate de a rezolva acest lucru prin RFC2617 și nici un punct în încercarea. Acest lucru poate fi, deoarece este cunoscut faptul că nici un nivel de autentificare este suficient (de exemplu din cauza unui IP neagră), dar aceasta poate fi, deoarece utilizatorul este deja autentificat și nu au autoritate. La RFC2617 model este unul de utilizator, o acreditările deci, în cazul în care utilizatorul poate avea un al doilea set de recomandări care ar putea fi autorizat poate fi ignorat. Nici nu sugerează nici nu implică faptul că un fel de pagina de logare sau alte non-RFC2617 protocol de autentificare pot sau nu pot ajuta - care este în afara RFC2616 standarde și definiții.
Resurse există ? (dacă private este verificat de multe ori DUPĂ auth verifica) | | NU | | DA v v 404 Este logat ? (autentificat, aka-a sesiune) sau | | 401 NU | | DA 403 | | v v 401 Pot accesa resurse ? (permisiunea, autorizat) ? (404 nu dezvăluie) | | sau 301 NU | | DA redirect | | să vă conectați v v 403 OK 200, 301, ... (sau 404: nu dezvăluie)
Controalele sunt, de obicei, făcut în această ordine:
NEAUTORIZATE: codul de Stare (401) indică faptul că cererea necesită autentificare, de obicei, acest lucru înseamnă că utilizatorul trebuie să fie autentificat (sesiune). Utilizator/agent necunoscut de către server. Se poate repeta cu alte acreditări. NOTĂ: Acest lucru este confuz deoarece acest lucru ar fi fost numit 'neautentificat' în loc de 'neautorizat'. Acest lucru se poate întâmpla, de asemenea, după autentificare, dacă sesiunea a expirat. Caz Special: Poate fi folosit în loc de 404 pentru a evita dezvăluie prezența sau non-prezența de resurse (credite @gingerCodeNinja)
INTERZIS: codul de Stare (403) indicând server cererea de înțeles, dar a refuzat să-l îndeplinească. Utilizator/agent cunoscut de către server dar a insuficientă acreditările. Repet cererea nu va funcționa, dacă acreditările schimbat, ceea ce este foarte puțin probabil într-un interval de timp scurt. Caz Special: Poate fi folosit în loc de 404 pentru a evita dezvăluie prezența sau non-prezența de resurse (credite @gingerCodeNinja)
NU a fost GĂSIT: codul de Stare (404) indică faptul că resursa solicitată nu este disponibilă. Utilizator/agent cunoscut, dar serverul nu va dezvălui nimic despre resursa, nu ca în cazul în care acesta nu există. Repetarea nu va funcționa. Aceasta este o utilizare specială de 404 (github face de exemplu).
Conform RFC 2616 (HTTP/1.1) 403 este trimis atunci când:
server cererea de înțeles, dar refuză să-l îndeplinească. Autorizația nu va ajuta și cererea NU ar TREBUI să fie repetate. Dacă cererea metodă nu a fost CAP și serverul dorește să facă publice motivele pentru care cererea nu a fost îndeplinită, acesta ar TREBUI să descrie motivul pentru refuzul în entitate. Dacă serverul nu doresc să facă aceste informații disponibile la client, codul de stare 404 (not found) poate fi folosit în loc
Cu alte cuvinte, în cazul în care clientul POATE avea acces la resurse prin autentificarea, 401 ar trebui să fie trimise.
Presupunând HTTP autentificare (WWW-Authenticate și Autorizare cap) este în uz, dacă autentificarea ca un alt utilizator va acorda acces la resursele solicitate, atunci 401 Neautorizate ar trebui să fie returnate.
403 Forbidden este folosit atunci când accesul la resurse este interzis pentru toată lumea sau limitată la o anumită rețea sau permis numai peste SSL, orice, atât timp cât acesta nu este legat de autentificare HTTP.
Dacă autentificarea HTTP nu este în uz și service un cookie de autentificare bazat pe schema ca este norma în zilele noastre, atunci 403 sau 404 ar trebui să fie returnate.
Cu privire la 401, acest lucru este de la RFC 7235 (Hypertext Transfer Protocol (HTTP/1.1): Autentificare):
3.1. 401 Neautorizate
401 (Neautorizate) cod de stare indică faptul că cererea a nu a fost aplicată, pentru că nu are valabil acreditările de autentificare pentru obiectivul de resurse. Pe serverul de origine TREBUIE să trimită un WWW-Authenticate câmp de antet (Secțiunea 4.4) conțin cel puțin o provocare aplicabile resurse țintă. Dacă cererea inclus acreditările de autentificare, apoi 401 răspuns indică faptul că autorizația a fost refuzat pentru cei acreditările. Clientul POATE repeta cererea cu un nou sau înlocuit de Autorizare câmp de antet (Secțiunea 4.1). Dacă 401 răspuns conține aceeași provocare ca înainte de răspuns, și agent utilizator a încercat deja de autentificare, cel puțin o dată, apoi agentul utilizator ar TREBUI să prezinte închise reprezentare a utilizator, deoarece acesta conține, de obicei, relevante informații de diagnosticare.
Semantica 403 (și 404) s-au schimbat de-a lungul timpului. Acest lucru este din 1999 (RFC 2616):
10.4.4 403 Forbidden
server cererea de înțeles, dar refuză să-l îndeplinească. Autorizație nu va ajuta și cererea NU ar TREBUI să fie repetate. Dacă cererea metodă nu a fost CAP și serverul dorește să facă publice motivele pentru care cererea nu a fost îndeplinită, acesta ar TREBUI să descrie motiv pentru refuzul în entitate. Dacă serverul nu doresc să de a face aceste informații disponibile la client, codul de stare 404 (Nu se Găsește) poate fi folosit în loc.
În 2014 RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantica și Conținut) a schimbat sensul de 403:
6.5.3. 403 Forbidden
403 (Forbidden) cod de stare indică faptul că serverul cererea de înțeles, dar refuză să-l autorizeze. Un server care dorește să facă publice motivele pentru care cererea a fost interzis descrie acest motiv, în răspunsul sarcină utilă (dacă există).
Dacă acreditările de autentificare au fost furnizate în cerere, server le consideră insuficiente pentru a acorda accesul. Clientul NU ar TREBUI să se repete automat la cerere cu același acreditările. Clientul POATE repeta cererea cu noi sau diferite acreditările. Cu toate acestea, o cerere ar putea fi interzis pentru motive nu au legătură cu acreditări.
Un server de origine care dorește să "ascunde" existența actuală a unei interzis resurse țintă POATE răspunde cu un cod de stare 404 (not found).
Astfel, un 403 (sau un 404) s-ar putea acum să spun despre nimic. Furnizarea de noi acreditări-ar putea ajuta... sau poate nu.
Cred că motivul pentru care acest lucru s-a schimbat este RFC 2616 presupune autentificarea HTTP va fi folosit atunci când, în practică, azi's aplicații Web construi personalizat schemele de autentificare folosind, de exemplu, forme și cookie-urile.
Aceasta este o mai veche întrebare, dar o opțiune care nu a fost niciodată într-adevăr a fost adus pentru a reveni un 404. Dintr-o perspectivă de securitate, cea mai votat răspuns suferă de un potențial scurgerile de informații vulnerabilitate. Spune, de exemplu, ca pagină web securizată în cauză este un sistem de administrare pagină, sau, poate, mai frecvent, este o înregistrare într-un sistem care utilizatorul nu't au acces la. În mod ideal, ar't vrea un utilizator rău intenționat chiar să știi că nu's o pagină / înregistrare acolo, să nu mai vorbim că ei don't au acces. Când m-am'm a construi ceva de genul asta, am'll încercați să înregistrați unauthenticate / neautorizate cereri interne într-un jurnal, dar se întoarce un 404.
OWASP are unele mai multe informații despre modul în care un atacator ar putea folosi acest tip de informații ca parte a unui atac.
Această întrebare a fost întrebat cu ceva timp în urmă, dar oamenii's gândire se mută pe.
Punctul 6.5.3 în acest proiect (scrisa de Fielding și Reschke) oferă statutul cod 403 un sens ușor diferit de cel documentate în RFC 2616.
Acesta reflectă ceea ce se întâmplă în autentificare & autorizatie schemele de un număr de populare web-servere și cadre.
Am'am subliniat pic cred că este cel mai proeminent.
6.5.3. 403 Forbidden
403 (Forbidden) cod de stare indică faptul că serverul cererea de înțeles, dar refuză să-l autorizeze. Un server care dorește să facă publice motivele pentru care cererea a fost interzis poate descrie acest motiv, în răspunsul sarcină utilă (dacă există).
Dacă acreditările de autentificare au fost furnizate în cerere, serverul le consideră insuficiente pentru a acorda accesul. Clientul NU ar TREBUI să repete cererea cu aceleași acreditări. Clientul POATE repeta cererea cu noi sau diferite acreditări. Cu toate acestea, o cerere ar putea fi interzis pentru motive care nu au legătură cu acreditările.
Un server de origine care dorește să "ascunde" existența actuală a unei interzis resurse țintă POATE răspunde cu un cod de stare 404 (not found).
Orice convenție utilizați, cel mai important lucru este de a asigura uniformitate în întreaga site-ul dvs. / API.
Dacă apache necesită autentificare (via .htaccess
), și te-a lovit "Anulare", se va răspunde cu o 401 Necesare pentru Autorizare
Dacă nginx găsește un fișier, dar nu are nici drepturi de acces (utilizator/grup) pentru a citi/a accesa, se va răspunde cu 403 Forbidden
Sensul 1: Necesitatea de a autentifica
cererea necesită autentificarea utilizatorului. ...
Sensul 2: Autentificare insuficientă
... Dacă cererea a inclus deja Autorizație de acreditare, apoi 401 răspuns indică faptul că autorizația a fost refuzat pentru aceste acreditări. ...
Semnificație: nu au Legătură cu autentificare
... de Autorizare nu va ajuta ...
Mai multe detalii:
server cererea de înțeles, dar refuză să-l îndeplinească.
Acesta ar TREBUI să descrie motivul pentru refuzul în entitate
codul De stare 404 (not found) poate fi folosit în loc
(Dacă serverul dorește să păstreze această informație de la client)
nu sunt logat sau nu aparțin corespunzătoare grupului de utilizatori
Trebuie menționat două cazuri diferite; în fiecare caz, ar trebui să aibă un răspuns diferit:
Notă privind RFC-a bazat pe comentariile primite pentru acest răspuns:
Dacă utilizatorul nu este logat ei sunt ne-autentificat, HTTP echivalent din care este 401 și este în mod eronat numit Neautorizate în RFC. Ca secțiunea 10.4.2 membre pentru 401 Neautorizate:
"cererea necesită utilizatorului autentificare."
Daca're neautentificat, 401 este răspunsul corect. Cu toate acestea, dacă te're neautorizate, în sens semantic corect, 403 este răspunsul corect.
Acest lucru este mai simplu decât în capul meu undeva pe-aici, deci:
401: Ai nevoie HTTP auth de bază pentru a vedea acest lucru.
403: puteți't vedea acest lucru, și HTTP auth de bază a câștigat't de ajutor.
Dacă utilizatorul trebuie doar să vă conectați folosind site-ul's HTML standard, formular de autentificare, 401, nu ar fi adecvat, deoarece acesta este specific HTTP autentificare de bază.
Eu nu't recomandăm să utilizați 403 pentru a refuza accesul la lucruri cum ar fi /include
, deoarece web-ul este în cauză, aceste resurse nu't există, la toate și, prin urmare, 404.
Acest lucru lasă 403 ca "trebuie să fii logat".
Cu alte cuvinte, 403 înseamnă "această resursă necesită o anumită formă de auth, altele decât HTTP auth de bază".
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
Cred că este important să se ia în considerare faptul că, de la un browser, 401 inițiază un dialog autentificarea pentru utilizator pentru a introduce noi acreditări, în timp ce 403 nu. Browsere cred că, dacă un 401 este returnat, atunci utilizatorul ar trebui să se re-autentifice. Deci 401 standuri pentru invalid authentication în timp ce 403 reprezintă o lipsă de permisiune.
Aici sunt unele cazuri în care logica în cazul în care o eroare s-ar fi întors de autentificare sau autorizare, cu fraze importante îngroșat.
401: clientul trebuie să specificați acreditările.
400: Ca's nici 401 nici 403, ca erori de sintaxă ar trebui să se întoarcă mereu 400.
401: clientul trebuie să specifice acreditări valide.
401: din Nou, clientul trebuie să specifice acreditări valide.
401: Aceasta este practic aceeași ca având invalid de acreditare, în general, astfel încât clientul trebuie să specifice acreditări valide.
403: Specificarea acreditări valide nu ar acorda acces la resurse, ca de acreditare curente sunt deja valabile, dar numai nu aveți permisiunea.
403: Aceasta este, indiferent de acreditare, astfel încât specificarea acreditări valide nu poate ajuta.
403Dacă clientul este blocat, precizând noi acreditări nu va face nimic.
Date fiind ultimele RFC's în această privință (7231 și 7235) în caz de utilizare pare destul de clar (sublinierea noastră):
401 Neautorizate
401 (Neautorizate) cod de stare indică faptul că cererea nu a fost aplicate pentru că nu dispune valabil de autentificare acreditările pentru ținta de resurse. Serverul generează o 401 răspuns TREBUIE să trimită un WWW-Authenticate câmp de antet (Secțiunea 4.1) conțin cel puțin o provocare aplicabile resurse țintă.
Dacă cererea a inclus acreditările de autentificare, apoi 401 răspuns indică faptul că autorizația a fost refuzat pentru cei acreditările. Agentul utilizator POATE repeta cererea cu un nou sau înlocuit de Autorizare câmp de antet (Secțiunea 4.2). Dacă 401 răspunsul conține aceeași provocare ca înainte de răspuns, și user agent a încercat deja de autentificare, cel puțin o dată, apoi agentul utilizator ar TREBUI să prezinte închise reprezentare a utilizator, deoarece acesta conține, de obicei, relevante informații de diagnosticare.
403 Forbidden
403 (Forbidden) cod de stare indică faptul că serverul a înțeles cererea dar refuză să autorizeze ea. Un server care dorește să facă publice motivele pentru care cererea a fost interzis poate descrie asta un motiv în răspunsul sarcină utilă (dacă există).
Dacă acreditările de autentificare au fost furnizate în cerere, server le consideră insuficiente pentru a acorda accesul. Clientul NU ar TREBUI să se repete automat la cerere cu același acreditările. Clientul POATE repeta cererea cu noi sau diferite acreditările. Cu toate acestea, o cerere ar putea fi interzis pentru motive nu au legătură cu acreditările.
Un server de origine care dorește să "ascunde" existența actuală a unei interzis resurse țintă POATE răspunde cu un cod de stare 404 (Not Found).
În cazul 401 vs 403, acest lucru a fost preluat de mai multe ori. Aceasta este, în esență, o 'cerere HTTP mediu' dezbatere, nu o 'aplicarea' dezbatere.
Nu pare a fi o întrebare pe rola-ta-proprii-problema de conectare (cererea).
În acest caz, pur și simplu nu sunt logat nu este suficientă pentru a trimite un 401 sau un 403, dacă nu utilizați HTTP Auth vs o pagina de login (nu legat de stabilirea HTTP Auth). Se pare ca ai putea fi în căutarea pentru un "201 Creat", cu un roll-ta-proprii-ecranul de login prezent (în loc de resursele solicitate) pentru aplicarea la nivel de acces la un fișier. Aceasta spune:
"te-am auzit, l's aici, dar încercați acest loc (nu ai voie să-l văd)"