Ответ 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. Если токен существует в локальном БД пользователя, запрос может продолжаться без обращения к диспетчеру идентификации.
Однако у нас есть сложные правила и тайм-ауты в менеджере удостоверений, поэтому мы должны изучить каждый токен, чтобы быть уверенным в его действительности. После того как промежуточное ПО уверен, что токен действителен, мы можем разрешить бэкэнд выполнять любую дополнительную обработку.
Это не наш живой код (он слишком сложный, чтобы сделать хороший пример.)