Re: Sounding out for GSoC 2020.

[Sage M. Abdullah]

Thank you for the kind comments!

I see some very interesting ideas here. I haven't been able to come up with 
a good idea, but I can give a hand as a mentor next year, so I thought I'd 
join on this conversation :)

Andrew, I think the Django Case Studies will be a great idea for Season of 
Docs . It's a similar program 
from Google, but it's targeted towards technical writers. Carlton has 
talked about it on another thread. You might want to check that out as well.

Regards,
Sage

On Thursday, 19 December 2019 05:51:06 UTC+7, Adam Johnson wrote:
>
> This year was interesting. Sage in particular did well putting together a 
>> cross-db JSONField, but he was probably under-mentored, 
>> since Mariusz has spent quite a bit of time reworking the PR, and still 
>> has a bit to go, before we can pull it in, hopefully for 3.1
>>
>> So, one consideration we need to think about seriously is our capacity 
>> for mentoring. (This isn't just about the candidate's ability — Sage was 
>> able to implement all suggestions — we just didn't have as much capacity as 
>> we might have liked to think about the requirement implementation — and 
>> there were four of us actively giving some time each... — Anyhow, to think 
>> about.) 
>>
>
> I think your analysis is pretty accurate Carlton. Sage was a pretty 
> self-motivated candidate, writing some great blog posts about his code, and 
> we still didn't manage to merge his PR. Perhaps the project was larger than 
> we can reasonably expect?
>
> Nice work on the descriptions there Andrew.
>
> Django Service Hooks
>>
>
> I think a key use case of this is background task processing. Nearly all 
> the Django integrated libraries need to remember to "connection.close()" / 
> "close_old_connections" at the end of requests. I've seen a couple in-house 
> ones that needed this.
>
> That said I can't think of much else to go inside the "service hook"? 
> There's not much else to "the end of a Django context" at the moment is 
> there?
>
> Evented Datastores
>>
>
> I'm not sure if other databases have it but MariaDB recently implemented 
> "temporal tables" which are an SQL standard way of doing historical views 
> on data:  https://mariadb.com/kb/en/library/temporal-data-tables/ 
>
> Admittedly not quite the same as event sourcing but perhaps easier to 
> implement given it would be limited to the ORM layer.
>
> Django Benchmarking
>>
>
> I love djangobench, and do wish it was maintained and expanded. Running on 
> CI would be amazing. 
>
>
> 2FA also sounds like a great idea.
>
> Other ideas:
>
>- Support MySQL/MariaDB storage engines. I think other databases tend 
>to support some table-level customizations to.
>- Official CORS middleware/view decorator. I took over maintenance of 
>https://github.com/adamchainz/django-cors-headers and its design is a 
>bit pants.
>
>
> On Sat, 14 Dec 2019 at 17:30, Andrew Godwin  > wrote:
>
>> Here's my take on each of these, leaving out async as that'd be more 
>> dependent on where we were:
>>
>> Secrets Manager
>> Many environments Django is deployed in use a separate secrets manager to 
>> store and provide secrets per environment - either as environment 
>> variables, files, or via a direct HTTP API. The project would be to design 
>> and add an abstraction interface over secrets managers that allows users to 
>> easily map to an external secret in a settings file. There's also room for 
>> giving Django a better, built-in per-environments settings option too, 
>> pulling from popular third-party patterns.
>>
>> Django Service Hooks
>> Django has a lot tied to the HTTP lifecycle, and if you run it outside of 
>> this, you miss out on some key things - like database connections being 
>> closed properly, or logging, or some middleware. The project would be to 
>> design and implement a separate way of calling Django from a service 
>> framework - even if that framework was itself HTTP based (basically, don't 
>> rely on Django having to run through WSGI/ASGI). Initial idea is to provide 
>> a context manager that replaces the wrapping of a request, but the project 
>> would have to include requirements-gathering and interviewing people who 
>> use Django to power microservices to work out what they want.
>>
>> Evented Datastores
>> Evented, or event-sourcing, database schemas are growing in popularity - 
>> essentially, a way to implement an append-only pattern on top of a 
>> relational database, where every single event that has happened is stored, 
>> but you can still efficiently retrieve the current state of an item. Given 
>> the way the pattern works, this would be possible to implement on top of 
>> Django models - likely as a whole new Model subclass - and implement with a 
>> matching QuerySet/Model API. It would require someone very skilled in 
>> database design, and it's also arguable if it should be in Django itself, 
>> or comprise of developing a third-pa

