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
You make a good point.
An obvious fix would seem to be to add the username to the cache key. This
way users cannot "use" another user's cache entry.
Cheers,
Erik
On Friday, 15 November 2013 11:41:43 UTC-8, Javier Guerra wrote:
>
> On Fri, Nov 15, 2013 at 2:27 PM, Marc Tamlyn
> >
> wrote:
>
On Tuesday, 19 November 2013 18:38:33 UTC-8, Wim Lewis wrote:
>
>
> On 19 Nov 2013, at 6:10 PM, Javier Guerra Giraldez wrote:
> > but still you get only SHA1-level strength, when the whole idea was to
> > switch to stronger crypto. if in your case SHA1 is enough, you can
> > simply keep using i
Django's django.core.urlresolvers.reverse() seems to have changed its
behavior in 1.6. It now runs the arguments through quote(), without
specifying the safe characters for path components. As a result:
on 1.4.10:
In [2]: reverse('test', args=['foo:bar'])
Out[2]: '/foo:bar'
but on 1.6.2:
In [2]
allowed unescaped in path segments.
> On 1 March 2014 17:26, Erik van Zijst wrote:
>> Django's django.core.urlresolvers.reverse() seems to have changed its
>> behavior in 1.6. It now runs the arguments through quote(), without
>> specifying the safe characters for pa
f that approach.
Cheers,
Erik
> The relevant django-developers discussion is here -
>
> https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ
>
> The final post addresses this issue, but doesn't seem to have been
>
On Wednesday, 5 March 2014 14:04:51 UTC-8, Erik van Zijst wrote:
>
> I'll follow up with a pull request, unless there are string feelings, or
> unwanted consequences of that approach.
>
https://github.com/django/django/pull/2401
Cheers,
Erik
>> The relevant django-d
