date:20190220

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

2019-02-20 Thread Philip James

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

Re: Fellow Reports - February 2019

2019-02-20 Thread Tim Graham

Week ending February 16, 2019

Reviewed/committed

https://github.com/django/django/pull/10875 - Refs #15902 -- Deprecated
storing current language in the session.

https://github.com/django/django/pull/10877 - Fixed #22423 - Added support
for MySQL operators on real geometries.

https://github.com/django/django/pull/10690 - Fixed #29943 -- Doc'd that
admin changelist adds pk to ordering.

https://github.com/django/django/pull/10989 - Fixed #30184 -- Removed
ellipsis characters from shell output strings.

https://github.com/django/django/pull/10973 - Fixed #30173 -- Simplified
db.backends.postgresql.client.

https://github.com/django/django/pull/10972 - Fixed #30171 -- Made
DatabaseWrapper thread sharing logic reentrant.

https://github.com/django/django/pull/10737 - Fixed #29619 -- Added field
names to some FieldErrors.
https://github.com/django/django/pull/10985 - Fixed #30181 -- Made
cache.get() with default work correctly on PyLibMCCache if None is cached.

--
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/98cfd1fb-8f7e-4d62-b470-e2e7747b0fe2%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

2019-02-20 Thread Mat Gadd

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-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.
For more options, visit https://groups.google.com/d/optout.

Re: Add an defer=True option for model fields

2019-02-20 Thread Adam Johnson

Dan, as to solving your problem with the Django of today: if you don't
mention a field in the Django model definition, Django won't select it. So,
you can declare the table for two Django models, and use "vertical
partitioning" so that when you query one, the other isn't selected, unless
it is added with select_related():

class LicensesDBView(models.Model):
file_name = models.TextField(primary_key=True)
file_type = ...
file_size = ...

class Meta:
managed = False
db_table = 'licenses_db_view'

class LicensesDBViewBlob(models.Model):
file_name = models.OneToOneField(LicensesDBView, primary_key=True)
file_data = models.BinaryField()

class Meta:
managed = False
db_table = 'licenses_db_view'

HTH,

Adam


On Wed, 20 Feb 2019 at 13:23, Josh Smeaton  wrote:

> There is a ticket for this one already, filed 4 years ago by me :)
>
> https://code.djangoproject.com/ticket/24096
>
> There are a few options described, but I think `defer=True` was winning
> out. I don't think we considered an `undefer`, but a `defer(None)` would
> fix that. Once that API is built, then we can consider getting LOB fields
> to defer themselves in specific situations.
>
> On Wednesday, 20 February 2019 05:02:50 UTC+11, Dan Davis wrote:
>>
>>
>> What I mean by the below:
>> > I was not sure whether to tell him to implement a ModelManager with a
>> get_queryset() method that defers the field,
>>
>> Of course this works, but I'm not going to maintain this code, and that
>> sort of sophistication creates a need for more sophisticated maintenance.
>>
>>
>> On Tue, Feb 19, 2019 at 12:43 PM Dan Davis  wrote:
>>
>>> I have a developer who stores the binary copy of a file in his table.
>>> In ColdFusion, this was acceptable, because he was writing every query by
>>> hand, and could simply exclude that field.  However, with the Django ORM it
>>> is a bit of a problem.   The primary table he uses is just for the file,
>>> and has a file_name, file_type, file_size, and BinaryField.
>>>
>>> The problem is that he has a database-level view that incorporates this
>>> field, and it may be that he needs to keep this because other schemas in
>>> our big-office Oracle use the view as an exported synonym.
>>>
>>> What I advised him to do was to take the BinaryField out of the
>>> database-level view, to protect the ORM from reading these large files into
>>> memory, as in:
>>>
>>>  [obj for obj in LicensesDBView.objects.all()]
>>>
>>> Or, if he cannot do that, to simply defer the field:
>>>
>>>  [obj for obj in
>>> LicensesDBView.objects.defer('scanned_license').all()]
>>>
>>> I was not sure whether to tell him to implement a ModelManager with a
>>> get_queryset() method that defers the field, but it made me wonder whether
>>> we should have a concept of an "initially deferred" field.
>>> That is, this is a field that starts deferred, and can be pulled into
>>> the select using a values iterator or a call to only() or defer(), e.g. the
>>> one that cancels prior defers.   The concept of "initially deferred" fields
>>> would certainly require a new queryset method, such as "nodefer" which is
>>> sort of like only but doesn't cause only those fields to load, or rather
>>> defer could accept a syntax like defer('-scanned_license') to cancel that
>>> previous deferred loading field.
>>>
>>> I'm afraid I probably don't understand all the implications of this
>>> feature, so I thought I'd bring it up on the list before filing any sort of
>>> issue. Its likely this has been discussed before; I cannot do a historical
>>> search all the time, especially when ancient history may not be today's
>>> read on this issue.
>>>
>>> --
>>> 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/ee5c04e5-69d6-42f9-95ff-c01d553b24c1%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-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
>

