Re: Changing the primary key of Django models

[Tim Graham]

By the way, the django-developers mailing list is about the development of 
Django itself. Please keep usage questions limited to django-users. Thanks!

On Friday, February 5, 2016 at 6:10:04 PM UTC-5, Dheerendra Rathor wrote:
>
> Yes you can keep custom primary key. Pass `primary_key=True` in your model 
> and Django won't create a primary key for that model. 
>
> Here are relevant docs: 
> https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key
>
> On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen  
> wrote:
>
>> To django-d...@googlegroups.com ,
>>
>> I'm a Django user and I'm working on converting Speedy Net from PHP to 
>> Django. I would like to know if it's possible in Django to change the 
>> primary key of Django models, such as User? I don't like the auto-increment 
>> default primary key, it doesn't make sense, and I want to use the primary 
>> key of users and pages also in urls. And therefore I decided that the id of 
>> users and pages, causes, groups and events on Speedy Net will be 15 
>> randomly generated digits. Users who already created accounts and pages on 
>> Speedy Net (with PHP) already have a 15-digits id, and I want to preserve 
>> this number when converting Speedy Net to Django. Is it possible? I don't 
>> want the id/primary key to be short (such as zuck's id on Facebook - 
>> https://www.facebook.com/messages/4) but 15-digits long.
>>
>> Thanks,
>> Uri.
>>
>> *Uri Even-Chen*   
>> [image: photo] Phone: +972-54-3995700
>> Email: u...@speedy.net 
>> Website: http://www.speedysoftware.com/uri/en/
>>   
>>   
>>   
>> 
>>
>>
>> -- Forwarded message --
>> From: Uri Even-Chen 
>> Date: Thu, Feb 4, 2016 at 6:20 PM
>> Subject: ID for users of Speedy Net
>> To: django...@googlegroups.com 
>> Cc: speedy-mai...@googlegroups.com 
>>
>>
>> To django...@googlegroups.com ,
>>
>> I'm working on the next version of Speedy Net , 
>> which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the 
>> specification of Speedy Net on 
>> https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
>>  (the 
>> file is System Requirements Specification - Speedy Net.txt). The old code 
>> is in PHP and can be found on 
>> https://www.assembla.com/spaces/speedynet/subversion/source (all the 
>> Speedy Net projects are free software and open source). According to my 
>> specification, each user will have a unique ID of 15 digits (a 
>> number between 100,000,000,000,000 and 999,999,999,999,999, randomly 
>> generated), which will be unique over the system (of users, pages, groups, 
>> causes and events). And each user will have a username, and pages, groups 
>> and causes may also have an optional username (it's called "username" also 
>> on Facebook).
>>
>> So my question is, can I make this random ID the primary key of the User 
>> model? I don't want users to have 2 ids - one for Django and one of Speedy 
>> Net, it doesn't make sense. I want the id to be the same and unique. I also 
>> want to have an Id model to prevent a page and a user (for example) to have 
>> the same ID. And a Username model to prevent them from having the same 
>> username. Is it possible to do it with Django 1.9.2?
>>
>> By the way, if you want to help me develop Speedy Net, Speedy Composer, 
>> Speedy Match or Speedy Mail, please let me know. If you want you can also 
>> join Speedy Net and grab yourself a username at Speedy Net. I'm also 
>> sending a copy of this message to speedy-mai...@googlegroups.com 
>> , the list of developers of the Speedy Net projects.
>>
>> I have another, off-topic question. Anyone knows how I can create a 
>> company in Switzerland, and how much does it cost? Any links to lawyers who 
>> can do it for me? I decided to host Speedy Net in Switzerland, because of 
>> the privacy laws there, and I prefer a Swiss company for the same reason 
>> (Israel is much less advanced in privacy than Europe and Switzerland). I'm 
>> a resident and citizen of Israel, with an option to become a Spanish 
>> citizen too. And I don't want to host private information of people in 
>> Israel.
>>
>> Thanks,
>> Uri.
>>
>> *Uri Even-Chen*  
>> [image: photo] Phone: +972-54-3995700
>> Email: u...@speedy.net 
>> Website: http://www.speedysoftware.com/uri/en/ 
>> 
>>   
>>   
>>   
>> 
>>
>> -- 
>> 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 

