Mat, are you saying you're seeing Safari still blocking, even with click tracking turned off, because GMail itself is inserting a redirect?
PJJ http://philipjohnjames.com On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd <dra...@gmail.com> wrote: > We're also now seeing Gmail users complain that the password reset links > don't work, even after we disabled click tracking. It seems that Google are > inserting their own click tracking into users' emails, which is… weird? > > The markup of links is transformed to the following (where … is our > original URL): > > <a href="…" target="_blank" data-saferedirecturl=" > https://www.google.com/url?q=…";>Link text here</a> > > Gmail is a *huge* provider of emails, and they make up around 54% of our > user base. Anyone using the Gmail web app can no longer reset their > password simply by clicking the link in the email. > > On Wednesday, 23 January 2019 12:51:22 UTC, Perry Roper wrote: >> >> It would appear that this affects a large number of users. We're also >> experiencing this in the following configurations. >> >> - Mailgun click tracking enabled + Safari 12.0 on MacOS or any browser in >> iOS 12 >> - Clicking the link in the Gmail app or web app (Mailgun click tracking >> disabled) + Safari 12.0 on MacOS or any browser in iOS 12. >> >> All iOS 12 browsers and MacOS Safari users using the Gmail app, or in any >> email client if the site they are requesting a password from uses link >> tracking. >> >> On Thursday, 22 November 2018 20:43:15 UTC+7, Mat Gadd 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 django-developers@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/CACXM1yGLRk9zXvHX3DGdSbh%2B3MT2G%3DmhJ_%2BdUsPEVTf%2By%3DqaJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