Re: Add an defer=True option for model fields

2019-02-20 Thread Josh Smeaton

There is a ticket for this one already, filed 4 years ago by me :)

https://code.djangoproject.com/ticket/24096

There are a few options described, but I think `defer=True` was winning 
out. I don't think we considered an `undefer`, but a `defer(None)` would 
fix that. Once that API is built, then we can consider getting LOB fields 
to defer themselves in specific situations.

On Wednesday, 20 February 2019 05:02:50 UTC+11, Dan Davis wrote:
>
>
> What I mean by the below:
> > I was not sure whether to tell him to implement a ModelManager with a 
> get_queryset() method that defers the field,
>
> Of course this works, but I'm not going to maintain this code, and that 
> sort of sophistication creates a need for more sophisticated maintenance.
>
>
> On Tue, Feb 19, 2019 at 12:43 PM Dan Davis  > wrote:
>
>> I have a developer who stores the binary copy of a file in his table.  In 
>> ColdFusion, this was acceptable, because he was writing every query by 
>> hand, and could simply exclude that field.  However, with the Django ORM it 
>> is a bit of a problem.   The primary table he uses is just for the file, 
>> and has a file_name, file_type, file_size, and BinaryField.
>>
>> The problem is that he has a database-level view that incorporates this 
>> field, and it may be that he needs to keep this because other schemas in 
>> our big-office Oracle use the view as an exported synonym.
>>
>> What I advised him to do was to take the BinaryField out of the 
>> database-level view, to protect the ORM from reading these large files into 
>> memory, as in:
>>
>>  [obj for obj in LicensesDBView.objects.all()] 
>>
>> Or, if he cannot do that, to simply defer the field:
>>
>>  [obj for obj in 
>> LicensesDBView.objects.defer('scanned_license').all()] 
>>
>> I was not sure whether to tell him to implement a ModelManager with a 
>> get_queryset() method that defers the field, but it made me wonder whether 
>> we should have a concept of an "initially deferred" field.
>> That is, this is a field that starts deferred, and can be pulled into the 
>> select using a values iterator or a call to only() or defer(), e.g. the one 
>> that cancels prior defers.   The concept of "initially deferred" fields 
>> would certainly require a new queryset method, such as "nodefer" which is 
>> sort of like only but doesn't cause only those fields to load, or rather 
>> defer could accept a syntax like defer('-scanned_license') to cancel that 
>> previous deferred loading field.
>>
>> I'm afraid I probably don't understand all the implications of this 
>> feature, so I thought I'd bring it up on the list before filing any sort of 
>> issue. Its likely this has been discussed before; I cannot do a historical 
>> search all the time, especially when ancient history may not be today's 
>> read on this issue.
>>
>> -- 
>> 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/ee5c04e5-69d6-42f9-95ff-c01d553b24c1%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-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/640bd321-2e8a-4958-bdff-a63ed92ad948%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Validation of m2m

