Django api 401 HTTP

@IRIP · Регистрация: 18.04.2015

Студворк — интернет-сервис помощи студентам

делаю все по инструкции http://apirobot.me/posts/djang... api-part-1

в конце статьи - нужно сделать get запрос http GET "http://localhost:8000/api/v1/notes/"

и получаю

HTML5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ http GET "http://localhost:8000/api/0/posts/"
 
[B]HTTP/1.1 401 Unauthorized[/B]
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 82
Content-Type: application/json
Date: Thu, 10 May 2018 08:17:40 GMT
Server: WSGIServer/0.2 CPython/3.6.5
Vary: Accept, Cookie
WWW-Authenticate: Basic realm="api"
X-Frame-Options: SAMEORIGIN
 
{
    "detail": "Учетные данные не были предоставлены."
}

что я делаю не так?

Добавлено через 3 часа 21 минуту
Как Вы наверняка знаете, в обычном, привычном нам вебе, к коему относятся и ручные запросы из браузера, для идентификации клиента придумали такую штуку, как сессия: при первом посещении сервер выдаёт клиенту идентификатор, который клиент затем будет добавлять к каждому запросу (в случае джанги это сессионная кука sessionid). И на своей стороне создаёт хранилище для информации о конкретно этом клиенте.

При каждом запросе сервер проверяет, передан ли от клиента тем или иным способом —а чаще всего это кука — ID сессии. Если передан, то сервер "опознаёт" пользователя. Если нет, то нет :-) Кука добавляется к запросу самим браузером, без явного участия пользователя, поэтому для нас, людишек, всё выглядит как будто само собой.

Теперь про REST. Обычно API пишется чаще всего не для браузеров, а для сторонних серверов, в которых и кук-то зачастую не бывает. И такого понятия, как сессия, просто нет! Каждый запрос приходит как будто он от нового пользователя. Здесь идентифицироваться приходится ручками.

Самый простой, но вместе с тем и самый глупый вариант — вместе с каждым запросом посылать логин и пароль. Другой не самый умный, но почему-то часто встречающийся вариант — захардкоженный секретный параметр: типа если в запросе есть переменная abcdef=123, то запрос считается достоверным.

Логическое продолжение этого способа — та самая аутентификация через токены, которую Вы то включаете, то выключаете. Пользователь шлёт логин и пароль на отдельный URL, в ответ получает токен, который затем должен добавлять вручную к каждому запросу. Что-то напоминает, верно? :-)

В случае с либеральным DRF можно наплевать на рекомендуемый принцип stateless — не сохранять информацию о состоянии клиента — и добавить поддержку сессий: т.е. сделать так, что если в запросе передаётся кука (а любой браузерный запрос, даже через XHR их вроде бы добавляет), то сервер должен определять пользователя.

Включается это довольно просто: нужно использовать Как Вы наверняка знаете, в обычном, привычном нам вебе, к коему относятся и ручные запросы из браузера, для идентификации клиента придумали такую штуку, как сессия: при первом посещении сервер выдаёт клиенту идентификатор, который клиент затем будет добавлять к каждому запросу (в случае джанги это сессионная кука sessionid). И на своей стороне создаёт хранилище для информации о конкретно этом клиенте.

При каждом запросе сервер проверяет, передан ли от клиента тем или иным способом —а чаще всего это кука — ID сессии. Если передан, то сервер "опознаёт" пользователя. Если нет, то нет :-) Кука добавляется к запросу самим браузером, без явного участия пользователя, поэтому для нас, людишек, всё выглядит как будто само собой.

Теперь про REST. Обычно API пишется чаще всего не для браузеров, а для сторонних серверов, в которых и кук-то зачастую не бывает. И такого понятия, как сессия, просто нет! Каждый запрос приходит как будто он от нового пользователя. Здесь идентифицироваться приходится ручками.

Самый простой, но вместе с тем и самый глупый вариант — вместе с каждым запросом посылать логин и пароль. Другой не самый умный, но почему-то часто встречающийся вариант — захардкоженный секретный параметр: типа если в запросе есть переменная abcdef=123, то запрос считается достоверным.

Логическое продолжение этого способа — та самая аутентификация через токены, которую Вы то включаете, то выключаете. Пользователь шлёт логин и пароль на отдельный URL, в ответ получает токен, который затем должен добавлять вручную к каждому запросу. Что-то напоминает, верно? :-)

В случае с либеральным DRF можно наплевать на рекомендуемый принцип stateless — не сохранять информацию о состоянии клиента — и добавить поддержку сессий: т.е. сделать так, что если в запросе передаётся кука (а любой браузерный запрос, даже через XHR их вроде бы добавляет), то сервер должен определять пользователя.

Включается это довольно просто: нужно использовать rest_framework.authentication.SessionAut hentication в качестве аутентификатора.

Лучше всего сделать глобальную настройку (в документации всё есть), либо указать этот класс для отдельного endpoint.

но как?!

@ТабуретY · 10.05.2018, 17:21

Сообщение от IRIP

делаю все по инструкции

Сообщение от IRIP

http GET "http://localhost:8000/api/0/posts/"

а должно быть http://localhost:8000/api/v1/notes/, все таки что-то не так делаешь
Попробовал покопипастить с примера и все заработало, только в django 2 файл backend/simplenote/urls.py должен выглядеть так

Python
1
2
3
4
5
6
7
8
from django.conf.urls import include, url
from django.contrib import admin
from django.urls import path
 
urlpatterns = [
    path('api/v1/', include('notes.urls')),
        path('admin/', admin.site.urls),
]

а вопрос по идентификации пользователей в таком виде ответа не имеет, попробуй что-нибудь реализовать отсюда http://www.django-rest-framewo... ntication/, а там и будет видно, чего не хватает

@IRIP · 11.05.2018, 08:01 **[ТС]**

Сообщение от ТабуретY

а должно быть

я, конечно, поменял у себя урлы, подгоняя под свой проект
но видимо где-то накосячил

Добавлено через 12 часов 43 минуты
В некоторых примерах дается

JavaScript
1
2
3
4
5
6
7
8
9
10
new Vue({
 
  http: {
    root: 'http://localhost:8000',
    headers: {
      Authorization: 'Basic YXBpOnBhc3N3b3Jk'
    }
  }
 
})

Authorization: '<TOKEN_HERE>'

откуда этот токен появляется? ГДе его брать?

Новые блоги и статьи Все статьи Все блоги /
Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20%	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .	Использование значений реквизитов справочника в документе, с определенными условиями и правами Maks 07.04.2026 1. Контроль срока действия договора Алгоритм из решения ниже реализован на примере нетипового документа "ЗаявкаНаРаботу", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если. . .
Доступность команды формы по условию Maks 07.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: сделать доступной кнопку (команда формы "ЗавершитьСписание") при. . .	Уведомление о неверно выбранном значении справочника Maks 06.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "НарядПутевка", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если в документе выбран неверный склад. . .	Установка Qt Creator для C и C++: ставим среду, CMake и MinGW без фреймворка Qt 8Observer8 05.04.2026 Среду разработки Qt Creator можно установить без фреймворка Qt. Есть отдельный репозиторий для этой среды: https:/ / github. com/ qt-creator/ qt-creator, где можно скачать установщик, на вкладке Releases:. . .	AkelPad-скрипты, структуры, и немного лирики.. testuser2 05.04.2026 Такая программа, как AkelPad существует уже давно, и также давно существуют скрипты под нее. Тем не менее, прога живет, периодически что-то не спеша дополняется, улучшается. Что меня в первую очередь. . .

Django api 401 HTTP

Решение