Re: Feature: Template Components

This sounds a bit like combining django-sniplates with django-amn, and going a bit further... Fragments of templates, list of JS/CSS dependencies, and a way to collect it all together and ensure your page has everything you need... Sounds interesting to me... I'd be happy to collaborate on it

Re: Introducing django-compat - arteria's solution for for- and backwards compatibility from Django 1.4.x to 1.8.x/1.9.x

Carl proposed a similar thing: https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ It would be a bit better than he outlined there with an LTS every 2 years instead of 3 as I proposed. It seems difficult to estimate how much such a policy would increase maintenance costs

Re: Introducing django-compat - arteria's solution for for- and backwards compatibility from Django 1.4.x to 1.8.x/1.9.x

Thanks Philippe for bringing this up. I'm currently upgrading a large Django app with dozens of dependencies from 1.4 to 1.8, here are some observations: - Most popular and/or maintained libraries actually supports every Django version between 1.4 to 1.8. (Many thanks to their maintainers!) -

Re: Form assets and static file storage

Hi Dom, Yeah, it looks like the admin_static is simply uses the staticfiles tag if staticfiles is installed, otherwise falls back to the core static? The only reason why it admin_static exists is because the admin can't rely on staticfiles being installed, right? Maybe pulling the the

Form assets and static file storage

I recently came across a problem when using ManifestStaticFilesStorage on an app with form media, which the documentation doesn't seem to address. I'm posting here rather that on django-users, since I think we ought to at least document how to fix it, or preferably come up with a better way of

Re: Feature: Template Components

On Tuesday, 9 June 2015 13:21:27 UTC+2, Yoong Kang Lim wrote: > > This seems like a huge change. If you were to include this feature in > Django, would it be straightforward for users to migrate from previous > versions? > What I'm suggesting is not a huge change. I'm just saying that Django

Re: Feature: Template Components

Speaking only for myself and the component framework we built here, I don't think I would expect it to ever be rolled into Django itself. However, the framework we made does work without any modifications to Django and works just fine alongside existing function and classed based views. This

Re: Using `SECRET_KEY` in password hashers

Hello, 2015-06-09 16:16 GMT+02:00 Josh Smeaton : > You're referring to a "pepper" - a site wide secret that's supposed to be > used, in some way, to further encrypt passwords. As far as I'm aware there > are no algorithms available that take a pepper into consideration. >

Re: Using `SECRET_KEY` in password hashers

You're referring to a "pepper" - a site wide secret that's supposed to be used, in some way, to further encrypt passwords. As far as I'm aware there are no algorithms available that take a pepper into consideration. Further, I don't see the need for the inclusion of a pepper if the password

Re: Feature: Template Components

This seems like a huge change. If you were to include this feature in Django, would it be straightforward for users to migrate from previous versions? On Sunday, May 31, 2015 at 2:52:37 AM UTC+10, Emil Stenström wrote: > > Hi, > > This is the first feature proposal as part of my general

Re: Using `SECRET_KEY` in password hashers

FWIW the idea is relatively old and I think mozilla has a 3rd party app which just adds that functionality to the hashers. As far as I remember it even allows having multiple secrets and as such migrate to a new key. On Tuesday, June 9, 2015 at 7:16:02 AM UTC+2, Ram Rachum wrote: > > Hi, > >

Re: Using `SECRET_KEY` in password hashers

On Tue, Jun 9, 2015 at 9:56 AM, Curtis Maloney wrote: > So, the benefit of your case is it's one more step for an attacker if they > want to brute-force your password database -- that they _also_ need to > steal your PASSWORD_SECRET. > > The downside is, in the very

Re: Using `SECRET_KEY` in password hashers

So, the benefit of your case is it's one more step for an attacker if they want to brute-force your password database -- that they _also_ need to steal your PASSWORD_SECRET. The downside is, in the very case where they _do_ steal it, you must immediately invalidate every password by changing your

Re: Using `SECRET_KEY` in password hashers

If the leak happened because someone got into your code repo, you're right. (I can't rule out a scenario where someone got your SECRET_KEY with some other method, like analyzing data that was generated with the secret key.) But even if there's a leak, then you're in a situation not worse than