2019-02-20 Thread Bernd Wechner

Ouch, I am not believing my eyes, but somewhat overjoyed with what I have 
found in my explorations over recent evenings empirically exploring 
transactions. The TLDR is this: I am puzzled that I haven't tested and 
found this to date, and that all the folk I read online asking for m2m ORM 
validation haven't, So puzzled I had to do a second take, a thorough retake 
and lots of note taking on the whole process. But in a nutshell it IS 
possible to do ORM validation of 2many relations - at least with Django 2.1 
and Postgresql. My findings are empirical and a dive down into the code 
again to back it with understanding is on my todo list. But I want to share 
the findings so far.

Essentially if in your form you override the post() method and use a 
transaction and add an explicit clean inside of that transaction then the 
objects clean() is called twice, once via form.is_valid() and the second 
time explicitly in our post() method. And stunningly on a CreateForm, the 
first time, with no id and no visible 2many relation data, but on the 
second all with an id and with all 2many relation data visible and there is 
at this point no change to the database yet!

In code form finding is clear and tested twice with thorough notes taken 
and here it is using a Book model straight out of the tutorials with the 
relations I want tested added:

class Book(models.Model):
title = models.CharField(max_length=100) 
authors = models.ManyToManyField(Author, related_name="books")
lead_author = models.ForeignKey(Author, on_delete=models.CASCADE)

def clean(self):
if (self.id is None):
# Validate all the model fields that are not One2Many or 
Many2Many
pass
else:
# Validate all the One2Many or Many2Many fields
pass


class Chapter(models.Model):
title = models.CharField(max_length=100)
book = models.ForeignKey(Book, on_delete=models.CASCADE, related_name=
"chapters")
author = models.ForeignKey(Author, on_delete=models.CASCADE, 
related_name="chapters")


class BookCreate(CreateView):
model = Book
fields = '__all__'

ChapterFormSet = inlineformset_factory(Book, Chapter, fields="__all__")

def post(self, request, *args, **kwargs):
self.form = self.get_form()

if self.form.is_valid():
try:
with transaction.atomic():
self.object = self.form.save(commit=True)

self.formset = self.ChapterFormSet(request.POST, request
.FILES, instance=self.object)
self.formset.is_valid():

self.formset.save()


self.object.clean() 
except IntegrityError:
transaction.set_rollback(True)
return self.form_invalid(self.form)
  
return self.form_valid(self.form)
else:
return self.form_invalid(self.form)

I have yet to nut out the nitty gritty of exceptions I throw in clean() and 
returning a form with error messages, but wanted to report this finding now 
to see who can shoot it down ;-).

I have not tested form errors with it yet, and I want to dive into the 
save() code to see how and why it's building a complete ORM with no sign of 
it in the database yet. It's GREAT that it does.

I have noticed that if the transaction on a Create is rolled back that in 
Postgresql at least this consumes the id that was provisioned to the ORM in 
the transaction. By which I mean the next Book created has the next id up, 
and the one in the baile dtransaction is gap in the id sequence of the 
table in the database. An interesting observation and of consequence only 
if ids are in short supply, or for some reason one wishes them to be 
consecutive (which is hard anyhow if you can delete records). 

Still, I admit I am blown away by this discovery, and there it is. We 
don't, it seems need to do anything to clean our 2many relations in the 
model itself, only override post() and use a transaction (which is sensible 
anyhow).

Comments welcome.

Regards,

Bernd.


-- 
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/449720b1-b794-4445-bdb3-0dcc5e99b199%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

Re: Fellow Reports - February 2019

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

Re: Add an defer=True option for model fields

Re: Add an defer=True option for model fields

Re: Validation of m2m

6 matches

Site Navigation

Mail list logo

Footer information