template - sistema login django

Autenticación basada en tokens en Django

Question

Estoy tratando de descubrir la mejor manera de implementar la autenticación basada en token en mi aplicación django. Una aplicación externa que no es django está configurando una cookie, con un token, y tengo un servicio web que puede recuperar información del usuario basada en ese token. Si el usuario tiene el conjunto de cookies, no deberían necesitar autenticarse en mi sitio y deberían iniciar sesión automáticamente en función de la información transmitida por el servicio web. Como lo veo, hay algunas opciones diferentes para realizar el control real y no estoy seguro de cuál es la mejor:

1. Escriba un decorador personalizado como el que está en este snippet y login_required en lugar de login_required .
2. Llame a un método de autenticación personalizado dentro de base_site a través de una llamada ajax. En cada página, se realizaría una verificación y si la cookie existe y es válida, entonces el usuario iniciaría sesión automáticamente.
3. Agregue un javascript a la página LOGIN_REDIRECT_URL que verificará / validará la cookie en una llamada ajax, y redirigirá automáticamente de regreso al remitente si la cookie se autentica.

¿Hay una opción que me falta? Idealmente, habría una forma de construir esto en login_required , sin tener que escribir un decorador personalizado.

Answer 1

Antes de buscar el código, asegúrese de leer la documentación. http://docs.djangoproject.com/en/1.2/topics/auth/#other-authentication-sources Lea también la fuente de Django suministrada.

Quieres crear tres cosas.

1. Middleware para capturar el token. Aquí es donde sucede la mayor parte del trabajo. Comprueba el token, lo autentica (confirmándolo con el administrador de identidad) y luego inicia sesión en el usuario.

2. Autenticación de back-end para encontrar usuarios. Este es un stub. Todo lo que hace es crear usuarios según sea necesario. Su administrador de identidad tiene los detalles. Simplemente está almacenando en caché la versión actual del usuario en la base de datos local de Django.

Aquí está el middleware (editado).

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)

El identity_manager.get_attributes es una clase separada que escribimos para validar el token y obtener detalles sobre el usuario de la fuente de mensajería instantánea. Esto, por supuesto, tiene que ser burlado para fines de prueba.

Aquí hay un backend (editado)

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

Esto no cambia materialmente los decoradores para autenticación o autorización.

Para garantizar esto, en realidad actualizamos la información de usuario y grupo de nuestro administrador de identidad.

Tenga en cuenta que el middleware se ejecuta para cada solicitud individual. A veces, está bien pasar el token al método de authenticate respaldado. Si el token existe en la base de datos del usuario local, la solicitud puede continuar sin comunicarse con el administrador de identidad.

Sin embargo, tenemos reglas y tiempos de espera complejos en el administrador de identidades, por lo que debemos examinar cada token para asegurarnos de que sea válido. Una vez que el middleware está seguro de que el token es válido, podemos permitir que el back-end realice un procesamiento adicional.

Este no es nuestro código en vivo (es un poco demasiado complejo como para dar un buen ejemplo).