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

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

Новые блоги и статьи Все статьи Все блоги /
Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .	Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .	Установка Android SDK, NDK, JDK, CMake и т.д. 8Observer8 25.01.2026 Содержание блога Перейдите по ссылке: https:/ / developer. android. com/ studio и в самом низу страницы кликните по архиву "commandlinetools-win-xxxxxx_latest. zip" Извлеките архив и вы увидите. . .
Вывод текста со шрифтом TTF на Android с помощью библиотеки SDL3_ttf 8Observer8 25.01.2026 Содержание блога Если у вас не установлены Android SDK, NDK, JDK, и т. д. то сделайте это по следующей инструкции: Установка Android SDK, NDK, JDK, CMake и т. д. Сборка примера Скачайте. . .	Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом

Django api 401 HTTP

Решение