Re: Making assertNumQueries more useful by printing the list of queries executed on failure

[Aymeric Augustin]

On 15 nov. 2013, at 18:38, gavinw...@gmail.com wrote:

> Every time I get a failure on one of these types of tests I go in and edit 
> the code to print out the queries that were executed. There's no way to 
> troubleshoot the problem without know the queries.

I have also typed `from django.db import connection; print(connection.queries)` 
countless times.

We can debate whether assertNumQueries is a good practice — and with what I 
know of Django’s source code, I don’t doubt it’s an issue for third-party 
backends. Regardless I support making the failure message more useful.

— 
Aymeric.

-- 
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/13B03AD3--47C7-8040-3860A4067FFC%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Javier Guerra Giraldez]

On Fri, Nov 15, 2013 at 2:27 PM, Marc Tamlyn  wrote:
> That said, sounds an interesting solution and would make a good library.
> However I'm not knowledgeable enough to say if it is a good idea from a
> security perspective.


imagine this scenario:

an attacker gets the user database and _a_single_one of these cache entries.
the paswords are bcrypt, but the salts are cleartext.  the attacker
chooses _any_ user and calculates a password such that when
concatenated with that user's salt produces a collision [1] with the
single SHA1 cache key stolen.

in short, this library reduces the security from bcrypt to salted
SHA1, and the data needed for any and all the users to any single
cache entry.

hum i don't like it

[1]https://www.schneier.com/blog/archives/2005/02/sha1_broken.html


-- 
Javier

-- 
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/CAFkDaoQxxDF8wXVKQ0C2JG6KSD3DSS8u2yXBmh7mXc_roRA8UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Marc Tamlyn]

I would suggest that's the kind of thing which is unlikely to get merged,
mainly for security reasons as someone could potentially configure it more
wrong than other things. It's also only useful or relevant for nonstandard
large deployments such as yourselves.

That said, sounds an interesting solution and would make a good library.
However I'm not knowledgeable enough to say if it is a good idea from a
security perspective.

Marc
On 15 Nov 2013 18:45, "Erik van Zijst"  wrote:

> We run bitbucket.org and are upgrading from SHA1 to BCrypt hashes. We
> offer Basic Auth support which is used a lot. So much so that we can't
> handle the increased load from these more expensive hashes. This has been
> the cause behind a recent self-inflicted DOS.
>
> BCrypt and PBKDF2 are ~4-5 orders of magnitude slower than a SHA1
> (deliberately so of course), bringing them into the hundred ms per hash
> range. For a high volume site that's a rather steep price to pay. We
> would have to lower the number of rounds substantially, which would negate
> much of their strength.
>
> To make bcrypt scale, we wrote a hasher that stores user passwords and
> their hash results in Django's cache (Memcached in our case). To prevent
> plain text passwords leaving the process, we SHA1 the values first. The
> code is here: https://github.com/django/django/pull/1918/files
>
> How do people feel about this approach and should it be merged into
> Django? If not, then I can turn it into a library instead. Maybe at our
> size we're not in Django's sweet spot anymore. However, in their current
> version the recommended hashers are just not usable for us.
>
> Cheers,
> Erik
>
>  --
> 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/5f384586-2183-46b7-a6a2-9ffd14caa3b0%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CAMwjO1EFy4Bq5%2BKyn8XoNNsmrJeymrc1eTRajp38_muHnJXqeA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

BCrypt and PBKDF2 Password Hash Caching

[Erik van Zijst]

We run bitbucket.org and are upgrading from SHA1 to BCrypt hashes. We offer 
Basic Auth support which is used a lot. So much so that we can't handle the 
increased load from these more expensive hashes. This has been the cause 
behind a recent self-inflicted DOS.

BCrypt and PBKDF2 are ~4-5 orders of magnitude slower than a SHA1 
(deliberately so of course), bringing them into the hundred ms per hash 
range. For a high volume site that's a rather steep price to pay. We would 
have to lower the number of rounds substantially, which would negate much 
of their strength.

To make bcrypt scale, we wrote a hasher that stores user passwords and 
their hash results in Django's cache (Memcached in our case). To prevent 
plain text passwords leaving the process, we SHA1 the values first. The 
code is here: https://github.com/django/django/pull/1918/files

How do people feel about this approach and should it be merged into Django? 
If not, then I can turn it into a library instead. Maybe at our size we're 
not in Django's sweet spot anymore. However, in their current version the 
recommended hashers are just not usable for us.

Cheers,
Erik

-- 
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/5f384586-2183-46b7-a6a2-9ffd14caa3b0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making assertNumQueries more useful by printing the list of queries executed on failure

