Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Mat Gadd]

I wasn't sure whether or not to file this as a bug, since strictly it isn't a problem in the Django code, but at the very least having it here will help other people who are experiencing the issue understand what is happening.

Users have started reporting that our password reset links sent out via email aren't working, and are showing the ​Password reset unsuccessful response instead. The reason for this is the click-tracking our email provider uses in combination with the "Protection Against First Party Bounce Trackers" feature of Safari on macOS and iOS, as ​described on the WebKit blog.

What's happening is our email provider replaces our links with ones pointed at their servers with some query string to identify the user and destination, their server redirects to our password reset link, and Django's auth contrib attempts to set a cookie (this fails under ITP) then redirect, replacing the user's secret token in the URL with the internal token. Since the attempt to set a cookie fails, the user has no session and therefore no token, and the view won't present the user with the password form.

We're planning to disable click tracking for these emails, which should mitigate the issue.

An option to disable the redirect and internal token behaviour might be an idea for people that need click tracking or run into similar issues?

[Tim Graham]

The DevelopersMailingList reaches a wider audience than this ticket tracker. You can write there to ask if there's a consensus to make a change in Django.

[René Fleschenberg]

I filed an issue on the WebKit bug tracker: ​https://bugs.webkit.org/show_bug.cgi?id=193502

[René Fleschenberg]

Just for the record: I believe this affects all users who use Safari in combination with Gmail, which seems to be a somewhat popular combination.

[Tim Graham]

The ​django-developers discussion seems to suggest that we'll take some action to improve the situation.

[Mat Gadd]

Hi all,

Thanks to the excellent work by Flávio Juvenal over on ticket #30250, we now have a workaround for this issue. It turns out to be a ​bug in Safari where it incorrectly handles cookies set with SameSite=lax, so setting CSRF_COOKIE_SAMESITE and SESSION_COOKIE_SAMESITE to None in your project settings will avoid this issue until Apple get around to deploying a fix for Safari.

[Tim Graham]

In that case, it seems like a change in Django isn't required. Perhaps the lack of activity here indicates that ​Sarafi's fix has rolled out.