Re: Sounding out for GSoC 2020.

[Adam Johnson]

>
> This year was interesting. Sage in particular did well putting together a
> cross-db JSONField, but he was probably under-mentored,
> since Mariusz has spent quite a bit of time reworking the PR, and still
> has a bit to go, before we can pull it in, hopefully for 3.1
>
> So, one consideration we need to think about seriously is our capacity for
> mentoring. (This isn't just about the candidate's ability — Sage was able
> to implement all suggestions — we just didn't have as much capacity as we
> might have liked to think about the requirement implementation — and there
> were four of us actively giving some time each... — Anyhow, to think
> about.)
>

I think your analysis is pretty accurate Carlton. Sage was a pretty
self-motivated candidate, writing some great blog posts about his code, and
we still didn't manage to merge his PR. Perhaps the project was larger than
we can reasonably expect?

Nice work on the descriptions there Andrew.

Django Service Hooks
>

I think a key use case of this is background task processing. Nearly all
the Django integrated libraries need to remember to "connection.close()" /
"close_old_connections" at the end of requests. I've seen a couple in-house
ones that needed this.

That said I can't think of much else to go inside the "service hook"?
There's not much else to "the end of a Django context" at the moment is
there?

Evented Datastores
>

I'm not sure if other databases have it but MariaDB recently implemented
"temporal tables" which are an SQL standard way of doing historical views
on data:  https://mariadb.com/kb/en/library/temporal-data-tables/

Admittedly not quite the same as event sourcing but perhaps easier to
implement given it would be limited to the ORM layer.

Django Benchmarking
>

I love djangobench, and do wish it was maintained and expanded. Running on
CI would be amazing.


2FA also sounds like a great idea.

Other ideas:

   - Support MySQL/MariaDB storage engines. I think other databases tend to
   support some table-level customizations to.
   - Official CORS middleware/view decorator. I took over maintenance of
   https://github.com/adamchainz/django-cors-headers and its design is a
   bit pants.


On Sat, 14 Dec 2019 at 17:30, Andrew Godwin  wrote:

> Here's my take on each of these, leaving out async as that'd be more
> dependent on where we were:
>
> Secrets Manager
> Many environments Django is deployed in use a separate secrets manager to
> store and provide secrets per environment - either as environment
> variables, files, or via a direct HTTP API. The project would be to design
> and add an abstraction interface over secrets managers that allows users to
> easily map to an external secret in a settings file. There's also room for
> giving Django a better, built-in per-environments settings option too,
> pulling from popular third-party patterns.
>
> Django Service Hooks
> Django has a lot tied to the HTTP lifecycle, and if you run it outside of
> this, you miss out on some key things - like database connections being
> closed properly, or logging, or some middleware. The project would be to
> design and implement a separate way of calling Django from a service
> framework - even if that framework was itself HTTP based (basically, don't
> rely on Django having to run through WSGI/ASGI). Initial idea is to provide
> a context manager that replaces the wrapping of a request, but the project
> would have to include requirements-gathering and interviewing people who
> use Django to power microservices to work out what they want.
>
> Evented Datastores
> Evented, or event-sourcing, database schemas are growing in popularity -
> essentially, a way to implement an append-only pattern on top of a
> relational database, where every single event that has happened is stored,
> but you can still efficiently retrieve the current state of an item. Given
> the way the pattern works, this would be possible to implement on top of
> Django models - likely as a whole new Model subclass - and implement with a
> matching QuerySet/Model API. It would require someone very skilled in
> database design, and it's also arguable if it should be in Django itself,
> or comprise of developing a third-party app alongside adding hooks/fixes to
> the Django ORM where needed to make it work well.
>
> GraphQL
> Basically, work on an "official" graphql-to-ORM mapper for Django,
> probably re-using a considerable amount of third-party work. This one could
> really vary in its application, based on how much other "API-ish" work the
> project includes (given that Django REST Framework is still separate, we
> should follow that rough pattern).
>
> Plus, some bonus ones that aren't Django code itself:
>
> Django Case Studies
> Our long-talked-about website which brings together case studies and white
> papers about why people choose Django, aimed at companies working out what
> they want to choose. This is likely only some coding and a lot of
> writing/legwork, so may not be a good

