Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеансаPython

Программы на Python
Ответить Пред. темаСлед. тема
Anonymous
 Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеанса

Сообщение Anonymous »

У меня есть установка с django, drf, django-allauth headless и nextjs, действующая как прокси для моего API django, полностью отделенная и сервер от разных серверов (обычная настройка django и отдельный сервер узлов для следующего) >
Настройки:

Код: Выделить всё

AUTH_USER_MODEL = "user.User"
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_EMAIL_VERIFICATION = "mandatory"

AUTHENTICATION_BACKENDS = [
"django.contrib.auth.backends.ModelBackend",
"allauth.account.auth_backends.AuthenticationBackend",
]
HEADLESS_ONLY = True
HEADLESS_FRONTEND_URLS = {}
# HEADLESS_TOKEN_STRATEGY = "apps.core.backends.allauth_token_strategy.DRFTokenAndAnonSessionTokenStrategy"

SOCIALACCOUNT_PROVIDERS = {
"google": {
"APP": {
"client_id": config.OAUTH.GOOGLE.CLIENT_ID,
"secret": config.OAUTH.GOOGLE.CLIENT_SECRET,
},
"SCOPE": [
"profile",
"email",
],
"AUTH_PARAMS": {
"access_type": "offline",
},
"OAUTH_PKCE_ENABLED": True,
}
}
URL-адреса: (изменение чисто для эстетики)

Код: Выделить всё

from allauth.headless.constants import Client
from allauth.headless.urls import build_urlpatterns
from django.urls import path, include
from django.urls.resolvers import RoutePattern

def build_allauth_url_patterns():
path_object = build_urlpatterns(Client.APP)[0]
path_object.pattern = RoutePattern("")
return [path_object]

urlpatterns = [
path("user/", include((build_allauth_url_patterns(), "headless"), namespace="app")),
path("accounts/", include("allauth.urls")),
]
Я хочу использовать безгласный режим, так как мне не нужны функции CSRF реализации браузера django allauth, однако я хочу использовать рукопожатие django-allauth, поэтому я отправляю отправить запрос к API через форму из nextjs.
для этого примера рассмотрим мой домен как локальный хост

Код: Выделить всё



Sign Up With Google





При этом форма успешно перенаправляется в Google для авторизации моего приложения, и я могу авторизоваться с использованием области из моих настроек и продолжить работу с моим приложением. Но на этом этапе django allauth возвращает ответ об ошибке — почему бы и нет — потому что у меня нет идентификатора/ключа сеанса.
В allauth.socialaccout.providers.oauth2.views. OAuth2CallbackView.dispatch вызов allauth.socialaccout.providers.oauth2.views.OAuth2CallbackView._get_state возвращает этот ответ об ошибке, поскольку в _get_sate состояние всегда равно None. Вот насколько мне удалось это отследить. Я пытался выяснить, как получить session_token, чтобы поместить его в заголовок X-Session-Token, но поскольку рукопожатие — это перенаправление из Google в мое приложение, я не могу изменить заголовок, поскольку я использую версию ПРИЛОЖЕНИЯ, а не версию БРАУЗЕРА, у меня нет файла cookie (в приложении, отличном от браузера, его все равно не будет, а конечная точка поставщика_токена все еще требует его в соответствии с docs)
Теперь мой вопрос: если я прав и мне нужен сеанс каким-то образом, как я могу идентифицировать сеанс с помощью django, так что state = statekit. unstash_state(request, state_id) действительно возвращает правильное состояние? Или, если я ошибаюсь и что-то не так, что это?
Обновление 1:
Я копнул глубже и подтвердил, что проблема связана с сеансами, поступает запрос from google не имеет информации о сеансе, хотя когда мы инициируем перенаправление провайдера, сеанс создается. Я не знаю почему, но кажется, что cookie-файла с идентификатором сеанса нет, хотя сеанс создан.
Обновление 2:

Код: Выделить всё

def dispatch(self, request, *args, **kwargs):
response = self.handle(request, *args, **kwargs)
breakpoint()
return self.handle(request, *args, **kwargs)
Если я поставлю точку останова в allauth.headless.internal.restkit.views.RestView.dispatch вот так, request.session.modified будет True< /code> и данные сеанса, добавленные через statekit.stash_state, находятся там. Однако когда я поставил точку останова на свое промежуточное программное обеспечение LAST для проверки запроса/ответа, почему-то данных сеанса больше не было. При этом он отсутствует в последних промежуточных программах, и, что наиболее важно, он отсутствует в промежуточном программном обеспечении сеанса, которое, поскольку оно отсутствует, не устанавливает файл cookie с идентификатором сеанса.
Я установил создал быстрое представление Django для проверки работоспособности

Код: Выделить всё

def hello(request):
request.session["foo"] = "bar"
from django.shortcuts import HttpResponse
return HttpResponse("Hello, World!")
Что на самом деле успешно добавляет идентификатор сеанса, поскольку это изменяет сеанс. Так что я думаю, что это не какая-то другая моя конфигурация, а исключительно конфигурации allauth.

Код: Выделить всё

MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"whitenoise.middleware.WhiteNoiseMiddleware",
"apps.common.utils.media_whitenoise_middleware.MediaWhiteNoiseMiddleware",
"django_hosts.middleware.HostsRequestMiddleware",
"pghistory.middleware.HistoryMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"corsheaders.middleware.CorsMiddleware",
"django.middleware.common.CommonMiddleware",
"django.middleware.csrf.CsrfViewMiddleware",
"allauth.account.middleware.AccountMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.messages.middleware.MessageMiddleware",
"django_hosts.middleware.HostsResponseMiddleware",
"django.middleware.clickjacking.XFrameOptionsMiddleware",
]
Вот мое промежуточное программное обеспечение, как я уже сказал, вышеуказанная функция проверки работоспособности работает, поэтому я не думаю, что проблема связана с каким-либо промежуточным программным обеспечением, и, как я уже сказал, к тому времени, когда дело доходит до XFrameOptionsMiddleware.get_response request.session уже каким-то образом теряет свои данные.
Обновление 3:
Похоже allauth.headless.internal.authkit.authentication_context виноват, он заменяет сессию на новую - не знаю почему, но вроде как к тому времени наконец-то запустится и восстановит предыдущую сессию, если просто пропустите эту функцию, я вижу, что session_id и остальная часть потока аутентификации работают как положено.

Подробнее здесь: https://stackoverflow.com/questions/792 ... n-problems
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение
  • Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеанса
    Anonymous » » в форуме Python
    0 Ответы
    14 Просмотры
    Последнее сообщение Anonymous
  • Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеанса
    Anonymous » » в форуме Python
    0 Ответы
    24 Просмотры
    Последнее сообщение Anonymous
  • Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеанса
    Anonymous » » в форуме Python
    0 Ответы
    16 Просмотры
    Последнее сообщение Anonymous
  • Безголовый режим Django Allauth 65.2.0 – проблемы с токеном сеанса
    Anonymous » » в форуме Python
    0 Ответы
    12 Просмотры
    Последнее сообщение Anonymous
  • Django Allauth — ModuleNotFoundError: нет модуля с именем «allauth.account.middleware», даже если django-allauth установ
    Anonymous » » в форуме Python
    0 Ответы
    49 Просмотры
    Последнее сообщение Anonymous

Вернуться в «Python»