Re: Changing the primary key of Django models

[Dheerendra Rathor]

Yes you can keep custom primary key. Pass `primary_key=True` in your model
and Django won't create a primary key for that model.

Here are relevant docs:
https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key

On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen  wrote:

> To django-developers@googlegroups.com,
>
> I'm a Django user and I'm working on converting Speedy Net from PHP to
> Django. I would like to know if it's possible in Django to change the
> primary key of Django models, such as User? I don't like the auto-increment
> default primary key, it doesn't make sense, and I want to use the primary
> key of users and pages also in urls. And therefore I decided that the id of
> users and pages, causes, groups and events on Speedy Net will be 15
> randomly generated digits. Users who already created accounts and pages on
> Speedy Net (with PHP) already have a 15-digits id, and I want to preserve
> this number when converting Speedy Net to Django. Is it possible? I don't
> want the id/primary key to be short (such as zuck's id on Facebook -
> https://www.facebook.com/messages/4) but 15-digits long.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
>   
>
>
> -- Forwarded message --
> From: Uri Even-Chen 
> Date: Thu, Feb 4, 2016 at 6:20 PM
> Subject: ID for users of Speedy Net
> To: django-us...@googlegroups.com
> Cc: speedy-mail-softw...@googlegroups.com
>
>
> To django-us...@googlegroups.com,
>
> I'm working on the next version of Speedy Net ,
> which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the
> specification of Speedy Net on
> https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
>  (the
> file is System Requirements Specification - Speedy Net.txt). The old code
> is in PHP and can be found on
> https://www.assembla.com/spaces/speedynet/subversion/source (all the
> Speedy Net projects are free software and open source). According to my
> specification, each user will have a unique ID of 15 digits (a
> number between 100,000,000,000,000 and 999,999,999,999,999, randomly
> generated), which will be unique over the system (of users, pages, groups,
> causes and events). And each user will have a username, and pages, groups
> and causes may also have an optional username (it's called "username" also
> on Facebook).
>
> So my question is, can I make this random ID the primary key of the User
> model? I don't want users to have 2 ids - one for Django and one of Speedy
> Net, it doesn't make sense. I want the id to be the same and unique. I also
> want to have an Id model to prevent a page and a user (for example) to have
> the same ID. And a Username model to prevent them from having the same
> username. Is it possible to do it with Django 1.9.2?
>
> By the way, if you want to help me develop Speedy Net, Speedy Composer,
> Speedy Match or Speedy Mail, please let me know. If you want you can also
> join Speedy Net and grab yourself a username at Speedy Net. I'm also
> sending a copy of this message to speedy-mail-softw...@googlegroups.com,
> the list of developers of the Speedy Net projects.
>
> I have another, off-topic question. Anyone knows how I can create a
> company in Switzerland, and how much does it cost? Any links to lawyers who
> can do it for me? I decided to host Speedy Net in Switzerland, because of
> the privacy laws there, and I prefer a Swiss company for the same reason
> (Israel is much less advanced in privacy than Europe and Switzerland). I'm
> a resident and citizen of Israel, with an option to become a Spanish
> citizen too. And I don't want to host private information of people in
> Israel.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700 <+972-54-3995700>
> Email: u...@speedy.net 
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
> 
>   
>
> --
> 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/CAMQ2MsGMip-WreMzjrpZFxJUB3edJz9RQoiMLoo5tEwjU-7pfw%40mail.gmail.com
> 

Re: remove support for unsalted password hashers?

[Tim Graham]

