Подтвердить что ты не робот

Аутентификация на основе токена в Django

Я пытаюсь найти лучший способ реализовать проверку подлинности на токенах в моем приложении django. Внешнее приложение, отличное от django, устанавливает cookie с маркером, и у меня есть веб-сервис, который может извлекать информацию пользователя на основе этого токена. Если у пользователя есть набор файлов cookie, им не нужно проверять подлинность на моем сайте и он должен автоматически регистрироваться на основе информации, переданной веб-службой. Как я вижу, есть несколько различных вариантов выполнения фактической проверки, и я не уверен, что лучше:

  • Напишите собственный декоратор, подобный таковому в snippet и используйте его вместо login_required.
  • Вызов пользовательского метода проверки подлинности внутри base_site через вызов ajax. На каждой странице будет сделана проверка, и если файл cookie существует и действителен, пользователь будет автоматически зарегистрирован.
  • Добавить javascript на страницу LOGIN_REDIRECT_URL, которая будет проверять/проверять cookie при вызове ajax и автоматически перенаправлять обратно на реферер, если файл cookie аутентифицирован.

Есть ли вариант, который мне не хватает? В идеале, был бы способ построить это в login_required, не имея необходимости писать пользовательский декоратор.

4b9b3361

ОТВЕТЫ

Ответ 1

Перед поиском кода обязательно прочтите документацию. http://docs.djangoproject.com/en/1.2/topics/auth/#other-authentication-sources Также прочитайте поставляемый источник Django.

Вы хотите создать три вещи.

  • Middleware для захвата маркера. Именно здесь происходит большая часть работы. Он проверяет токен, аутентифицирует его (подтверждая его с помощью диспетчера идентификаторов), а затем регистрирует пользователя.

  • Проверка подлинности для поиска пользователей. Это заглушка. Все, что он делает, - это создавать пользователей по мере необходимости. У вашего менеджера по идентификации есть данные. Вы просто кэшируете текущую версию пользователя в локальной базе данных Django.

Здесь промежуточное ПО (отредактировано).

from django.contrib.auth import authenticate, login

class CookieMiddleware( object ):
    """Authentication Middleware for OpenAM using a cookie with a token.
    Backend will get user.
    """
    def process_request(self, request):
        if not hasattr(request, 'user'):
            raise ImproperlyConfigured() 
        if "thecookiename" not in request.COOKIES:
            return
        token= request.COOKIES["thecookiename"]
        # REST request to OpenAM server for user attributes.
        token, attribute, role = identity_manager.get_attributes( token )
        user = authenticate(remote_user=attribute['uid'][0])
        request.user = user
        login(request, user)

identity_manager.get_attributes - это отдельный класс, который мы написали, чтобы проверить токен и получить информацию о пользователе из источника IM. Это, конечно же, нужно издеваться над целями тестирования.

Здесь бэкэнд (отредактированный)

class Backend( RemoteUserBackend ):
    def authenticate(**credentials):
        """We could authenticate the token by checking with OpenAM
        Server.  We don't do that here, instead we trust the middleware to do it.
        """
        try:
            user= User.objects.get(username=credentials['remote_user'])
        except User.DoesNotExist:
            user= User.objects.create(username=credentials['remote_user'] )
        # Here is a good place to map roles to Django Group instances or other features.
        return user

Это не приводит к существенному изменению декораторов для аутентификации или авторизации.

Чтобы убедиться в этом, мы фактически обновляем информацию пользователя и группы из нашего менеджер идентификации.

Обратите внимание, что промежуточное программное обеспечение работает для каждого отдельного запроса. Иногда, это хорошо, чтобы передать токен на поддерживаемый метод authenticate. Если токен существует в локальном БД пользователя, запрос может продолжаться без обращения к диспетчеру идентификации.

Однако у нас есть сложные правила и тайм-ауты в менеджере удостоверений, поэтому мы должны изучить каждый токен, чтобы быть уверенным в его действительности. После того как промежуточное ПО уверен, что токен действителен, мы можем разрешить бэкэнд выполнять любую дополнительную обработку.

Это не наш живой код (он слишком сложный, чтобы сделать хороший пример.)