with template password mixin logoutview loginview loginrequired custom django django-authentication

template - Suprimir el comportamiento de "? Next=blah" en el decorador de login_required de django



logoutview django (3)

Me encanta el decorador @login_required de django, pero hay una cosa que no sé cómo hacer que funcione.

Si un usuario no autenticado intenta visitar una página @login_required (por ejemplo, "/ private-stuff /"), quiero devolverlos a la página de inicio (por ejemplo, "/ home /"). Pero no quiero agregar un argumento "? Next =" a la url. En otras palabras, solo quiero redirigir a "/ home /", no "/ home /? Next = / private-stuff /".

¿Cómo puedo hacer eso? ¿Hay alguna forma mejor que escribir mi propio decorador?


¿No es simplemente como

@decorators.login_required(redirect_field_name=None)


Bueno, hay dos maneras en las que puedo pensar. Primero, sería la forma "correcta", en el sentido de que no está rompiendo ninguna funcionalidad, solo agregando una nueva funcionalidad: cree su propio decorador login_required . Sin embargo, el problema es que Django realmente ha ocultado la redirección después de la funcionalidad de inicio de sesión, y requiere muchas partes. El decorador login_required es en realidad solo un envoltorio alrededor del decorador user_passes_test , que a su vez llama a la vista redirect_to_login , y es esa vista la que agrega el next parámetro a la cadena de consulta. En su decorador personalizado, puede incluir todas o algunas de estas funciones directamente en el decorador, pero deberá hacer referencia a las tres para obtener el código necesario.

La otra opción, y mucho más simple, es crear algún middleware para eliminar la cadena de consulta si está configurada:

from django.conf import settings from django.http import HttpResponseRedirect class RemoveNextMiddleware(object): def process_request(self, request): if request.path == settings.LOGIN_URL and request.GET.has_key(''next''): return HttpResponseRedirect(settings.LOGIN_URL)

Y luego, agregue la ruta de importación a ese middleware a MIDDLEWARE_CLASSES . Recuerde que en la fase de solicitud, el middleware se procesa primero a último o de arriba a abajo, en otras palabras. Esto debería ser relativamente temprano en la fase de solicitud, pero es posible que deba jugar un poco con él para ver qué puede y qué no puede venir antes.

El único problema real con este método es que "rompe" la siguiente funcionalidad de redireccionamiento, y no de una manera muy intuitiva, si un desarrollador posterior hereda su base de código junto con un mandato para permitir el redireccionamiento, podría ser un poco complicado.


login(request, user) if request.POST[''next'']: return redirect(request.POST[''next'']) else: msg = u"Welcome..." return render_to_response(''members/welcome.html'', {''msg'':msg}, context_instance=RequestContext(request))