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

[Curtis Maloney]

On 2/23/19 7:35 AM, Collin Anderson wrote:
I wouldn't mind just rolling back the security fix (or maybe making a 
straightforward way to enable/disable the behavior). We could instead 
encourage people to use  on any links (from the 
password rest page) to untrusted urls.


I don't think it would be controversial to add the rel="noreferrer" part 
to the docs no matter what choice we make about the other functionality.


--
Curtis


On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
wrote:


Just wanted to chime in and say we also experienced this issue. We
ended up having to revert the security fix that was added to the
view in Django just to avoid the flood of customers reporting they
couldn't reset their passwords on our apps anymore - so I'm assuming
this affects a lot of users out there.

torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:

You can see this in action yourself using Chrome's Dev Tools.
Open Dev Tools, then their Settings, and turn on "Auto-open
DevTools for popups". Then, click any link in the Gmail web app.
You'll see you go via google.com/url?q=original_url_here
. Since they're doing
this with JavaScript, the links look like they're going to open
the real URL, but they /don't./

On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:

Exactly that, yes. We've disabled all click tracking that we
can, but Gmail has its own redirect which causes Safari's
privacy features to kick in. (Some?) Gmail users are unable
to use the password reset emails.

On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:

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
 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):

https://www.google.com/url?q=
…">Link text here

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
 
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. 

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

[Collin Anderson]

I wouldn't mind just rolling back the security fix (or maybe making a 
straightforward way to enable/disable the behavior). We could instead 
encourage people to use  on any links (from the 
password rest page) to untrusted urls.

On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
wrote:
>
> Just wanted to chime in and say we also experienced this issue. We ended 
> up having to revert the security fix that was added to the view in Django 
> just to avoid the flood of customers reporting they couldn't reset their 
> passwords on our apps anymore - so I'm assuming this affects a lot of users 
> out there.
>
> torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:
>>
>> You can see this in action yourself using Chrome's Dev Tools. Open Dev 
>> Tools, then their Settings, and turn on "Auto-open DevTools for popups". 
>> Then, click any link in the Gmail web app. You'll see you go via 
>> google.com/url?q=original_url_here. Since they're doing this with 
>> JavaScript, the links look like they're going to open the real URL, but 
>> they *don't.*
>>
>> On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:
>>
>>> Exactly that, yes. We've disabled all click tracking that we can, but 
>>> Gmail has its own redirect which causes Safari's privacy features to kick 
>>> in. (Some?) Gmail users are unable to use the password reset emails.
>>>
>>> On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:

 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  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):
>
> https://www.google.com/url?q=…;>Link text here
>
> 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  
>>> 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/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups 

Fellow Reports -- February 2019

[Carlton Gibson]

Hi all. 


Calendar Week 6 -- ending 10 February.


Triaged:

https://code.djangoproject.com/ticket/30154 -- i18n: redirects to default 
login page if LOGIN_URL = login not specified (Accepted)
https://code.djangoproject.com/ticket/30149 -- Empty value selected check 
in Admin Filter prevents subclassing (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/29956 -- Allow formset form widget 
override for the ORDER field
https://code.djangoproject.com/ticket/30004 -- Set default 
FILE_UPLOAD_PERMISSION to 0o644.
https://code.djangoproject.com/ticket/29408 -- Add validation of related 
fields in model Meta.ordering
https://code.djangoproject.com/ticket/29915 -- Allow icontains lookup to 
accept uuids with or without dashes
https://code.djangoproject.com/ticket/30160 -- Added support for 
lzma-compressed tarfiles.
https://github.com/django/django/pull/10908 -- Update to logging 
documentation.



Authored:

https://github.com/django/django/pull/10928 -- Fixed #30154 -- Doc’d 
LOGIN_URL compat with i18n URLs.
https://github.com/django/django/commit/402c0caa851e265410fbcaa55318f22d2bf22ee2
--  Fixed CVE-2019-6975 -- Fixed memory exhaustion in 
utils.numberformat.format().




Calendar Week 7 -- ending 17 February.


Released Django 2.2b1, 2.1.6, 2.0.11, and 1.11.19 AND 2.17, 2.0.12 and 
1.11.20 AND 2.0.13. 
(This is a personal best, if not a project record. )


Reviewed:

https://code.djangoproject.com/ticket/12952 -- Models history doesnt 
use verbose names
https://code.djangoproject.com/ticket/11593 -- Incomplete support for 
app-level testing
https://code.djangoproject.com/ticket/30149 -- Empty value selected check 
in Admin Filter prevents subclassing
https://code.djangoproject.com/ticket/23004 -- Cleanse entries from 
request.META in debug views
https://code.djangoproject.com/ticket/29714 -- Make it easier to customise 
ExceptionReporter output.
https://code.djangoproject.com/ticket/29956 -- Allow formset form widget 
override for the ORDER field



Authored:

https://github.com/django/django/pull/10991 -- Restored use of realpath() 
in Admin script tests.



Kind Regards,

Carlton

-- 
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/4b2caa48-2a73-4363-bcd1-d93f602ebe63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Ossipoff Hansen]

Just wanted to chime in and say we also experienced this issue. We ended up 
having to revert the security fix that was added to the view in Django just 
to avoid the flood of customers reporting they couldn't reset their 
passwords on our apps anymore - so I'm assuming this affects a lot of users 
out there.

torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:
>
> You can see this in action yourself using Chrome's Dev Tools. Open Dev 
> Tools, then their Settings, and turn on "Auto-open DevTools for popups". 
> Then, click any link in the Gmail web app. You'll see you go via 
> google.com/url?q=original_url_here. Since they're doing this with 
> JavaScript, the links look like they're going to open the real URL, but 
> they *don't.*
>
> On Thu, 21 Feb 2019 at 10:44, Mat Gadd > 
> wrote:
>
>> Exactly that, yes. We've disabled all click tracking that we can, but 
>> Gmail has its own redirect which causes Safari's privacy features to kick 
>> in. (Some?) Gmail users are unable to use the password reset emails.
>>
>> On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:
>>>
>>> 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  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):

 https://www.google.com/url?q=…;>Link text here

 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  
>> 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/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com
  
 
 .
 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-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 
>>