Do not override "user" variable when User model is used with generic views

[Stefano Vettorazzi]

Hello Django team.

I noticed that the default behavior when using the User model in a generic view, is to override the user variable set by the context processor django.contrib.auth.context_processors.auth(). It is documented here ​https://docs.djangoproject.com/en/3.1/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.get_context_data.

I think that from a security standpoint, the user variable shouldn't be overridden, unless the developer intentionally wants to do that using context_object_name = 'user'.
For instance, if you have something like the following in a base template:

{% if user.is_authenticated and user.is_staff %}
private information supposed to be shown to staff users
{% endif %}

and in your urls.py you have:

path('user/<int:pk>/', views.DetailUserView.as_view())

and in your views.py you have the following supposed to be used to show just some details about the user:

class DetailUserView(generic.DetailView):
 model = User

when anyone with access to user/<pk>/, loads the URL for a staff user, is going to get the private information supposed to be shown to staff users.

Of course, the developer is going to notice at some point what's going on, but it wouldn't be nice if it is too late.

Anyway, it's just a suggestion, I understand if it is ignored.

[Mariusz Felisiak]

Thanks for this ticket. It was discussed recently via @django-security (see also #25397) and we decided that a note in docs in enough.

Florian's reply at @django-security:

"I am open to suggestions on how to improve the situation; but a blacklist of certain context variables would IMO go to far… In general I also think that the issue isn't that bad. The global user object is mostly used in navigation bars etc to show the username. Even if it is used for permission checks it usually is just to determine whether a link should be shown or not. All in all I think the fallout shouldn't be that bad ... I think a documentation update would be fine."

[Stefano Vettorazzi]

Thank you for your time and the explanation.