Hi both, Adam, you're right that the email provider is rewriting the URLs to point to their server which then redirects to our site. The contrib.auth module then performs *another* redirect which appears to cause the privacy feature to kick in. If Django didn't perform a redirect then it would work as expected. As-is, the cookie that is attempted to be set before the redirect is thrown away by Safari and the user sees a message that their token is invalid.
Florian, it's not strictly an "internal redirect on a page", but the combination of being bounced from a different domain to our site, and their our site immediately performing its own redirect. If the links were directly to our server, I don't believe this issue would occur. Regards, - Mat On Sunday, 25 November 2018 20:37:27 UTC, Florian Apolloner wrote: > > I guess it would help to know how Safari's tracking protection does work > (I do not own a Mac) -- it seems hard to imagine that an internal redirect > on a page triggers the protection. In that sense it seems more like a > ISP-problem like Adam pointed out. > > On Sunday, November 25, 2018 at 9:39:28 AM UTC+1, Adam Johnson wrote: >> >> It sounds to me that this your email provider rewriting the link to go >> through their tracking site, and Safari now blocks the tracking site. I >> don't see how Django can do anything around this - the "internal token >> redirect" (which I guess means a Django generated redirect from one page to >> another on your site) is going to be after going through the tracking site, >> no? >> >> On Thu, 22 Nov 2018 at 09:51, Mat Gadd <dra...@gmail.com> wrote: >> >>> Hi all, >>> >>> I raised a ticket <https://code.djangoproject.com/ticket/29975> >>> regarding this and was directed here to discuss the topic. The summary is >>> that the combination of using click-tracking redirects (which are popular >>> with a variety of email providers) with the Django contrib.auth password >>> reset views does not work in Safari on macOS and iOS as of the latest major >>> versions. >>> >>> It took me quite a long time to work out what was happening, so I wanted >>> to at least raise a ticket where other people might find it, but was also >>> hoping to start a discussion around how else the problem could be >>> mitigated. An option to disable the internal token redirect might be >>> useful, but that then re-opens the token up to being leaked via the >>> HTTP_REFERER header. >>> >>> Regards, >>> - Mat >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> Adam >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/338f251c-c4e6-441e-a877-641c86974ffe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.