I would guess most users aren't customizing the default list of hashers, so 
I'd rather remove weak hashers from the PASSWORD_HASHERS setting and let 
anyone who needs to use a weak hasher define their own setting (at which 
point a warning probably isn't needed). Does that seem okay?

On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote:
>
> Adding a check for weak password hashers could be a good compromise to 
> drive attention to the issue but make it reasonably easy to ignore it if 
> you need MD5 for compatibility with other systems.
>
> -- 
> Aymeric.
>
> On 5 févr. 2016, at 21:11, Sergei Maertens  > wrote:
>
> This is my main concern as well. I often migrate old Joomla or other PHP 
> things that use md5, and it's really convenient that Django upgrades the 
> passwords for free for me.
>
> Although I guess I could just write the hasher as part of the project and 
> add it to the setting, but then that's an additional burding because you 
> need to keep track of potential new hashers that get added in the default 
> settings.
>
> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>>
>> Will I still be able to implement unsalted hasher if I so desire?
>>
>> Don't get me wrong, I understand thats pretty crappy way to store 
>> password, but there are times when you inherit large set of data from site 
>> that you are moving from some old PHP contraption that happens to be around 
>> since 2006, is big (>100 users), ran by company that dominates one of 
>> nation's markets and says "absolutely no" on making all those housewifes 
>> reset passwords, and your passwords happen to use md5(md5(pass) + 
>> md5(pass)) for passwords?
>>
>
> -- 
> 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/56677162-c020-4c2f-8d1f-b35ec0b9874d%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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Changing the primary key of Django models

[Uri Even-Chen]

To django-developers@googlegroups.com,

I'm a Django user and I'm working on converting Speedy Net from PHP to
Django. I would like to know if it's possible in Django to change the
primary key of Django models, such as User? I don't like the auto-increment
default primary key, it doesn't make sense, and I want to use the primary
key of users and pages also in urls. And therefore I decided that the id of
users and pages, causes, groups and events on Speedy Net will be 15
randomly generated digits. Users who already created accounts and pages on
Speedy Net (with PHP) already have a 15-digits id, and I want to preserve
this number when converting Speedy Net to Django. Is it possible? I don't
want the id/primary key to be short (such as zuck's id on Facebook -
https://www.facebook.com/messages/4) but 15-digits long.

Thanks,
Uri.

*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700
Email: u...@speedy.net
Website: http://www.speedysoftware.com/uri/en/
  
    


-- Forwarded message --
From: Uri Even-Chen 
Date: Thu, Feb 4, 2016 at 6:20 PM
Subject: ID for users of Speedy Net
To: django-us...@googlegroups.com
Cc: speedy-mail-softw...@googlegroups.com


To django-us...@googlegroups.com,

I'm working on the next version of Speedy Net ,
which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the
specification of Speedy Net on
https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
(the
file is System Requirements Specification - Speedy Net.txt). The old code
is in PHP and can be found on
https://www.assembla.com/spaces/speedynet/subversion/source (all the Speedy
Net projects are free software and open source). According to my
specification, each user will have a unique ID of 15 digits (a
number between 100,000,000,000,000 and 999,999,999,999,999, randomly
generated), which will be unique over the system (of users, pages, groups,
causes and events). And each user will have a username, and pages, groups
and causes may also have an optional username (it's called "username" also
on Facebook).

So my question is, can I make this random ID the primary key of the User
model? I don't want users to have 2 ids - one for Django and one of Speedy
Net, it doesn't make sense. I want the id to be the same and unique. I also
want to have an Id model to prevent a page and a user (for example) to have
the same ID. And a Username model to prevent them from having the same
username. Is it possible to do it with Django 1.9.2?

By the way, if you want to help me develop Speedy Net, Speedy Composer,
Speedy Match or Speedy Mail, please let me know. If you want you can also
join Speedy Net and grab yourself a username at Speedy Net. I'm also
sending a copy of this message to speedy-mail-softw...@googlegroups.com,
the list of developers of the Speedy Net projects.

I have another, off-topic question. Anyone knows how I can create a company
in Switzerland, and how much does it cost? Any links to lawyers who can do
it for me? I decided to host Speedy Net in Switzerland, because of the
privacy laws there, and I prefer a Swiss company for the same reason
(Israel is much less advanced in privacy than Europe and Switzerland). I'm
a resident and citizen of Israel, with an option to become a Spanish
citizen too. And I don't want to host private information of people in
Israel.

Thanks,
Uri.

*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700 <+972-54-3995700>
Email: u...@speedy.net 
Website: http://www.speedysoftware.com/uri/en/

  
    

-- 
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/CAMQ2MsGMip-WreMzjrpZFxJUB3edJz9RQoiMLoo5tEwjU-7pfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Aymeric Augustin]