[gavinwahl]

Every time I get a failure on one of these types of tests I go in and edit 
the code to print out the queries that were executed. There's no way to 
troubleshoot the problem without know the queries.

On Wednesday, November 13, 2013 11:37:43 PM UTC-7, Dominic Rodger wrote:
>
> Currently, when assertNumQueries fails, the output is perhaps less helpful 
> than it might be:
>
> Traceback (most recent call last):
>   File 
> "/home/dom/.virtualenvs/kanisa/src/kanisa/kanisa/tests/views/public.py", 
> line 31, in test_kanisa_root_view
> [banner1.pk, banner2.pk, banner3.pk, banner5.pk, ])
>   File 
> "/home/dom/.virtualenvs/kanisa/src/kanisa/.tox/py27-1.5.X/local/lib/python2.7/site-packages/django/test/testcases.py",
>  
> line 195, in __exit__
> executed, self.num
> AssertionError: 5 queries executed, 99 expected
>
>
> When an assertNumQueries check fails, the first thing I (and I'd guess 
> everyone else too) want to know is what queries ran, so it'd be awesome if 
> an assertNumQueries failure printed the list of queries. Charlie Denton has 
> a blog post describing how he does this (
> http://meshy.co.uk/posts/debugging-assertnumqueries-tests/), but I'd like 
> to see this included in Django itself - since it seems generally helpful.
>
> I'm very happy to work on this and provide a patch (and a ticket), I just 
> wanted to solicit some feedback before I did too much work on it, in case 
> I'm missing a reason why this hasn't already been done (I appreciate this 
> can be done outside of Django, but I think its of sufficiently general 
> utility to warrant being in core).
>
> Dom
>

-- 
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/37d8ca4c-c8d3-4f46-b5a1-b32000bbf6b3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to livereload Django templates?

[charettes]

Hi Nikolay,

You could implement such a feature as a third party app by connecting a 
receiver to the 
template_renderedsignal.

I suggest you take a look at how django-debug-toolbar tracks which template 
were 
used.

Please move forward discussion to django-users since, as pointed out by 
Florian, it's out of django-developpers scope.

Thanks,
Simon

Le vendredi 15 novembre 2013 04:25:10 UTC-5, Nikolay Georgiev a écrit :
>
> Hi Florian,
>
> after trying to add livereload I came to the conclusion that it should be 
> implemented in Django itself. I managed to add CSS livereload with Cross 
> Browser CSS Injection: http://css-tricks.com/cross-browser-css-injection/, 
> but HTML files cannot be reloaded without knowing how Django templating 
> works. That's why I help is needed not from the user, but from the Django 
> developers.
>
> The easiest implementation would be: If a Django template (HTML) changes, 
> refresh the browser.
>
> How can this be implemented in Django itself?
>
> Greetings,
>
> Nikolay
>
>
> On Tuesday, November 12, 2013 11:08:44 PM UTC+1, Florian Apolloner wrote:
>>
>> Hi Nikolay,
>>
>> this mailing lists is about the development of Django itself; you might 
>> wanna ask that on django-users
>>
>> Regards,
>> Florian
>>
>> On Monday, November 11, 2013 5:45:42 PM UTC+1, Nikolay Georgiev wrote:
>>>
>>> Do you know some tips or concrete steps on how to livereload Django 
>>> templates?
>>>
>>> Livereloading means that if I change the HTML Template, CSS or JS files 
>>> that these files will be automatically reloaded in the browser, without me 
>>> having to refresh the page manually. This leads to increased productivity. 
>>> http://livereload.com/
>>>
>>> Thank you very much!
>>>
>>> Nikolay
>>>
>>

-- 
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/5ddff85f-231a-406d-a03f-d0daf0c16376%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: mod_wsgi setup

[Tim Graham]

This list is for the discussion of the development Django itself. I see 
you've already cross-posted to django-users which is the correct list to 
get help.

On Friday, November 15, 2013 4:36:53 AM UTC-5, tin...@gmail.com wrote:
>
> Hello,
>
> I am trying to setup a python 2.7 + Django + virtualenv + mod_wsgi 
> environment in my centos 6.3 server to run my python application through 
> apache.
> But I am getting internal error while trying to access the application 
> through apache. The error log shows the following.
>
> 
> [Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] mod_wsgi 
> (pid=20361): Target WSGI script '/var/www/html/djangosites/spark.wsgi' 
> cannot be loaded as Python module.
> [Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] mod_wsgi 
> (pid=20361): Exception occurred processing WSGI script 
> '/var/www/html/djangosites/spark.wsgi'.
> Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] 
> ImproperlyConfigured: Requested setting DEBUG, but settings are not 
> configured. You must either define the environment variable 
> DJANGO_SETTINGS_MODULE or call settings.configure() before accessing 
> settings.
>
> 
>
> It is working fine when running as a test server.
>
> ==
> (virtualenv)[root@lampserver spark]# python manage.py runserver 
> 0.0.0.0:8080
> Validating models...
>
> 0 errors found
> November 15, 2013 - 09:15:19
> Django version 1.6, using settings 'spark.settings'
> Starting development server at http://0.0.0.0:8080/
> Quit the server with CONTROL-C.
> 
>
>
> spark.wsgi file looks like the following.
>
> ===
>
>  import sys
> import site
> import os
>
> vepath = '/var/www/html/virtualenv/lib/python2.7/site-packages'
> prev_sys_path = list(sys.path)
> site.addsitedir(vepath)
> sys.path.append('/var/www/html/djangosites')
> new_sys_path = [p for p in sys.path if p not in prev_sys_path]
> for item in new_sys_path:
> sys.path.remove(item)
> sys.path[:0] = new_sys_path
> from django.core.handlers.wsgi import WSGIHandler
> os.environ['DJANGO_SETTINGS_MODULE'] = 'spark.settings'
> application = WSGIHandler()
>
> ==
>
> Entries for wsgi in apache conf looks like the following
>
> 
>
> [root@lampserver djangosites]# cat /etc/httpd/conf.d/django.conf 
>
>
> LoadModule wsgi_module modules/mod_wsgi.so
> AddHandler wsgi-script .wsgi
>
> WSGIScriptAlias / /var/www/html/djangosites/spark.wsgi
>
> WSGIDaemonProcess spark processes=5 threads=15 display-name=%{GROUP}
>
> WSGIProcessGroup spark
>
> WSGIApplicationGroup %{GLOBAL}
>
> WSGISocketPrefix /var/run/wsgi
>
> =
>
> Apache is running as user "apache".
>
> My project files and permissions are shown below.
>
> ===
> root@lampserver djangosites]# pwd
> var/www/html/djangosites
> [root@lampserver djangosites]# ls
> spark  spark.wsgi
> [root@lampserver djangosites]# ll
> total 8
> drwxr-xr-x 3 apache apache 4096 Nov 15 02:38 spark
> -rwxrwxrwx 1 apache apache  535 Nov 15 03:16 spark.wsgi
> [root@lampserver djangosites]# cd spark/
> manage.py  spark/ 
> [root@lampserver spark]# ll
> total 8
> -rwxr-xr-x 1 apache apache  248 Nov 15 02:38 manage.py
> drwxr-xr-x 2 apache apache 4096 Nov 15 03:05 spark
> [root@lampserver spark]# cd spark/
> [root@lampserver spark]# ll
> total 28
> -rw-r--r-- 1 apache apache0 Nov 15 02:38 __init__.py
> -rw-r--r-- 1 apache apache  136 Nov 15 02:40 __init__.pyc
> -rw-r--r-- 1 apache apache 1969 Nov 15 02:38 settings.py
> -rw-r--r-- 1 apache apache 2142 Nov 15 02:40 settings.pyc
> -rw-r--r-- 1 apache apache  296 Nov 15 02:38 urls.py
> -rw-r--r-- 1 apache apache  416 Nov 15 02:40 urls.pyc
> -rwxr-xr-x 1 apache apache  385 Nov 15 02:38 wsgi.py
> -rw-r--r-- 1 apache apache  589 Nov 15 02:40 wsgi.pyc
>
> ==
>
> Can anybody please identify the problem with my settings?
>
> Regards
>