Re: Automatic admins registration

[Vladimir Godovalov]

среда, 18 декабря 2019 г., 19:46:18 UTC+3 пользователь Adam Johnson написал:
>
> Hi Vladimir
>
> Posting code to this mailing list is the wrong way to try make 
> contributions. Thanks for offering though.
>
> Please read the guides at 
> https://docs.djangoproject.com/en/dev/internals/contributing/ for how to 
> post tickets and code.
>
> However from a quick skim I'm not sure your code is valuable to add to 
> Django core at this time.
>
> Thanks,
>
> Adam
>
> On Wed, 18 Dec 2019 at 14:31, Vladimir Godovalov  > wrote:
>
>> Hello to everyone,
>>
>>
>> # This non-trivial patch improve Django functionality
>> # by providing automatic registration in main admin.py
>> # of all admin files of the project
>>
>>
>>
>>   admin.py module code  
>>
>> # admin.py
>> import importlib
>> from django.contrib import admin
>> from django.apps import apps
>>
>>
>> # automatic registration module
>> models = apps.get_models()
>> for model in models:
>> model_name = str(model.__name__)
>>
>> # import and registration
>> app_list = model.__module__.split(".")
>> idx = app_list.index('models')
>> app1 = app_list[idx-1]
>> del app_list[idx:]
>>
>> try:
>> module = 
>> importlib.import_module('.'.join(app_list)+'.'+app1.title()+'Admin')
>> except ImportError:
>> continue
>> class_admin = module.str_to_class(model_name+'Admin')
>> if class_admin is None:
>> continue
>> try:
>> admin.site.register(model, class_admin)
>> except admin.sites.AlreadyRegistered:
>> pass
>>
>>
>> ###  an application admin module code  ###
>> # make sure the module name looks like 'BaseAdmin.py',
>> # where the module name begins with the application
>> # name in uppercase as well as the word 'Admin'
>>
>> # BaseAdmin.py
>> import sys
>>
>> 
>>
>> insert your code here
>>
>> 
>>
>>
>> def str_to_class(str):
>> try:
>> obj = getattr(sys.modules[__name__], str)
>> except AttributeError:
>> return None
>> return obj
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1fddfa20-339f-463a-a168-e86d8bb3f739%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>
 
 

Thanks Adam, I will do it the right way.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fa518ec-36f4-4963-b82e-5908ee6b5d2e%40googlegroups.com.

Re: Automatic admins registration

[Adam Johnson]

Hi Vladimir

Posting code to this mailing list is the wrong way to try make
contributions. Thanks for offering though.

Please read the guides at
https://docs.djangoproject.com/en/dev/internals/contributing/ for how to
post tickets and code.

However from a quick skim I'm not sure your code is valuable to add to
Django core at this time.

Thanks,

Adam

On Wed, 18 Dec 2019 at 14:31, Vladimir Godovalov  wrote:

> Hello to everyone,
>
>
> # This non-trivial patch improve Django functionality
> # by providing automatic registration in main admin.py
> # of all admin files of the project
>
>
>
>   admin.py module code  
>
> # admin.py
> import importlib
> from django.contrib import admin
> from django.apps import apps
>
>
> # automatic registration module
> models = apps.get_models()
> for model in models:
> model_name = str(model.__name__)
>
> # import and registration
> app_list = model.__module__.split(".")
> idx = app_list.index('models')
> app1 = app_list[idx-1]
> del app_list[idx:]
>
> try:
> module =
> importlib.import_module('.'.join(app_list)+'.'+app1.title()+'Admin')
> except ImportError:
> continue
> class_admin = module.str_to_class(model_name+'Admin')
> if class_admin is None:
> continue
> try:
> admin.site.register(model, class_admin)
> except admin.sites.AlreadyRegistered:
> pass
>
>
> ###  an application admin module code  ###
> # make sure the module name looks like 'BaseAdmin.py',
> # where the module name begins with the application
> # name in uppercase as well as the word 'Admin'
>
> # BaseAdmin.py
> import sys
>
> 
>
> insert your code here
>
> 
>
>
> def str_to_class(str):
> try:
> obj = getattr(sys.modules[__name__], str)
> except AttributeError:
> return None
> return obj
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1fddfa20-339f-463a-a168-e86d8bb3f739%40googlegroups.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3KM9dP0s4G9Ti_fz%2B%3DMoDhdX1viHcULvOHoXhKmVDSCA%40mail.gmail.com.

Automatic admins registration

[Vladimir Godovalov]

Hello to everyone,


# This non-trivial patch improve Django functionality
# by providing automatic registration in main admin.py
# of all admin files of the project



  admin.py module code  

# admin.py
import importlib
from django.contrib import admin
from django.apps import apps


# automatic registration module
models = apps.get_models()
for model in models:
model_name = str(model.__name__)

# import and registration
app_list = model.__module__.split(".")
idx = app_list.index('models')
app1 = app_list[idx-1]
del app_list[idx:]

try:
module = 
importlib.import_module('.'.join(app_list)+'.'+app1.title()+'Admin')
except ImportError:
continue
class_admin = module.str_to_class(model_name+'Admin')
if class_admin is None:
continue
try:
admin.site.register(model, class_admin)
except admin.sites.AlreadyRegistered:
pass


###  an application admin module code  ###
# make sure the module name looks like 'BaseAdmin.py',
# where the module name begins with the application
# name in uppercase as well as the word 'Admin'

# BaseAdmin.py
import sys



insert your code here




def str_to_class(str):
try:
obj = getattr(sys.modules[__name__], str)
except AttributeError:
return None
return obj

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fddfa20-339f-463a-a168-e86d8bb3f739%40googlegroups.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[אורי]

Django developers,

We use Django 2.1 and anyway I saw that Django expects each user to have
one email address, where on Speedy Net each user can have multiple email
addresses. So I had to override *def save* in *class PasswordResetForm* on
Speedy Net:

https://github.com/speedy-net/speedy-net/blob/master/speedy/core/accounts/forms.py#L228-L279

I also added logging info to let us know who used the password reset form
and who received the password reset link.

I also checked and I noticed that if I reset the password of u...@speedy.net,
the email is sent to u...@speedy.net instead of u...@speedy.net - the email
is sent to the email the user submitted instead of the email the user has
on the database. This is a mistake. So I also updated the email to be sent
to the email the user has on the database - but the one matching the user
input and not just the primary email. So if a user has 2 email addresses,
and one stopped working, he can reset his password to the second email
address too, even if it's not his primary email address.

I decided to keep using Django 2.1 since there is still not a solution to
our Hebrew translation problem which I wrote you about in November.

Here is the code we use now (after I updated it today):

class PasswordResetForm(auth_forms.PasswordResetForm):
@property
def helper(self):
helper = FormHelperWithDefaults()
helper.add_input(Submit('submit', _('Submit')))
return helper