Adding a check for weak password hashers could be a good compromise to drive 
attention to the issue but make it reasonably easy to ignore it if you need MD5 
for compatibility with other systems.

-- 
Aymeric.

> On 5 févr. 2016, at 21:11, Sergei Maertens  wrote:
> 
> This is my main concern as well. I often migrate old Joomla or other PHP 
> things that use md5, and it's really convenient that Django upgrades the 
> passwords for free for me.
> 
> Although I guess I could just write the hasher as part of the project and add 
> it to the setting, but then that's an additional burding because you need to 
> keep track of potential new hashers that get added in the default settings.
> 
> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
> Will I still be able to implement unsalted hasher if I so desire?
> 
> Don't get me wrong, I understand thats pretty crappy way to store password, 
> but there are times when you inherit large set of data from site that you are 
> moving from some old PHP contraption that happens to be around since 2006, is 
> big (>100 users), ran by company that dominates one of nation's markets 
> and says "absolutely no" on making all those housewifes reset passwords, and 
> your passwords happen to use md5(md5(pass) + md5(pass)) for passwords?
> 
> -- 
> 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/56677162-c020-4c2f-8d1f-b35ec0b9874d%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/0A64944E-6096-4C90-A3F6-DBC8BB45B6FD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Sergei Maertens]

This is my main concern as well. I often migrate old Joomla or other PHP 
things that use md5, and it's really convenient that Django upgrades the 
passwords for free for me.

Although I guess I could just write the hasher as part of the project and 
add it to the setting, but then that's an additional burding because you 
need to keep track of potential new hashers that get added in the default 
settings.

On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>
> Will I still be able to implement unsalted hasher if I so desire?
>
> Don't get me wrong, I understand thats pretty crappy way to store 
> password, but there are times when you inherit large set of data from site 
> that you are moving from some old PHP contraption that happens to be around 
> since 2006, is big (>100 users), ran by company that dominates one of 
> nation's markets and says "absolutely no" on making all those housewifes 
> reset passwords, and your passwords happen to use md5(md5(pass) + 
> md5(pass)) for passwords?
>

-- 
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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django template modules compiled with cython

[Adam Johnson]

Hi guys,

I work with Alex here at YPlan. We deployed a tidied updated version of 
Alex's code as django-speedboost, since it looked promising in local 
profiling. You can see the code here: 
https://github.com/YPlan/django-speedboost . It uses a Cythonized version 
of Django 1.8.8's template engine, and passes Django 1.8.8's test suite. 
This is also compatible with 1.8.9, since there were no template changes, 
but not 1.9.x (as far as we know!).

However, we did take it out of production recently though. The speed boost 
we could measure locally with profiling, about 10% on whole page time, 
didn't seem to translate into a speed boost in production. We don't really 
know why, but since it's quite hackish and requires maintenance, we've 
stopped using it. Just wanted to let everyone know where we got.

Thanks,

Adam

On Tuesday, December 15, 2015 at 8:51:58 AM UTC, Florian Apolloner wrote:
>
>
>
> On Monday, December 14, 2015 at 3:53:50 PM UTC+1, Alexandru Damian wrote:
>>
>> I am not really convinced that replacing the whole file is a good idea. 
>>> In my experience one gets better results when using Cython by strategically 
>>> replacing single functions and rewriting those in C directly. 
>>>
>>
>> This is the actual approach I am taking, but at class level. I 
>> selectively choose the base classes and convert those to Cython language; 
>> the modules are packaged in as a whole to make packaging easier. 
>>
>
> Well, defaulttags.pyx and base.pyx seems to indicate to me that the whole 
> files are compiled? I understand that this is most likely due to cdefing 
> some base classes -- therefore you need a C-context. But that is what I 
> ment with replacing the whole files.
>
> Cheers,
> Florian 
>

