Re: Vendoring Select2

[Johannes Hoppe]

Hi Sven,

you are right. For this particular case select2 would be an ill advice. But 
I didn't initially add support for m2m fields. I just added it later to my 
pull-requested, since it was only one line of code. And some people would 
have found a usecase for It.

At the end this will be an optional feature and I wouldn't enable it for 
users and groups ether. But than I don't have too.

Thanks for the feedback!

Joe

On Saturday, April 23, 2016 at 11:32:22 PM UTC+2, Sven R. Kunze wrote:
>
> 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/ac69257d-e01a-46fa-b24c-cd7810dda636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

One Click Django Installer

[Ankit Kumar]

Check this video :


https://www.youtube.com/watch?v=85P3Qn9Sccs 


Download installer file

https://www.dropbox.com/s/l8t483dqcjh8m75/Django.rar?dl=0

-- 
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/b500d149-3dcf-48e8-a909-be2d4030873f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode normalization for username field

[Claude Paroz]

Hi Aymeric,

Le samedi 23 avril 2016 14:33:56 UTC+2, Aymeric Augustin a écrit :
>
> > 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.
>

My preoccupation here was not to force users to create a custom user model 
just to change the username validation, especially as the migration system 
doesn't seem to support yet upgrading from the standard auth User to a 
custom user. I thought that creating a proxy custom user is easier 
migration-wise, as no new table is required. But I may be wrong.
 

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

Normalization happens both at the form layer and at the model layer in 
_create_user. You may have missed the _create_user change.
 

> I would keep ASCII usernames as the default because: 
>
> - this has always been the intent; 
>

Until now! Things are evolving, we see that for example with 
internationalized domain names. I think that most if not all technical 
reasons requiring pure ASCII usernames have vanished nowadays.
 

> - allowing non ASCII usernames may result in interoperability problems 
> with other software e.g. if a Django project is used as SSO server; 
>

These are still not the majority of Django use cases. And even then, I 
think that LDAPv3 for example should support unicode in attributes. Those 
project could still configure the ASCIIUsernameValidator if desired.
 

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

Sure, the more characters, the more attack surface. As you said before, 
it's a tradeoff. My thinking is that sooner or later, we'll have to cope 
with unicode in usernames. So let's do our most to not open security holes, 
based on some passed issues (BTW I think you forgot you references).
 

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

That's a tough question to estimate. This might be true for most English 
monolingual web sites, but not necessarily for the majority of Django 
sites. Hopefully we'll get some more user inputs in this thread.
 

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

Sure, good idea.
 
Globally, I totally understand your opinion, and I agree there is no 
"right" or "wrong" solution. Eventually, this might be a decision to be 
brought to the technical broad.

Claude

-- 
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/3c750af9-68f4-4e6c-88be-ead3fe0d3358%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Sven R. Kunze]

Hi Johannes,

Am Sonntag, 24. April 2016 10:16:53 UTC+2 schrieb Johannes Hoppe:
>
> Hi Sven,
>
> you are right. For this particular case select2 would be an ill advice. 
> But I didn't initially add support for m2m fields. I just added it later to 
> my pull-requested, since it was only one line of code. And some people 
> would have found a usecase for It.
>

I look forward to it.
 

> At the end this will be an optional feature and I wouldn't enable it for 
> users and groups ether. But than I don't have too.
>

Interesting. I didn't know one could choose a particular widget for foreign 
keys/m2m in the admin interface. Admittedly, I don't work on it regularly.
 

> Thanks for the feedback!
>

You are welcome. :)

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/bc197574-9819-4211-ba6d-711776362f7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.