Here are links to the dev discussions.
https://groups.google.com/d/msg/django-developers/MBSWXcQBP3k/XgWzGhpDBAAJ
On Thursday, 21 April 2016 10:47:43 UTC-4, Arun S wrote:
>
> thanks for some very useful information.
>
> I did raise this in the dev forum but it was not agreed to be a question
>
so it seems it would only need to use unicodedata.normalize(input, 'NFKD')
on usernames and passwords ?
https://docs.python.org/2/library/unicodedata.html
On Thu, Apr 21, 2016 at 6:11 PM, Rick Leir wrote:
> username = models.CharField(
>_('username'),
>
username = models.CharField(
_('username'),
max_length=150,
unique=True,
help_text=_('Required. 150 characters or fewer. Letters, digits and
@/./+/-/_ only.'),
validators=[ validators.RegexValidator( r'^[\w.@+-]+$',
It looks as if you could just clear the LOCALE
On Thu, Apr 21, 2016 at 07:47:42AM -0700, Arun S wrote:
> thanks for some very useful information.
>
> I did raise this in the dev forum but it was not agreed to be a
> question in that forum to discuss whether this should be taken up.
>
> I guess with all this input, this can be suggested
thanks for some very useful information.
I did raise this in the dev forum but it was not agreed to be a question in
that forum to discuss whether this should be taken up.
I guess with all this input, this can be suggested tough.
--
You received this message because you are subscribed to the
On Thu, Apr 21, 2016 at 07:30:07AM -0700, Rick Leir wrote:
> Here are the Stackoverflow discussions I mentioned Ñ )oops I have the
> Espanol keyboard selected=
>
> http://stackoverflow.com/questions/16173328/what-unicode
> -normalization-and-other-processing-is-appropriate-for-passwords-w
>
Here are the Stackoverflow discussions I mentioned Ñ )oops I have the
Espanol keyboard selected=
http://stackoverflow.com/questions/16173328/what-unicode
-normalization-and-other-processing-is-appropriate-for-passwords-w
http://stackoverflow.com/questions/2798794/how-do-i-properly-implement-
On Wed, Apr 20, 2016 at 07:42:26AM -0700, Arun S wrote:
> For ex, adding the Django Code Snippet for handling User names in the Login
> Page :
>
> default_username = (unicodedata.normalize('NFKD', default_username)
> So Django does follow Normalizing of Usernames usign NFKD Algorithm.
> Then
For ex, adding the Django Code Snippet for handling User names in the Login
Page :
default_username = (unicodedata.normalize('NFKD', default_username)
So Django does follow Normalizing of Usernames usign NFKD Algorithm.
Then applies Hashing Algorithms on this.
*But the same is never followed
There is also a new issue in Trac on this topic. I added two links to
Stackoverflow discussions there.
The issue: supposing a password is mañana. Depending on what client you use,
input methods can give you two different UTF8 characters for ñ. As a first
step, let's add test case, and check
> On Wed, Apr 20, 2016 at 4:16 PM, Arun S wrote:
>
> > let me try to clear my question.
> >
> > please correct me if am wrong.
> > basically all I want to know is that there already exists a number of
> > Unicode normalization forms.
> > Reference
> >
> > Unicode
actually upon further reading the document it seems it specifies on how to
handle unicode, it tells how unicode strings whould be stored.
if that's the case then it is not a django problem but a python problem.
if you are on python 3 then you are using unicode strings, python handles
that for
Does that mean that Unicode Normalisation is a very weak and unsecure way
for passwords?
In this case, what is the actual Usage of Unicode Normalization ?
Why exactly do we need something like a Unicode Normalization ?
Offcourse django provides various ways to strengthen and vallidate the
in summary: "Unicode Normalization Forms are formally defined
normalizations of Unicode strings which make it possible to determine
whether any two Unicode strings are equivalent to each other"
as I see this would be highly unsecure for passwords, this is something
like converting special
On Wed, Apr 20, 2016 at 03:02:06PM +0200, Erik Cederstrand wrote:
> Do you want passwords to be case-insensitive? If so, you can
> subclass AuthenticationForm and override clean_password(), and
> set_password() on your user model, and put any transformations of
> the raw password there.
A more
let me try to clear my question.
please correct me if am wrong.
basically all I want to know is that there already exists a number of Unicode
normalization forms.
Reference
Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms
so as I said as a part of a company norms, the
Hi Arun,
I'm not sure this is what you are referring to but Django 1.9 ships
with password validation[1] which can be configured to:
1. Prevent field similarity (e.g. password == username)
2. Enforce minimum password length
3. Prevent usage of common password (e.g. "password")
4.
On Wed, Apr 20, 2016 at 05:41:37AM -0700, Arun S wrote:
> basically I would like to know if the latest version of django
> already supports any kind of normalization for the login passwords.
Most of us probably have no idea what kind of normalization you are
talking about. At least I know I
> Den 20. apr. 2016 kl. 14.41 skrev Arun S :
>
> basically I would like to know if the latest version of django already
> supports any kind of normalization for the login passwords.
What exactly do you mean by "password normalization"? Do you want passwords to
be
basically I would like to know if the latest version of django already supports
any kind of normalization for the login passwords.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from
Hi,
As a Part of a very big project for a Company, we follow CSDL rules and we
use Django Extensively.
As a part of Django, we would like to Follow certain Normalisation Process
for all the Passwords during User Login.
In the Django Documentation, there isn’t any information on whether Django
21 matches
Mail list logo