Dogfood class-based views in contrib.auth

[Stephen Burrows]

Right now, the views provided by contrib.auth are not very extensible, since they are still functional. It would be great to add class-based versions which could eventually replace the functional versions. This is related to #17208; when this change is made, the admin login view should be tweaked to extend the new view.

[Donald Stufft]

I'm taking a crack at this. I've started working on it in my branch on github: ​https://github.com/dstufft/django/tree/feature/contrib-auth-cbv

So far i've gotten the LoginView switched to a CBV with a shim to translate login -> LoginView and switching the auth specific kwarg names to match the more generic kwarg names in FormView.

[Baptiste Mispelon]

I've made some pogress on this: ​https://gist.github.com/1851113

It still needs tests and documentation but I'm hoping to work on it during the sprints at djangocon europe next month.

[Andrews Medina]

bmispelon I can help you with that. You could add me to your fork on github?

[Baptiste Mispelon]

Replying to andrews:

bmispelon I can help you with that. You could add me to your fork on github?

I made a proper fork of django's new github repo: ​https://github.com/bmispelon/django and committed my changes.

[Baptiste Mispelon]

After two minor modifications, I've got all the tests passing on my fork.

There are still a few things I'd like to improve, mostly around the redirection logic in LoginView and LogoutView (it's still messy).

I've had a hard time wrapping my head around the flow of the function-based logout view. I'd appreciate it if someone could make sure I did actually replicate it.

I also have a few questions:

• LogoutView: For now, it inherits from TemplateView. Does it make more sense to inherit from RedirectView (RedirectView has the nice advantage of dispatching POST, OPTIONS, DELETE, and PUT to GET)? Or maybe simply View?

• PasswordResetConfirmView: as mentionned in the comment on the code, there is a potential backwards-compatibility issue. It should not be too hard to correct it but is it really a problem?

• Backwards-compatible stubs: the approach I took to ensure backwards-compatibility was to create function based wrappers around the class-based views. Is this a good approach?

• How do I approach writing tests for these new class-based views? I'm having a hard time determining what should be tested and how.

[Baptiste Mispelon]

I've made some more improvements and reached a point where I'm pretty satisfied with the code.

I'm going to attempt writing some documentation now, using the work done by pydanny in the pull request #144 (it hasn't been accepted yet as I'm writing this).

[anonymous]

Also check out #16197 which has been closed as a duplicate of this ticket.

[Marc Tamlyn]

I've tried bringing the patch up to the current master. Most of the tests pass and it seems to be ok, but there's something weird going on with the way that the wrapper shim works.

On discussion with andrewgodwin we've come up with the following changes:

1) Remove the wrapper shim, and convert all of the keyword arguments to kwargs. We can handle extra_context by updating the context on the TemplateResponse object returned from the CBV.

2) Tests: the new tests should be entirely equivalent to the old tests, but also separate. So a new set of urls linked to the cbv views, and retest all the expected behaviour. We should then be able to deprecate things easily when the time comes.

3) Docs/Release notes. The functional views documentation can be removed, and we can convert each part of the docs to now document the new, class based version.

[Marc Tamlyn]

Ok, I've got all of the tests working again and updated the wrapping of the new views with the old ones.

The code is visible here: ​https://github.com/mjtamlyn/django/compare/auth-cbv

The last thing to add to the list above is integrating these changes with the rest of django. The auth views are used by the admin, flatpages and other parts of auth and these should be updated to use the new cbv approach.

[Preston Holmes]

an interesting related bit to note here - is making the password reset process more flexible for custom users via CBV views:

​http://pypi.python.org/pypi/django-password-reset

via

​https://groups.google.com/forum/?fromgroups=#!topic/django-developers/NNnDVzoNQbU

[Baptiste Mispelon]

I just pulled master back into my branch:
​https://github.com/bmispelon/django/compare/auth-cbv

I thought the new swappable user model would break a lot of things but it turned out much easier than expected.

I've been looking into moving contrib.admin to use the new CBV but what I have so far is pretty ugly because the admin uses a lot of the old extra_context parameter, which requires CBV to create a get_context_data method.

As for flatpages, it only uses redirect_to_login which we didn't touch.

[Claude Paroz]

It looks nice. It would be nice to rebase/merge the commits, write some documentation and generate a pull request so we can comment on it.

[Rocky Meza]

I opened a pull request for this ticket ​https://github.com/django/django/pull/1239

This pull request is different from ​https://github.com/bmispelon/django/compare/auth-cbv in a couple ways:

1. There is no wrapper shim. The views extract the old parameters from kwargs. This has the benefit of subclasses still supporting the old view invocation.
2. It uses the DecoratorMixin pattern described in ​https://groups.google.com/d/msg/django-developers/jrfbenCJYYU/6aiH2sebnlAJ. This is controversial, yes, but it does mean a subclass will never lose its decorators should someone override dispatch.
3. It is rebased on master.

I was going to write some documentation for the class-based views, but I was wondering if we should maintain (and keep documented) the function view kwarg parameters or if they should be truly deprecated. All access to those function view kwarg parameters is regulated through one piece of code, so it would be possible to deprecate them easily. I'm in favor of deprecating the function view kwargs, 1) because they are terribly inconsistent (post_reset_redirect vs. post_change_redirect) and 2) to embrace the established class-based views APIs.

[Marc Tamlyn]

I'm not particularly fond of the approach you've taken here. I think we should not be trying to support some of the more obscure customisation points which existed historically. I agreed with some of the other core devs that the best way to proceed is to leave the old code as is, but with deprecation warnings, and create new views which are well designed to the new way of doing things, and provide a more consistent feeling API to the main GCBVs.

