Всем доброго времени суток.
Исходные данные
Есть сайт, работающий на стэке DRF + Next.js. На сайте используется встроенная админка Django и есть самописное API, часть которого (небезопасные запросы) закрыта. Закрытым API может воспользоваться только суперюзер.
Как известно, по дефолту админка Django использует аутентификацию на основе сессий, а не токенов. Но на клиенте Next.js как-то должен делать запросы от лица суперюзера.
Сразу сделаю ремарку: говоря "клиент Next.js" я прекрасно понимаю, что Next.js работает отдельной службой на сервере, но по смыслу мало что меняется между ним и обычным React. Просто рендеринг происходит на сервере, а не в браузере.
Варианты решения
- Сделать отдельную форму авторизации на основе токенов. В таком случае, если пользователь вошел, как админ, на клиенте Next.js будут храниться токены, и клиент сможет делать запросы к API с ними. Но у этого подхода есть огромный минус. Пользователю (админу) придется 2 раза авторизироваться... Т.е. через форму входа админки Django для работы с админкой и через нашу кастомную форму входа для получения токенов и работы с API. Странно.
- Второй вариант заключается в том, чтобы аутентифицировать пользователя в эндпоинтах API через сессию. Т.е. т.к. пользователь вошел через админку Django, у него в браузере будут куки с sessionid. Эти куки автоматически браузер прикрепляет к каждому запросу. Значит, мы можем этим воспользоваться, чтобы понять, кто делает запрос. Таким образом, если пользователь войдет через админку, он сможет и ей пользоваться, и API закрытым.
А теперь проблема, с которой я столкнулся
Я нарушил принцип stateless REST-архитектуры, наивно думая, что не будет последствий. Теперь клиент может делать авторизированные запросы к API через cookie с sessionid, но клиент не может получить никакой информации о пользователе, допустим, т.к. я не использую те же JWT. А мне нужно знать роль пользователи (админ или нет). В моей схеме выхода два - присылать с каждым ответом это поле либо пилить отдельный эндпоинт для получения информации о юзере, что как-то.. странно и костыльно на мой взгляд.
Тогда я начал думать, что возможно стоит все-таки вернуться к JWTAuth. Пришла в голову мысль написать бэкенд аутентификации для Django через jwt-токены: и к API можно было бы делать запросы через jwt, и к админке.
Но проблема в том, что тут придется на Next.js делать свою форму авторизации
ВЗАМЕН ФОРМЕ АДМИНКИ DJANGO. Хорошо, допустим, сделали. В ответ от сервера получаем токены и.. что дальше? Как делать запросы к админке Django с этими токенами, ведь запросы к админке Django идут в обход Next.js напрямую в приложение Django (через Nginx)? Т.е. клиент (Next.js) никак не может сформировать запрос и добавить токены.
Тогда я придумал другой выход: при авторизации через кастомную форму в Next.js записывать access и refresh токены в cookie, и вот тогда все заработало бы! Потому что браузер сам отправляет куки. Правда, придется бэкенд аутентификации научить вытаскивать токены из кук, но это не проблема. Проблема в том, что в силу своей неопытности еще, я не знаю, нормальный ли это подход, безопасно ли это. Какие последствия могут быть у такого подхода?
Прошу прощения за огромный текст, нужно было описать проблему подробно. И очень хочется получить мнения более опытных и старших людей в этом вопросе, т.к. я сам еще, объективно говоря, зеленый.