-- 
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/c43a6390-ea45-4bea-99d6-74e2faae8064%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

mod_wsgi setup

[tino85]

Hello,

I am trying to setup a python 2.7 + Django + virtualenv + mod_wsgi 
environment in my centos 6.3 server to run my python application through 
apache.
But I am getting internal error while trying to access the application 
through apache. The error log shows the following.


[Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] mod_wsgi 
(pid=20361): Target WSGI script '/var/www/html/djangosites/spark.wsgi' 
cannot be loaded as Python module.
[Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] mod_wsgi 
(pid=20361): Exception occurred processing WSGI script 
'/var/www/html/djangosites/spark.wsgi'.
Fri Nov 15 04:20:30 2013] [error] [client 117.201.194.54] 
ImproperlyConfigured: Requested setting DEBUG, but settings are not 
configured. You must either define the environment variable 
DJANGO_SETTINGS_MODULE or call settings.configure() before accessing 
settings.



It is working fine when running as a test server.

==
(virtualenv)[root@lampserver spark]# python manage.py runserver 0.0.0.0:8080
Validating models...

0 errors found
November 15, 2013 - 09:15:19
Django version 1.6, using settings 'spark.settings'
Starting development server at http://0.0.0.0:8080/
Quit the server with CONTROL-C.



spark.wsgi file looks like the following.