Other points:
If we're going to include the DecoratorMixinthen we should include it in a more logical place in the code base
Patch is completely missing tests - the tests for auth views are not complete as it is, so they need expanding to cover all the branches as well. Also they need to check all the deprecated views still work.
There are lots of minor style points - for example the use of resolve_url rather than reverse

[Baptiste Mispelon]

Hi,

I worked with Marc on this issue during the sprints at Djangocon Europe last month (and last year too).
Admitedly, I haven't made much progress on this since, but I haven't given up and I still work on it from time to time.

As it's often the case, writing the code is the easier part. I think the code we have is pretty good now and I don't see much advantage in tweaking it further (except maybe the idea of using the DecoratorMixin, see later).

As Marc mentionned, we've more or less settled on the idea of creating plain CBV, without any backwards-compatibility layer.
We would then keep the old function-based views around, with a deprecation warning as per the deprecation policy.
This allows us to start on a relative clean slate and get rid of the cruft that's been added over the years.

With the code settled, what's preventing this ticket from moving further has more to do with things like tests, documentation, and other parts of django that need to be cleaned up.

For example, there are a few places in django that assume the presence of function-based views inside contrib/auth/views.py so those need to be fixed (I'm currently working on this).
There's also the issue of the admin which makes heavy use of the auth views and their configuration options. In particular, it uses extra_context which doesn't map well to class-based views.

One thing to note is that with this rewrite, django.contrib.auth would become the first app in django that ships with non-generic class-based views.
This means that we need to come up with a way of both documenting and testing these views.
This is not completely straighforward, especially considering that whatever we come up with would probably be regarded as some sort of canon on how to test/document non-generic class-based views.

Personally, I'd rather take some more time and do this properly (clean up the code, tests and doc) rather than cut corners and ship something still half-broken with backwards-compatibility cruft.

Finally, regarding the DecoratorMixin:
I like the idea but I wonder if shouldn't be in a separate ticket.
I think the feature makes sense on its own and with the more litmited scope that it has,
it would stand a better chance of getting commited separately.

Thanks.

[Baptiste Mispelon]

I just pushed all the things I had left from the sprints onto ​https://github.com/bmispelon/django/compare/master...auth-cbv (I also merged the latest changes from master).

Here's what needs to be done next:

• Move all the contrib.auth.test_views to a new test_legacy_views file.
• Come up with a way of testing the class-based views (2 things need to be tested separately: the fact that the view itself works as intended, and its extension points).
• Document the new class-based views.
• Fix contrib.admin's usage of the auth views. As I mentionned before, the usage of the old extra_context parameter is what's causing problems here.

Out of these 4 points, only the first one is fairly easy (it's just some heavy copy/pasting and moving files around). The other 3 will be more tricky and I worry that the fixing of contrib.admin might unveil some more complicated issues.

[japrogramer]

this patch changes the auth view functions to CBV, maintaining backwards compatibility and tests passing ;)

[japrogramer]

(above) just attached a file with my improvements on the auth views, they are now CBV and have function gateways to maintain backwards compatability but users can easily import the CBV and override functions to extend or modify functionality :D

[Asif Saifuddin Auvi]

hi willing to work on this related tickets for gsoc this year. willing to assigning myself for now. will be analyzing the related tickets for a good proposal. looking forward to you guys kind suggestions :)

[Asif Saifuddin Auvi]

starting work on this. mainly cleanly implement the patch of japrogramer.

[Asif Saifuddin Auvi]

Targeting this for 1.10

[Claude Paroz]

auvipy, still working on this?

[Asif Saifuddin Auvi]

Replying to claudep:

auvipy, still working on this?

If you are willing to take it over for your personal sprint then OK but if not then I would be happy to start work on it. been busy with other projects.

[Claude Paroz]

If you think you'll be able to work on it before the feature freeze (May 16th), then fine. If not, then simply deassign yourself.

[Claude Paroz]

I added a patch for only login and logout in ​this PR. We might consider doing the password reset views later.

[Philip James]

I think the code looks good, and includes appropriate test changes. However, the patch needs to be rebased, and the references to 1.10 should be set to the next version.

[Claude Paroz]

Patch rebased.

[Philip James]

I think the code looks good, tests pass, and there is updated documentation. Marking "Ready For Checkin", happy to be corrected.

[Tim Graham]

I see a few things for improvement. Will review it soon.

[Claude Paroz <claude@…>]

In 7896349:

Refs #17209 -- Added LoginView and LogoutView class-based views

Thanks Tim Graham for the review.

[Claude Paroz]

Now to the password change/reset views...

[Claude Paroz]

​PR for the password-related views.

[Claude Paroz <claude@…>]

In 255fb992:

Fixed #17209 -- Added password reset/change class-based views

Thanks Tim Graham for the review.

[Tim Graham <timograham@…>]

In 51eaff6d:

Refs #17209 -- Fixed token verification for PasswordResetConfirmView POST requests.

[Markus Holtermann <info@…>]

In b9b35f9e:

Fixed #27840 -- Fixed KeyError in PasswordResetConfirmView.form_valid().

When a user is already logged in when submitting the password and
password confirmation to reset a password, a KeyError occurred while
removing the reset session token from the session.

Refs #17209

Thanks Quentin Marlats for the report and Florian Apolloner and Tim
Graham for the review.

[Markus Holtermann <info@…>]

In f5ff5be2:

[1.11.x] Fixed #27840 -- Fixed KeyError in PasswordResetConfirmView.form_valid().

When a user is already logged in when submitting the password and
password confirmation to reset a password, a KeyError occurred while
removing the reset session token from the session.

Refs #17209

Thanks Quentin Marlats for the report and Florian Apolloner and Tim
Graham for the review.

[Tim Graham <timograham@…>]

In 4f313e2:

Refs #17209 -- Removed login/logout and password reset/change function-based views.

Per deprecation timeline.