def get_users(self, email):
"""
Given an email, return matching user(s) who should receive a reset.
"""
email_addresses =
UserEmailAddress.objects.select_related('user').filter(email__iexact=email.lower())
return {e.user for e in email_addresses if ((e.email ==
email.lower()) and (e.user.has_usable_password()))}

def send_mail(self, subject_template_name, email_template_name,
context, from_email, to_email, html_email_template_name=None):
"""
Send a django.core.mail.EmailMultiAlternatives to `to_email`.
"""
send_mail(to=[to_email],
template_name_prefix='email/accounts/password_reset', context=context)

def save(self, domain_override=None,
subject_template_name='registration/password_reset_subject.txt',
email_template_name='registration/password_reset_email.html',
use_https=False, token_generator=default_token_generator,
from_email=None, request=None, html_email_template_name=None,
extra_email_context=None):
"""
Generate a one-use only link for resetting password and send
it to the user.
"""
email = self.cleaned_data["email"]
site = Site.objects.get_current()
users_list = self.get_users(email)
logger.info("PasswordResetForm::User submitted form,
site_name={site_name}, email={email},
matching_users={matching_users}".format(site_name=_(site.name),
email=email, matching_users=len(users_list)))
for user in users_list:
if not domain_override:
current_site = get_current_site(request)
site_name = current_site.name
domain = current_site.domain
else:
site_name = domain = domain_override
user_email_list = [e.email for e in
user.email_addresses.all() if (e.email == email.lower())]
if (len(user_email_list) == 1):
user_email = user_email_list[0]
logger.info("PasswordResetForm::Sending reset link to
the user, site_name={site_name}, user={user},
user_email={user_email}".format(site_name=_(site_name), user=user,
user_email=user_email))
context = {
'email': user_email,
'domain': domain,
'site_name': site_name,
'uid': urlsafe_base64_encode(force_bytes(user.pk)).decode(),
'user': user,
'token': token_generator.make_token(user),
'protocol': 'https' if use_https else 'http',
**(extra_email_context or {}),
}
self.send_mail(subject_template_name,
email_template_name, context, from_email, user_email,
html_email_template_name=html_email_template_name)
else:
logger.error("PasswordResetForm::User doesn't have a
matching email address, site_name={site_name}, user={user},
email={email}".format(site_name=_(site_name), user=user, email=email))


אורי
u...@speedy.net


On Wed, Dec 18, 2019 at 11:23 AM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> Details are available on the Django project weblog:
>
> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
>
> --
> 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 view this discussion on the web vi

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Hanne Moa]

This depends on the collation that is used
. On a
system sorting everything as if it was Turkish, "ı" and "i" would be
considered two different letters, but I guess everywhere else they
would be merged into "i".

On Wed, 18 Dec 2019 at 14:09, Dirk Groten  wrote:
>
> I've been looking in more detail into this issue, as some other Django 
> packages are affected also by this issue. Now, when I run the tests that are 
> provided with this fix using SQLite, the issue does not occur, whereas it 
> does happen for PostgreSQL (I haven't tested for MySQL). Is it correct that 
> in Postgres, `User.objects.filter(email__iexact='mık...@example.org')` will 
> match a user with email "m...@example.org" but SQLite won't find a match? And 
> if so, why is that? Is it dependent on specific Postgres settings?
>
> On Wednesday, December 18, 2019 at 10:23:35 AM UTC+1, Mariusz Felisiak wrote:
>>
>> Details are available on the Django project weblog:
>>
>> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
>>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7ebbc544-c113-478b-9417-7f714fef783e%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACQ%3Drrco062GzUG_tavb1mVjtMJuh%3Dvth6%2Bi_UK6sAvmPPGZWg%40mail.gmail.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Mariusz Felisiak]

 

SQLite's only does an exact match, so it's not affected by Unicode Case 
Mapping Collisions.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8b73a544-2b8a-4663-95c2-b7f8898dbb91%40googlegroups.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Carlton Gibson]

