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>'

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

Новые блоги и статьи Все статьи Все блоги /
Фото всей Земли с борта корабля Orion миссии Artemis II kumehtar 04.04.2026 Это первое подобное фото сделанное человеком за 50 лет. Снимок называют новым вариантом легендарной фотографии «The Blue Marble» 1972 года, сделанной с борта корабля «Аполлон-17». Новое фото. . .	Вывод диалогового окна перед закрытием, если документ не проведён Maks 04.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать программный контроль на предмет проведения документа. . .	Программный контроль заполнения реквизита табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать контроль заполнения реквизита "ПричинаСписания". . .	wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/
Программная установка даты и запрет ее изменения Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: при создании документов установить период списания автоматически. . .	Вывод данных в справочнике через динамический список Maks 01.04.2026 Реализация из решения ниже выполнена на примере нетипового справочника "Спецтехника" разработанного в конфигурации КА2. Задача: вывести данные из ТЧ нетипового документа. . .	Программное заполнения текстового поля в реквизите формы документа Maks 01.04.2026 Алгоритм из решения ниже реализован на нетиповом документе "ВыдачаОборудованияНаСпецтехнику" разработанного в конфигурации КА2, в дополнении к предыдущему решению. На форме документа создается. . .	К слову об оптимизации kumehtar 01.04.2026 Вспоминаю начало 2000-х, университет, когда я писал на Delphi. Тогда среди программистов на форумах активно обсуждали аккуратную работу с памятью: нужно было следить за переменными, вовремя. . .

Django api 401 HTTP

Решение