Re: Unicode normalization for username field
Hi Claude, > Le 23 avr. 2016 à 00:04, Claude Paroz a écrit : > > Le vendredi 22 avril 2016 14:25:59 UTC+2, Here's some code, unpolished, but a > base for discussion. > https://github.com/django/django/pull/6494 This patch looks pretty good. I have a few questions, not necessarily because I disagree with your proposal, but to make sure we have considered alternatives. Actually I don't think there's exactly one correct solution here; it's more a matter of tradeoffs. You added a username_validator attribute instead of documenting how to override the whole username field. Can you elaborate on this decision? I simplifies the use case targeted by the patch by introducing a one-off API. As a matter of principle I'm a bit skeptical of such special cases. But I understand the convenience. Normalization happens at the form layer. I'm wondering whether it would be safer to do it at the model layer. That would extend the security hardening to cases where users aren't created with a form — for example if they're created through an API or programmatically. I would keep ASCII usernames as the default because: - this has always been the intent; - allowing non ASCII usernames may result in interoperability problems with other software e.g. if a Django project is used as SSO server; - these interoperability issues might escalate into security vulnerabilities — there isn't a straightforward connection but (1) non ASCII data can be used for breaking out of parsing routines (2) I'm paranoid with anything that manipulates authentication credentials; - I'm afraid this change may result in boilerplate as most custom user models will revert to Django's historical (and in my opinion sensible) username validation rules. Finally, I would add a test to check that a username containing a zero-width space is rejected, just to make sure we never accidentally make it trivial to create usernames that render identically, which this PR aims at preventing. It will be rejected because it won't match \w. Best regards, -- Aymeric. -- 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/DCD0DA6C-B366-4602-8823-9E51CB054458%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Re: is_authenticated as property
Am Montag, 11. April 2016 18:57:46 UTC+2 schrieb Tim Graham: > > Do you think the backwards incompatibility is justified here or do you > prefer some other solution? > I for one think it is justified here. -- 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/3d8ea847-5049-4b16-8462-c8eaf7bc2ce4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
Hi, I hope I am not too late to the discussion (and I hope it's the right one). :) Am Mittwoch, 6. April 2016 15:42:58 UTC+2 schrieb Collin Anderson: - Why select2? I haven't heard any serious proposals of a different library to use. Internally, we had the same debate of upgrading our widgets for ForeignKey/ManyToMany, so I would like to share the current result with you. Unfortunately, we ended up with two different widgets: 1) django-selectable 2) select2 We found that select2 only makes sense for a *very very small number* of selected items but allows on-the-fly creation of items even for many-to-many relations. Thus, we use if for email address fields and tags: foreign keys but text input suffices for creation. On the other hand, if you need to distribute 800 users among 70 groups, where even half the users can be in a single group, then select2 is not the right widget. That's where selectable comes in. The presentation of the selection *as a list* appears to be less confusing. Just wanted to share this with you even if you might already have decided to use select2. Sven -- 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/6dc267db-390e-4587-a3fe-c391303655c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Test projects needed for removal of Field.get_db_prep_lookup()/get_prep_lookup()
Claude and I have been working on a ticket [0] to remove the Field.get_db_prep_lookup() and Field.get_prep_lookup() methods in favor of moving that functionality to the lookups themselves. It would be helpful if we had some test apps and/or projects that implement these methods so we can determine what level of backwards-compatibility is needed. If you're using those methods in your project, could you see if Claude's latest pull request [1] breaks anything for you? [0] https://code.djangoproject.com/ticket/22936 [1] https://github.com/django/django/pull/6499 -- 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/86bee24f-091c-469c-9b7d-c60432dd52a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fellow Report - April 23, 2016
Triaged
---
https://code.djangoproject.com/ticket/23356 - Unable to create template tag
which behaves similar to {% verbatim %} (accepted)
https://code.djangoproject.com/ticket/26514 - User.refresh_from_db() does
not clear Permission cache (fixed)
https://code.djangoproject.com/ticket/26518 - Refactor admin view functions
to allow for easier overrides (duplicate)
https://code.djangoproject.com/ticket/26524 - Change foreign key id
list_display reference to display only the id (accepted)
https://code.djangoproject.com/ticket/26529 - migration: Add argument or
flag which indicates the current db (invalid)
Authored
https://github.com/django/django/pull/6490 - Fixed #26320 -- Deprecated
implicit OneToOnField parent_link.
https://github.com/django/django/pull/6496 - Fixed #26533 -- Renamed
Widget._format_value() to format_value().
Reviewed/committed
--
https://github.com/django/django/pull/6450 - Fixed #26498 -- Fixed
TimeField microseconds round-tripping on MySQL and SQLite.
https://github.com/django/django/pull/6475 - Fixed #26516 -- Added
minlength attribute when forms.CharField.min_length is set.
https://github.com/django/django/pull/6470 - Fixed #26475 -- Added
functools.partial() support to migrations autodetector.
https://github.com/django/django/pull/6476 - Fixed #26512 -- Added tests
for SpatialRefSysMixin.get_units().
https://github.com/django/django/pull/6403 - Fixed #16327 -- Redirected
"Save as new" to change view instead of the changelist.
https://github.com/django/django/pull/6480 - Fixed #26520 -- Fixed a
regression where SessionBase.pop() didn't raise a KeyError.
https://github.com/django/django/pull/6407 - Fixed #26281 -- Added a
helpful error message for an invalid format specifier to
dateformat.format().
https://github.com/django/django/pull/6453 - Fixed #26504 -- Avoided
logging "Not Found" warnings if a middleware handles the 404.
https://github.com/django/django/pull/6448 - Fixed #26495 -- Added name arg
to Storage.save()'s File wrapping.
https://github.com/django/django/pull/6352 - Fixed #22383 -- Added support
for HTML5 required attribute on required form fields.
Reviews of core dev work
https://github.com/django/django/pull/6469 - Fixed #22561 -- Prevented
email message line lengths from exceeding the RFC5322 limit.
https://github.com/django/django/pull/6486 - Fixed #26528 -- Allowed any
iterable (e.g. tuple) as validators kwarg for form/model fields.
https://github.com/django/django/pull/6460 - Fixed #20189 -- Allowed
customizing staticfiles ignored_patterns list
https://github.com/django/django/pull/4726 - Refs #3254 -- Added full text
search to contrib.postgres.
--
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/662b1e18-343a-4382-bc38-4295393d6161%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