===

 import sys
import site
import os

vepath = '/var/www/html/virtualenv/lib/python2.7/site-packages'
prev_sys_path = list(sys.path)
site.addsitedir(vepath)
sys.path.append('/var/www/html/djangosites')
new_sys_path = [p for p in sys.path if p not in prev_sys_path]
for item in new_sys_path:
sys.path.remove(item)
sys.path[:0] = new_sys_path
from django.core.handlers.wsgi import WSGIHandler
os.environ['DJANGO_SETTINGS_MODULE'] = 'spark.settings'
application = WSGIHandler()

==

Entries for wsgi in apache conf looks like the following



[root@lampserver djangosites]# cat /etc/httpd/conf.d/django.conf 


LoadModule wsgi_module modules/mod_wsgi.so
AddHandler wsgi-script .wsgi

WSGIScriptAlias / /var/www/html/djangosites/spark.wsgi

WSGIDaemonProcess spark processes=5 threads=15 display-name=%{GROUP}

WSGIProcessGroup spark

WSGIApplicationGroup %{GLOBAL}

WSGISocketPrefix /var/run/wsgi

=

Apache is running as user "apache".

My project files and permissions are shown below.

===
root@lampserver djangosites]# pwd
var/www/html/djangosites
[root@lampserver djangosites]# ls
spark  spark.wsgi
[root@lampserver djangosites]# ll
total 8
drwxr-xr-x 3 apache apache 4096 Nov 15 02:38 spark
-rwxrwxrwx 1 apache apache  535 Nov 15 03:16 spark.wsgi
[root@lampserver djangosites]# cd spark/
manage.py  spark/ 
[root@lampserver spark]# ll
total 8
-rwxr-xr-x 1 apache apache  248 Nov 15 02:38 manage.py
drwxr-xr-x 2 apache apache 4096 Nov 15 03:05 spark
[root@lampserver spark]# cd spark/
[root@lampserver spark]# ll
total 28
-rw-r--r-- 1 apache apache0 Nov 15 02:38 __init__.py
-rw-r--r-- 1 apache apache  136 Nov 15 02:40 __init__.pyc
-rw-r--r-- 1 apache apache 1969 Nov 15 02:38 settings.py
-rw-r--r-- 1 apache apache 2142 Nov 15 02:40 settings.pyc
-rw-r--r-- 1 apache apache  296 Nov 15 02:38 urls.py
-rw-r--r-- 1 apache apache  416 Nov 15 02:40 urls.pyc
-rwxr-xr-x 1 apache apache  385 Nov 15 02:38 wsgi.py
-rw-r--r-- 1 apache apache  589 Nov 15 02:40 wsgi.pyc

==

Can anybody please identify the problem with my settings?

Regards

-- 
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/12a25a2f-0f3b-4115-a27c-5781f9244ef4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to livereload Django templates?

[Nikolay Georgiev]

Hi Florian,

after trying to add livereload I came to the conclusion that it should be 
implemented in Django itself. I managed to add CSS livereload with Cross 
Browser CSS Injection: http://css-tricks.com/cross-browser-css-injection/, 
but HTML files cannot be reloaded without knowing how Django templating 
works. That's why I help is needed not from the user, but from the Django 
developers.

The easiest implementation would be: If a Django template (HTML) changes, 
refresh the browser.

How can this be implemented in Django itself?

Greetings,

Nikolay


On Tuesday, November 12, 2013 11:08:44 PM UTC+1, Florian Apolloner wrote:
>
> Hi Nikolay,
>
> this mailing lists is about the development of Django itself; you might 
> wanna ask that on django-users
>
> Regards,
> Florian
>
> On Monday, November 11, 2013 5:45:42 PM UTC+1, Nikolay Georgiev wrote:
>>
>> Do you know some tips or concrete steps on how to livereload Django 
>> templates?
>>
>> Livereloading means that if I change the HTML Template, CSS or JS files 
>> that these files will be automatically reloaded in the browser, without me 
>> having to refresh the page manually. This leads to increased productivity. 
>> http://livereload.com/
>>
>> Thank you very much!
>>
>> Nikolay
>>
>

-- 
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/9247f613-4bca-4c9b-a7cf-9c771e45bb97%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.