Помилка HTTP 401 проти помилки HTTP 403 - Пояснення відповідей на код стану

Ми вже докладно розглядали код помилки 403 (заборонено) HTTP, але він також має майже однаковий брат.

То в чому саме різниця між кодами стану 401 (Несанкціонований) та 403 (Заборонено)? Напевно вони мають на увазі одне і те ж? Давайте розглянемо уважніше!

Стандарти RFC

Найновішим стандартом RFC, що визначає 401 (Несанкціонований), є RFC 7235

Код стану 401 (неавторизований) вказує на те, що запит не застосовано, оскільки в ньому відсутні дійсні облікові дані автентифікації для цільового ресурсу ... Агент користувача МОЖЕ повторити запит із новим або заміненим полем заголовка авторизації.

Тоді як 403 (Заборонено) визначено нещодавно у RFC 7231

Код стану 403 (Заборонено) вказує на те, що сервер зрозумів запит, але відмовляється його авторизувати ... Якщо в запиті були вказані облікові дані автентифікації, сервер вважає їх недостатніми для надання доступу.

Поширені причини

Як згадувалось у попередній статті, помилка 403 може виникнути, коли користувач увійшов у систему, але у нього недостатньо прав для доступу до запитуваного ресурсу. Наприклад, загальний користувач може намагатися завантажити маршрут "адміністратора".

З іншого боку, найочевидніший момент, коли ви зіткнетеся з помилкою 401, - це те, коли ви взагалі не ввійшли в систему або вказали неправильний пароль.

Це дві найпоширеніші причини цієї пари помилок.

Менш поширені причини

Є деякі випадки, коли це не так просто, як це.

Помилки 403 можуть виникати через обмеження, які не повністю залежать від облікових даних користувача, що ввійшов до системи.

Наприклад, сервер, можливо, заблокував певні ресурси, щоб дозволити доступ лише із заздалегідь визначеного діапазону IP-адрес, або може використовувати геоблокування. Останні можна потенційно обійти за допомогою VPN.

Помилки 401 можуть статися, навіть якщо користувач вводить правильні облікові дані. Це трапляється рідко, і це може бути те, з чим ви справді стикаєтесь лише під час розробки власних автентифікованих фонових програм. Але якщо заголовок авторизації неправильний, він поверне 401.

Наприклад, у вас може бути JWT (веб-маркер JSON), який ви хочете включити в заголовок запиту, який очікує формату Authorization: Bearer eyJhbGci......yJV_adQssw5c. Якби ви забули слово "Носій" перед JWT, ви б зіткнулися з помилкою 401.

Я сам зіткнувся з цією проблемою під час тестування API, що розробляється Postman, і забувши правильний синтаксис заголовків auth!

Це воно

Сподіваюся, це усуває будь-яку плутанину, пов’язану з цими дуже подібними помилками.

Якщо ви знайшли це корисним або хочете кинути виклик або продовжити щось, що було піднято тут, не соромтеся зв’язуватися зі мною на Twitter @JacksonBates.