On Thu, Jul 8, 2010 at 8:39 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Jul 8, 2010 at 3:17 PM, DanEE <daniel.eg...@gmail.com> wrote: >> Hello >> >> I posted this already in django-user. But because it is rather an >> internal django/python problem I will repost it here >> >> I experienced a strange behaviour with my django application when I >> wanted to deploy and test on my apache instance on my virtual server. >> I could successfully deploy my application but when I wanted to access >> any view the browser just took forever to load and it never showed the >> view. Accessing any non existing view gave the correct debug error >> view. >> >> After a long debugging session I could locate the problem to be in >> django/middleware/csrf.py. The call which actually took a very long >> time was the call to randrange(0, _MAX_CSRF_KEY). >> >> By playing around in a python session it seems that the call to the >> system randrange with random.SystemRandom().randrange(0, >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 >> minutes) whereas a call to the "normal" randrange with randrange(0, >> _MAX_CSRF_KEY) happily returns the desired random number. >> The problem seems to depend on the size of the argument. >> random.SystemRandom().randrange happily returns the random values if >> the arguments are significantly lower. (I just deleted some number >> from the _MAX_CSRF_KEY and then it worked) >> >> I had to manully set the line "randrange = random.randrange" instead >> of the if/else logic which checks for the system random generator to >> make my app work on my virtual host. >> >> Now it seems that is not a django problem per se. But I am wondering >> what I should to with this kind of error as I had to manually fiddle >> around in the django-code to be able to successfully host my >> application. > > This is concerning, but I can't reproduce anything like it -- on every > platform I have available for testing, randrange() returns almost > instantaneously. > > If you call randrange from a normal python prompt, do you see the same > sort of delays? What about if you call randrange() in a simple Django > view? (i.e., start a new project with a simple view with no forms, and > call randrange() in that view?). Do you get similar lockups if you run > the CSRF tests in the Django test suite? > > If you can find the source of this problem, we will be only too happy > to fix it -- but until we can narrow down the specific set of > circumstances that causes the problem, there's not much we can do. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@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. > >
I'm unclear on why we even allow this code to work with the "default" random implementation, which is based on a Messrne Twister, and (quoting the Python docs here), "is completely unsuitable for cryptographic purposes". To my understand that's how we're trying to use it, and if I'm wrong here I wonder why we give preference to the system random at all? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
