PASSWORD_HASHERS Check
I think it would be a good idea to add a check for insecure hashers on PASSWORD_HASHERS[0], I know the insecure ones are not enabled by default, but I think it would be useful to warn users that have enabled them that it's a bad idea. They could have enabled them on production while thinking they only enabled them for testing for example. -- 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/c70419c8-5328-4665-a8bf-0cc0a99c5dcbn%40googlegroups.com.
Re: PASSWORD_HASHERS Check
If you happen to be using pytest and want to detect if you're testing, there's a really bad recommendation on this ticket: https://github.com/pytest-dev/pytest-django/issues/333, now that alone works, but if you were to import pytest, you would be running some test settings and be none the wiser. Also I think it's a good practice, you could have modified PASSWORD_HASHERS years ago, and the hasher that was once secure is not any more. On Tue, Jun 21, 2022 at 12:31 PM Tim Graham wrote: > For context, Francisco proposed this at > https://code.djangoproject.com/ticket/33793 which was marked wontfix by > Mariusz > with the comment: > > > Django keeps "weak" password hashers for support with legacy systems > and speeding up the tests > <https://docs.djangoproject.com/en/stable/topics/testing/overview/#password-hashing>. > Moreover they are not enabled by default > <https://docs.djangoproject.com/en/stable/ref/settings/#password-hashers>, > so you must add them explicitly to the PASSWORD_HASHERS. Folks that do > this should be aware of their weakness. IMO there is not need for a new > system check. > > Francisco, have you seen this mistake made? It doesn't seem very likely to > me. Typically, the setting is customized in a test settings file; thus, I > don't see how this could propagate to a production environment. > > On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote: > >> I think it would be a good idea to add a check for insecure hashers on >> PASSWORD_HASHERS[0], >> I know the insecure ones are not enabled by default, but I think it would >> be useful to warn users that have enabled them that it's a bad idea. >> >> They could have enabled them on production while thinking they only >> enabled them for testing for example. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/CBdwSCiDKwY/unsubscribe > . > To unsubscribe from this group and all its topics, 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/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHx8S1uCzT%2BXitwsA1p4gYNM9VbpOS9fTpfHKrNY_DTDEct4BQ%40mail.gmail.com.
Re: PASSWORD_HASHERS Check
Here is a real-world example I found on a quick search: https://github.com/dimagi/commcare-hq/blob/6be7be39cb3f554670685e811a15720d46cc4a2d/settings.py#L192 On Fri, Jun 24, 2022 at 11:00 PM Francisco Couzo wrote: > If you happen to be using pytest and want to detect if you're testing, > there's a really bad recommendation on this ticket: > https://github.com/pytest-dev/pytest-django/issues/333, now that alone > works, but if you were to import pytest, you would be running some test > settings and be none the wiser. > > Also I think it's a good practice, you could have modified > PASSWORD_HASHERS years ago, and the hasher that was once secure is not any > more. > > On Tue, Jun 21, 2022 at 12:31 PM Tim Graham wrote: > >> For context, Francisco proposed this at >> https://code.djangoproject.com/ticket/33793 which was marked wontfix by >> Mariusz >> with the comment: >> >> > Django keeps "weak" password hashers for support with legacy systems >> and speeding up the tests >> <https://docs.djangoproject.com/en/stable/topics/testing/overview/#password-hashing>. >> Moreover they are not enabled by default >> <https://docs.djangoproject.com/en/stable/ref/settings/#password-hashers>, >> so you must add them explicitly to the PASSWORD_HASHERS. Folks that do >> this should be aware of their weakness. IMO there is not need for a new >> system check. >> >> Francisco, have you seen this mistake made? It doesn't seem very likely >> to me. Typically, the setting is customized in a test settings file; thus, >> I don't see how this could propagate to a production environment. >> >> On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote: >> >>> I think it would be a good idea to add a check for insecure hashers on >>> PASSWORD_HASHERS[0], >>> I know the insecure ones are not enabled by default, but I think it would >>> be useful to warn users that have enabled them that it's a bad idea. >>> >>> They could have enabled them on production while thinking they only >>> enabled them for testing for example. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/django-developers/CBdwSCiDKwY/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAHx8S1tSQhDSqnoszEqDT_FRzGhSmmNBuuaGSP0EUcqgNFdSAA%40mail.gmail.com.
Exception [IntegrityError] - violates not-null constraint in email field
Hey guys. I'm developing a new project and creating a custom user model, extending the AbstractBaseUser class, but when add a new user in admin interface or modelform I get the error: IntegrityError at /null value in column "email" violates not-null constraint. The field email is necessary and I inform in the form, it's used to login too. It's necessary create a "custom modelform" too? I followed many tutorials by web, including documentation. Links bellow. https://docs.djangoproject.com/en/3.0/topics/auth/customizing/#custom-users-admin-full-example https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html#abstractbaseuser And, this my gist code of model, form and admin file. https://gist.github.com/fandrefh/ff6d8bbe047654174aa699072589539a -- 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/34e04b84-52d5-4cf0-9667-501969ea2370o%40googlegroups.com.
ConditionalGetMiddleware MD5
I think it would be a good idea to make ConditionalGetMiddleware use a hash function that's not as easy to find a collision as MD5, most probably SHA-256 or BLAKE2. I don't see a problem with just changing it, it will just invalidate the old cache. If there's an agreement on changing the hash function, I can make the PR. -- 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/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%40googlegroups.com.
Re: ConditionalGetMiddleware MD5
User 1 uploads a file User 2 downloads it, and caches it User 1 uploads a new file to the same URL, with the same MD5 hash User 2 will keep using the old file indefinitely Sure, user 1 has to upload two files with the same hash on purpose On Thu, Sep 10, 2020 at 11:07 AM Adam Johnson wrote: > What would this protect against? > > On Thu, 10 Sep 2020 at 03:56, Francisco Couzo > wrote: > >> I think it would be a good idea to make ConditionalGetMiddleware use a >> hash function that's not as easy to find a collision as MD5, most probably >> SHA-256 or BLAKE2. >> I don't see a problem with just changing it, it will just invalidate the >> old cache. >> If there's an agreement on changing the hash function, I can make the PR. >> >> >> >> >> >> >> >> >> >> -- >> >> >> 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/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- > 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/CAMyDDM1Db5tRDNXQEMLuX6UdOmjhUq0_-Dr_9kK%3DB5AUqsXG%2Bg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM1Db5tRDNXQEMLuX6UdOmjhUq0_-Dr_9kK%3DB5AUqsXG%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHx8S1vpoP9txnZrV4fTfwRJBCF2q-QtjnYpw%2BwAgGKbg4V5yQ%40mail.gmail.com.
Re: ConditionalGetMiddleware MD5
If changing ConditionalGetMiddleware to use SHA-256 It also might be a good to change it on FileBasedCache, _generate_cache_key, and generate_cache_header_key too Also, _generate_cache_key is just blindly concatenating hashes, so ['foo', 'bar'] is equal to ['fo', 'obar'], I don't know it might be a problem, but it just doesn't looks right On Thu, Sep 10, 2020 at 10:14 PM Taymon A. Beal wrote: > That attack doesn't work with the recommended production setup because > Django doesn't serve uploaded files in that setup. > > That being said, some users might be doing that anyway since setting > up production-worthy upload hosting is such a pain, and even if they > don't, they might have other views that somehow allow users to control > the response body. So I think this should be treated as a > not-super-severe-but-still-worth-fixing security issue. > > What backwards-compatibility considerations exist? Do we consider it > normal for upgrading to a different Django version to bust users' > caches? I can't immediately think of any bad consequences of changing > the hash function, apart from that one. Busting users' caches doesn't > sound that terrible, given that, even if the hash function were > changed on every release (which of course it wouldn't be; SHA-2 has > been the most generally-recommended hash function for 15 years and > there are no signs that this will change), it would still only happen > once every eight months, and it's fairly rare for anything to be > cached that long in the first place, I think. > > Taymon > > > On Thu, Sep 10, 2020 at 1:16 PM Francisco Couzo > wrote: > > > > User 1 uploads a file > > User 2 downloads it, and caches it > > User 1 uploads a new file to the same URL, with the same MD5 hash > > User 2 will keep using the old file indefinitely > > > > Sure, user 1 has to upload two files with the same hash on purpose > > > > On Thu, Sep 10, 2020 at 11:07 AM Adam Johnson wrote: > >> > >> What would this protect against? > >> > >> On Thu, 10 Sep 2020 at 03:56, Francisco Couzo > wrote: > >>> > >>> I think it would be a good idea to make ConditionalGetMiddleware use a > hash function that's not as easy to find a collision as MD5, most probably > SHA-256 or BLAKE2. > >>> I don't see a problem with just changing it, it will just invalidate > the old cache. > >>> If there's an agreement on changing the hash function, I can make the > PR. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> > >>> 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/ff591d46-97fc-43d6-9d1c-d0ba24d7b1a8n%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/CAMyDDM1Db5tRDNXQEMLuX6UdOmjhUq0_-Dr_9kK%3DB5AUqsXG%2Bg%40mail.gmail.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/CAHx8S1vpoP9txnZrV4fTfwRJBCF2q-QtjnYpw%2BwAgGKbg4V5yQ%40mail.gmail.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/CAHRQ%3D85KUrrsv%3DeY7YW%3DXb%3DeD%2BdY9-eeeQQW0YuB5ckDmUgfEg%40mail.gmail.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/CAHx8S1tk%2BjjKgpkOdaKyMti8DeLiLLcO6GxjHJTguc47Q-P80g%40mail.gmail.com.
Weird error on bad form class
Hi. I've got a doubt about Django, but the reason I didn't post this on django-users was because the doubt was about Django's behaviour/design. If I was wrong to post here, I'm sorry. The problem occured when I was defining a form class. I made changes in a view, I wrote a form class and I made changes in a template. Then I went to see the result and Django blew with an error similar to this: "Could not import app.views.myview. View does not exist in module app.views.". This would be pretty normal if there was indeed a problem with my view, but after a long while trying to find the problem in it, I found out that the error was instead in my form class where I had tried to use a forms.TextField to get a textarea, which is the wrong way to do it. The same error would have appeared if I made a typo in the field class name instead. My problem is that there was indeed an error, so Django was right to blow in my face, I just wish the error was a bit more to the point. Now, is this normal, or was it a special case derived by my environment? Oh, and by the way, I'm using Django version 1.4.3. If this has already been fixed in 1.5 forget this... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Weird error on bad form class
Awh damn... There goes my change of reporting an actual bug in Django... xD It is fixed in Django 1.5, so thank you for fixing it! Francisco Vieira On 12/20/2012 09:46 PM, Florian Apolloner wrote: Hi, On Thursday, December 20, 2012 9:29:06 PM UTC+1, Francisco Vieira wrote: Oh, and by the way, I'm using Django version 1.4.3. If this has already been fixed in 1.5 forget this... I think I indeed fixed that for Django 1.5: https://github.com/django/django/commit/367bfaa5226eaae3278989e63f16063d5cc46cd8 -- Could you try and verify it? Thx, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ygTdT9CRHMwJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
py2exe + Django 1.6
Hi everyone, I was using py2exe + Django 1.3 without problems. From Django 1.4 the way to find the commands changed and it tries to find .py files as you can see in the find_commands() function in the file core/management/__init__.py . When you compile Django using py2exe, your don't have .py files, just .pyc and manage.exe won't have any command. I have tried to modify the find_command() function but the result was negative. Also, I have tried to run commands manually but the functions try to find .py files as well. Did anyone manage to do it? Cheers -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/98506afa-0514-414a-8285-f5692ac742a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Hybrid Property request
A feature I would really appreciate (as devs in http://stackoverflow.com/questions/12217763/does-django-orm-have-an-equivalent-to-sqlalchemys-hybrid-attribute, at least) is the Hybrid Property feature present in SQLAlchemy. They would really contribute to DRY principle. In django this would allow using it as a left-side for the key=value in a filter query (in sqlalchemy they filter by . as part of an expression ). Example: class Purchase(models.Model): first_name = CharField(...) last_name = CharField(...) ... @hybrid_property def full_name(self): return self.first_name + ' ' + self.full_name or ... class ProductEntry(models.Model): purchase = ForeignKey(Purchase, related_name='product_entries') onpurchase_price = DecimalField(...) product = ForeignKey(Product) quantity = DecimalField(...) ... @hybrid_property def cost(self): return self.onpurchase_price * self.quantity ... being those queries valid and working as expected Person.objects.filter(full_name__ilike='Martin') ProductEntry.objects.filter(cost__lt=5000.0) #SQLAlchemy would use ProductEntry.cost < 5000.0 -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