-- 
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/76dc5b1b-62ca-4c61-b85b-231949a8961e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

I was thinking of a situation where you have md5 hashes in the database and 
want to run both Django and the legacy system at the same time. In that 
case, changing the password format in the database might not be an option 
if the legacy system needs to read plain hashes instead of Django's format. 
Maybe this isn't important to support. I thought it might be possible using 
the unsalted md5 hasher with algorithm='' but this givers 
ImproperlyConfigured("hasher doesn't specify an algorithm name").

On Friday, February 5, 2016 at 10:05:31 AM UTC-5, Donald Stufft wrote:
>
>
> > On Feb 5, 2016, at 10:04 AM, Tim Graham  > wrote: 
> > 
> > I'm not sure if we can keep support for unsalted hashes while removing 
> the special logic in identify_hasher() for those hashers since they don't 
> confirm to Django's normal hash format? 
> > 
> https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
>  
> > 
> > I guess a use case where you are integrating with a legacy system that 
> doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
> technique. 
>
> Seems like it would be trivial to migrate the database to make the hashed 
> password conform to the format. 
>
> - 
> Donald Stufft 
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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/49c680fb-3154-43d6-9dc1-3e46dc2f2b6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

I'm not sure if we can keep support for unsalted hashes while removing the 
special logic in identify_hasher() for those hashers since they don't 
confirm to Django's normal hash format?
https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9

I guess a use case where you are integrating with a legacy system that 
doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
technique.

On Friday, February 5, 2016 at 9:38:23 AM UTC-5, Donald Stufft wrote:
>
> > 
> > On Feb 5, 2016, at 7:05 AM, Rafał Pitoń  > wrote: 
> > 
> > Will I still be able to implement unsalted hasher if I so desire? 
> > 
> > Don't get me wrong, I understand thats pretty crappy way to store 
> password, but there are times when you inherit large set of data from site 
> that you are moving from some old PHP contraption that happens to be around 
> since 2006, is big (>100 users), ran by company that dominates one of 
> nation's markets and says "absolutely no" on making all those housewifes 
> reset passwords, and your passwords happen to use md5(md5(pass) + 
> md5(pass)) for passwords? 
>
>
> You can implement them still sure, there’s nothing stopping you. 
>
>
> You can also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed 
> the issue without needing to issue a password reset. 
>
> - 
> Donald Stufft 
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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/b3575cfa-ad79-42b0-9336-8f5bf31a6e55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Donald Stufft]

> On Feb 5, 2016, at 10:04 AM, Tim Graham  wrote:
> 
> I'm not sure if we can keep support for unsalted hashes while removing the 
> special logic in identify_hasher() for those hashers since they don't confirm 
> to Django's normal hash format?
> https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
> 
> I guess a use case where you are integrating with a legacy system that 
> doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
> technique.

Seems like it would be trivial to migrate the database to make the hashed 
password conform to the format.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/196F5D27-B720-4D9E-8EC4-074B18E9E8E2%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Donald Stufft]

> 
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń  wrote:
> 
> Will I still be able to implement unsalted hasher if I so desire?
> 
> Don't get me wrong, I understand thats pretty crappy way to store password, 
> but there are times when you inherit large set of data from site that you are 
> moving from some old PHP contraption that happens to be around since 2006, is 
> big (>100 users), ran by company that dominates one of nation's markets 
> and says "absolutely no" on making all those housewifes reset passwords, and 
> your passwords happen to use md5(md5(pass) + md5(pass)) for passwords?


You can implement them still sure, there’s nothing stopping you.


You can also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed the 
issue without needing to issue a password reset.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/0A69E02C-F025-4E4B-9709-8D135BA5539C%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Question] MySQL Microseconds stripping

[Adam Johnson]

Hi,

I've just finished converting all the datetime columns to datetime(6) in 
our database after an upgrade to MySQL 5.6. We don't use Django migrations, 
many of these were done manually with *pt-online-schema-change*. Just 
catching up on this thread, throwing some ideas in.

