Unable to create an integration test for Django's reset password flow

Question

I'm trying to implement an integration test for the password reset flow, but I'm stuck at the "password_reset_confirm" view. I already tested the flow manually, and it works fine. Unfortunately, the Django unit test client seems unable to follow correctly the redirects required in this view.

urls config

from django.contrib.auth import views as auth_views


url(r"^accounts/password_change/$",
    auth_views.PasswordChangeView.as_view(),
    name="password_change"),
url(r"^accounts/password_change/done/$",
    auth_views.PasswordChangeDoneView.as_view(),
    name="password_change_done"),
url(r"^accounts/password_reset/$",
    auth_views.PasswordResetView.as_view(email_template_name="app/email/accounts/password_reset_email.html",
                                         success_url=reverse_lazy("app:password_reset_done"),
                                         subject_template_name="app/email/accounts/password_reset_subject.html"),
    name="password_reset"),
url(r"^accounts/password_reset/done/$",
    auth_views.PasswordResetDoneView.as_view(),
    name="password_reset_done"),
url(r"^accounts/reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$",
    auth_views.PasswordResetConfirmView.as_view(
        success_url=reverse_lazy("app:password_reset_complete"),
        form_class=CustomSetPasswordForm),
    name="password_reset_confirm"),
url(r"^accounts/reset/complete/$",
    auth_views.PasswordResetCompleteView.as_view(),
    name="password_reset_complete"),

Test code

import re
from django.urls import reverse, NoReverseMatch
from django.test import TestCase, Client
from django.core import mail
from django.test.utils import override_settings
from django.contrib.auth import authenticate

VALID_USER_NAME = "username"
USER_OLD_PSW = "oldpassword"
USER_NEW_PSW = "newpassword"
PASSWORD_RESET_URL = reverse("app:password_reset")

def PASSWORD_RESET_CONFIRM_URL(uidb64, token):
    try:
        return reverse("app:password_reset_confirm", args=(uidb64, token))
    except NoReverseMatch:
        return f"/accounts/reset/invaliduidb64/invalid-token/"


def utils_extract_reset_tokens(full_url):
    return re.findall(r"/([\w\-]+)",
                      re.search(r"^http\://.+$", full_url, flags=re.MULTILINE)[0])[3:5]


@override_settings(EMAIL_BACKEND="anymail.backends.test.EmailBackend")
class PasswordResetTestCase(TestCase):
    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.myclient = Client()

    def test_password_reset_ok(self):
        # ask for password reset
        response = self.myclient.post(PASSWORD_RESET_URL,
                                      {"email": VALID_USER_NAME},
                                      follow=True)

        # extract reset token from email
        self.assertEqual(len(mail.outbox), 1)
        msg = mail.outbox[0]
        uidb64, token = utils_extract_reset_tokens(msg.body)

        # change the password
        response = self.myclient.post(PASSWORD_RESET_CONFIRM_URL(uidb64, token),
                                      {"new_password1": USER_NEW_PSW,
                                       "new_password2": USER_NEW_PSW},
                                      follow=True)

        self.assertIsNone(authenticate(username=VALID_USER_NAME,password=USER_OLD_PSW))

Now, the assert fails: the user is authenticated with the old password. From the log I'm able to detect that the change password is not executed.

A few extra useful information:

• post returns a successful HTTP 200;
• the response.redirect_chain is [('/accounts/reset/token_removed/set-password/', 302)] and I think this is wrong, as it should have another loop (in the manual case I see another call to the dispatch method);
• I'm executing the test with the Django unit test tools.

Any idea on how to properly test this scenario? I need this to make sure emails and logging are properly executed (and never removed).

Many thanks!

EDIT: solution

As well explained by the accepted solution, here the working code for the test case:

def test_password_reset_ok(self):
        # ask for password reset
        response = self.myclient.post(PASSWORD_RESET_URL,
                                      {"email": VALID_USER_NAME},
                                      follow=True)

        # extract reset token from email
        self.assertEqual(len(mail.outbox), 1)
        msg = mail.outbox[0]
        uidb64, token = utils_extract_reset_tokens(msg.body)

        # change the password
        self.myclient.get(PASSWORD_RESET_CONFIRM_URL(uidb64, token), follow=True)
        response = self.myclient.post(PASSWORD_RESET_CONFIRM_URL(uidb64, "set-password"),
                                      {"new_password1": USER_NEW_PSW,
                                       "new_password2": USER_NEW_PSW},
                                      follow=True)

        self.assertIsNone(authenticate(username=VALID_USER_NAME,password=USER_OLD_PSW))

Answer 1

This is very interesting; so it looks like Django has implemented a security feature in the password reset page to prevent the token from being leaked in the HTTP Referrer header. Read more about Referrer Header Leaks here.

TL;DR

Django is basically taking the sensitive token from the URL and placing it in Session and performing a internal redirect (same domain) to prevent you from clicking away to a different site and leaking the token via the Referer header.

Here's how:

• When you hit /accounts/reset/uidb64/token/ (you should be doing a GET here, however you are doing a POST in your test case) the first time, Django pulls the token from the URL and sets it in session and redirects you to /accounts/reset/uidb64/set-password/.
• This now loads the /accounts/reset/uidb64/set-password/ page, where you can set the passwords and perform a POST
• When you POST from this page, the same View handles your POST request since the token URL param can handle both the token and the string set-password.
• This time though, the view sees that you have accessed it with set-password and not a token, so it expects to pull your actual token from session, and then change the password.

Here's the flow as a chart:

GET /reset/uidb64/token/ --> Set token in session --> 302 Redirect to /reset/uidb64/set-token/ --> POST Password --> Get token from Session --> Token Valid? --> Reset password

Here's the code!

INTERNAL_RESET_URL_TOKEN = 'set-password'
INTERNAL_RESET_SESSION_TOKEN = '_password_reset_token'

@method_decorator(sensitive_post_parameters())
@method_decorator(never_cache)
def dispatch(self, *args, **kwargs):
    assert 'uidb64' in kwargs and 'token' in kwargs

    self.validlink = False
    self.user = self.get_user(kwargs['uidb64'])

    if self.user is not None:
        token = kwargs['token']
        if token == INTERNAL_RESET_URL_TOKEN:
            session_token = self.request.session.get(INTERNAL_RESET_SESSION_TOKEN)
            if self.token_generator.check_token(self.user, session_token):
                # If the token is valid, display the password reset form.
                self.validlink = True
                return super().dispatch(*args, **kwargs)
        else:
            if self.token_generator.check_token(self.user, token):
                # Store the token in the session and redirect to the
                # password reset form at a URL without the token. That
                # avoids the possibility of leaking the token in the
                # HTTP Referer header.
                self.request.session[INTERNAL_RESET_SESSION_TOKEN] = token
                redirect_url = self.request.path.replace(token, INTERNAL_RESET_URL_TOKEN)
                return HttpResponseRedirect(redirect_url)

    # Display the "Password reset unsuccessful" page.
    return self.render_to_response(self.get_context_data())

Notice the comment in the code where this magic happens:

Store the token in the session and redirect to the password reset form at a URL without the token. That avoids the possibility of leaking the token in the HTTP Referer header.

I think this makes it clear how you can fix your unit test; do a GET on the PASSWORD_RESET_URL which will give you the redirect URL, you can then POST to this redirect_url and perform password resets!