Consider deprecating the current_app argument of auth views

[Aymeric Augustin]

All views defined in django.contrib.auth.views have the following structure:

def view(request, ..., current_app=None, ...):

    ...

    if current_app is not None:
        request.current_app = current_app

    return TemplateResponse(request, template_name, context)

As of Django 1.8 current_app is set on the request object. (This is debated but no other concrete proposal has been made at this time.)

For consistency the auth views should require the caller to set it on the request instead of passing it in a separate argument.

That would also avoid the risk of conflicts between a current_app set on the request and another current_app passed in argument. Currently the latter overrides the former.

[Tim Graham]

I guess the use case of making it a view parameter is that maybe you want to be able to simply use these views in a URLconf and specify the current_app that way? Further investigation is likely required.

[lukawoj]

Submitted pull request ​https://github.com/django/django/pull/4813

[Tim Graham]

It looks like the use case for adding current_app was for the admin: cc64fb5c4b4315a4ad66e21458e27ece57266847.

If we automatically set the current_app as suggested in #24127, that would allow us to proceed with this deprecation without having to add request.current_app = request.resolver_match.namespace in all the admin callers in contrib/admin/sites.py.

[Tim Graham <timograham@…>]

In 927b30a:

Fixed #24126 -- Deprecated current_app parameter to auth views.

[Tim Graham <timograham@…>]

In 9f9a3d64:

Refs #24126 -- Removed auth views' current_app parameter per deprecation timeline.