Why not strip the microseconds explicitly as soon as you're handed a datetime 
> with microseconds? 


A note here: stripping isn't what MySQL does - it actually *rounds*. This 
is the most annoying thing since it breaks a 5.6 replica feeding off a 5.5 
master - it's reported as unfixed bug here: 
https://bugs.mysql.com/bug.php?id=76948 . (Note: MariaDB kept the stripping 
behaviour).

We actually ended up patchy.patch ing 
MySQLdb.times.DateTime2literal so that microseconds never escaped the 
Python layer in the whole application, whilst we upgraded:

from MySQLdb.times import DateTime2literal
patchy.patch(DateTime2literal, """\
@@ -1,3 +1,4 @@
 def DateTime2literal(d, c):
 \"""Format a DateTime object as an ISO timestamp.\"""
+d = d.replace(microsecond=0)
 return string_literal(format_TIMESTAMP(d), c)
""")

converting every datetime column of every table to datetime(6) and afford 
> the extra storage (and probably


There's no extra storage usage in fact - the old format of datetime columns 
in 5.5 was less efficient than the new one in 5.6. Also, whenever you 
migrate a table that was created on 5.5 with datetime columns on 5.6, they 
get converted to the new format automatically. 

Does Django have visibility of the field constraints at insert/select 
> queryset time? 
>

Django could lookup the precision of datetime columns from 
*information_schema.columns* , but I don't think it's necessarily a great 
idea to change the field behaviour to match this.

./manage.py mysql-upgrade-microseconds && ./manage.py migrate ?
>

If you're imagining a command to generate migrations, you can't do this for 
third party apps. It might be better to have a command that simply outputs, 
or runs, the SQL to alter all tables, outside of the migrations framework? 
I'd've liked that, I ended up using a little script like that here to 
generate the SQL and then run it manually/with *pt-online-schema-change*. 
I'll look at open sourcing it in Django-MySQL so you guys can look at it.

On Tuesday, December 22, 2015 at 2:56:41 AM UTC, Cristiano Coelho wrote:
>
> I think a simple setting allowing to use the old behaviour should be 
> enough, shouldn't it? How does it handle other db backends? I'm not sure if 
> oracle has an option for datetime precision, but if it does, it makes sense 
> to have a global setting for datetime precision, as right now you are 
> pretty much forced to always go with a precision of 6 (at least on mysql?) 
> and that might be just too much if you want a simpler datetime.
>
> El lunes, 21 de diciembre de 2015, 19:54:29 (UTC-3), Josh Smeaton escribió:
>>
>> I think this is a fairly big oversight that should be fixed in the most 
>> backwards compatible way, so users don't need to change their code, or only 
>> have to change it minimally. I'm with Aymeric here. Does Django have 
>> visibility of the field constraints at insert/select queryset time? Ideally 
>> Django would handle the differences transparently. If that's not possible 
>> then we should have a migration or script that'll do the conversion on 
>> behalf of users once off.
>>
>> ./manage.py mysql-upgrade-microseconds && ./manage.py migrate ?
>>
>>
>> On Monday, 21 December 2015 19:39:44 UTC+11, Aymeric Augustin wrote:
>>>
>>> 2015-12-20 22:57 GMT+01:00 Cristiano Coelho :
>>>
 Thanks for the suggestion, I think that work around might just add too 
 much code, so I'm probably going the way of converting every datetime 
 column of every table to datetime(6) and afford the extra storage (and 
 probably a little performance impact ?).
 I think the documented change might need a little more of attention, 
 and mention something about that any equality query will stop working if 
 you either don't strip microseconds or update datetime columns to 
 datetime(6) (and not even datetime(3) will work...)

>>>
>>> If that's the solution we end up recommending -- because the horse has 
>>> left the barn months ago... -- then we must document it in detail.
>>>
>>> This is a large backwards incompatibility that may result in subtle bugs 
>>> and requires non-trivial steps to fix. It doesn't live up to Django's 
>>> standards.
>>>
>>> -- 
>>> 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