django.contrib.auth doesn't support template context processors?

[Mark Rogaski]

Hello,

I'm coming back to Django after working with 1.4/1.5.  Within a custom template for auth.views.password_reset, I'd like to access the request data using django.core.context_processors.request.  But it doesn't look like any template context processors are applied.

It's not a big problem for me, but it seems that the contrib packages should support this ... it's really a lovely feature.  Has anyone else run into this or know if this is something that is slated to be added?

Thanks,
Mark


[Edgar Gabaldi]

did you register the context processor in settings?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Rogaski]

Yes, I've appended it to the defaults.

TEMPLATE_CONTEXT_PROCESSORS += (

'django.core.context_processors.request',

)

[Mark Rogaski]

And looking at the request using django-debug-toolbar, I confirmed that none of the context processors were applied to the templates.

[James Schneider]

The FBV's included in contrib.auth.views don't use RequestContext(), they jump straight to TemplateResponse():

https://github.com/django/django/blob/master/django/contrib/auth/views.py#L192

IIRC, rendering a context via a RequestContext() is what triggers the TEMPLATE_CONTEXT_PROCESSORS to run. 

I could be wrong though, the docs are not really explicit as to what triggers a call out to TEMPLATE_CONTEXT_PROCESSORS, and I haven't tested it.

Everything I do is in CBV's, so I always assume that RequestContext() is used.

If it makes you feel better, I did try the same experiment using auth.views.password_reset, and my TEMPLATE_CONTEXT_PROCESSORS didn't run either, and work beautifully in my CBV's.

It's probably possible to wrap auth.views.auth.views.password_reset and shoehorn in a RequestContext() or render call when it returns, but I haven't needed/researched how to do so. That might also trigger rendering of the template twice, which may be acceptable for performance for a low usage page like a password reset form.

Better yet, you can wrap the view with your own FB view that simply calls auth.views.auth.views.password_reset, passing in an extra_context={<stuff from your context processors>} as one of the view arguments. Probably cleaner and keeps all the Django batteries intact. You might be able to do it inside of your urls.py as well, although that might get a bit uglier.

https://docs.djangoproject.com/en/1.7/topics/auth/default/#django.contrib.auth.views.password_reset

I have no insight on future plans with anything in Django beyond the public release notes.

-James

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/bf857384-6699-49c7-a14f-3d6c6247eaa2%40googlegroups.com.

[Mark Rogaski]

Thanks, James.  I think the call to TemplateResponse is fine, but the context that's passed as a dict needs to be passed as a ContextRequest instead.

Heck, this looks like a simple exercise to practice navigating the patch submission process. ;)

[Tom Evans]

On Wed, Jan 21, 2015 at 2:31 PM, Mark Rogaski <mrog...@pobox.com> wrote:
> Thanks, James. I think the call to TemplateResponse is fine, but the
> context that's passed as a dict needs to be passed as a ContextRequest
> instead.

https://docs.djangoproject.com/en/1.7/ref/template-response/#django.template.response.TemplateResponse

"TemplateResponse is a subclass of SimpleTemplateResponse that uses a
RequestContext instead of a Context."

So something else is going awry. Fire up a shell and confirm the value
of settings.TEMPLATE_CONTEXT_PROCESSORS is what you expect it to be.

Cheers

Tom

[James Schneider]

Hmm, I stand corrected:

https://github.com/django/django/blob/1.7.3/django/template/response.py#L156

It does render the context via RequestContext().

However, I can also point out why I thought I was right (in addition to my apparently flawed/rushed test):

https://github.com/django/django/blob/master/django/template/response.py#L188

In that function definition, you'll see that RequestContext() is never called/rendered before being passed back to the parent class methods, nor do they override the resolve_context() method. Doh!

It appears that in the current master branch and 1.8a1, that Context() is on its way out (or is getting a major refactoring), and everything is moving to RequestContext(). The RN are a bit sketchy on this topic still. 

https://docs.djangoproject.com/en/dev/releases/1.8/#dictionary-and-context-instance-arguments-of-rendering-functions

That aside though, I re-ran my quick test a bit under 1.7.3 a bit more formally using a blank project with as basic of a config as I could with the debug toolbar, a single app, and a single template. My urls.py referenced django.contrib.auth.views.password_reset. The only change to the default settings was adding django.core.context_processors.request to TEMPLATE_CONTEXT_PROCESSORS. After throwing a {{ request }} in my template, a ton of WSGI garbage in the request made me red in the face. Debug toolbar also confirmed the context processors ran. As would be expected.

Not sure what happened with my other test, I probably ran through it with too much confidence after viewing the wrong branch of source code.

Apologies.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1%2BcUM13fdrEwXykLuWdsTb7uevz0kMQahY5TCioCv38EA%40mail.gmail.com.