#29975: Password reset emails in combination with click tracking do not work 
with
Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
-------------------------------------+-------------------------------------
               Reporter:  Drarok     |          Owner:  nobody
                   Type:  Bug        |         Status:  new
              Component:             |        Version:  2.1
  contrib.auth                       |       Keywords:  safari, privacy,
               Severity:  Normal     |  auth, password reset
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 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
 [https://github.com/django/django/blob/master/django/contrib/auth/views.py#L281
 "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 [https://webkit.org/blog/8311/intelligent-tracking-
 prevention-2-0/ 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?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/29975>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.c74979ca9f839b28ebced9bc35fd1625%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to