HI Dirk. 

You're correct, the issue doesn't appear to arise on SQLite. Pass on 
exactly why right now. Maybe there's some PostgreSQL setting that might 
avoid it but, in general, it's not dependent on specific PostgreSQL 
settings. 

Kind Regards,

Carlton


On Wednesday, 18 December 2019 14:09:52 UTC+1, Dirk Groten wrote:
>
> I've been looking in more detail into this issue, as some other Django 
> packages are affected also by this issue. Now, when I run the tests that 
> are provided with this fix using SQLite, the issue does not occur, whereas 
> it does happen for PostgreSQL (I haven't tested for MySQL). Is it correct 
> that in Postgres, `User.objects.filter(email__iexact='mık...@example.org 
> ')` will match a user with email "mi...@example.org 
> " but SQLite won't find a match? And if so, why is that? Is 
> it dependent on specific Postgres settings?
>
> On Wednesday, December 18, 2019 at 10:23:35 AM UTC+1, Mariusz Felisiak 
> wrote:
>>
>> Details are available on the Django project weblog: 
>>
>> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aa488796-5cb3-4b46-93fc-d7cb2513ad40%40googlegroups.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Dirk Groten]

I've been looking in more detail into this issue, as some other Django 
packages are affected also by this issue. Now, when I run the tests that 
are provided with this fix using SQLite, the issue does not occur, whereas 
it does happen for PostgreSQL (I haven't tested for MySQL). Is it correct 
that in Postgres, `User.objects.filter(email__iexact='mık...@example.org')` 
will match a user with email "m...@example.org" but SQLite won't find a 
match? And if so, why is that? Is it dependent on specific Postgres 
settings?

On Wednesday, December 18, 2019 at 10:23:35 AM UTC+1, Mariusz Felisiak 
wrote:
>
> Details are available on the Django project weblog: 
>
> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ebbc544-c113-478b-9417-7f714fef783e%40googlegroups.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Markus Holtermann]

Thanks for checking and asking!

On Python 2, the email address with "i without dot" isn't a valid email address 
according to the EmailValidator and thus shouldn't be in your database in the 
first place.

Cheers,

/Markus 

On Wed, Dec 18, 2019, at 11:23 AM, Sam Willis wrote:
> Hi,
> 
> It looks to me like this has introduced a slight behaviour difference 
> with 1.11 on python 2.7 than on 3.x:
> 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36
> 
> The release notes don't indicate what the difference in behaviour is 
> between python 2 and 3.
> 
> I'm trying to follow the change and test cases but it looks like if you 
> have two users 'm...@example.org' and 'mık...@example.org' (which is 
> highly unlikely anyway to happen legitimately) neither can reset their 
> password anymore on py2?
> 
> See: 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
>  
> 
> I'm guessing this was found after the similar GitHub vulnerability was found?
> 
> Thanks for the hard work!
> 
> On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak 
> wrote:Details are available on the Django project weblog: 
> > 
> > https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7e03a11-10c3-4f7b-9932-2a9e0497e318%40www.fastmail.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Sam Willis]

Hi,

It looks to me like this has introduced a slight behaviour difference with 
1.11 on python 2.7 than on 3.x:

https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36

The release notes don't indicate what the difference in behaviour is 
between python 2 and 3.

I'm trying to follow the change and test cases but it looks like if you 
have two users 'm...@example.org' and 'mık...@example.org' (which is highly 
unlikely anyway to happen legitimately) neither can reset their password 
anymore on py2?

See: 
 
https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
 

I'm guessing this was found after the similar GitHub vulnerability was 
found?

Thanks for the hard work!

On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak wrote:
>
> Details are available on the Django project weblog: 
>
> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.com.

Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2019/dec/18/security-releases/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/87b42e7f-f80e-bd2b-6217-485b2fe41d37%40gmail.com.