Re: Improved password hashing for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2011 09:54 PM, Paul McMillan wrote: > In conjunction with Justine Tunney, Isaac Kelly and Russell KM, I'd > like to introduce our plan of attack for including significantly > better password hashing in Django 1.4. One of the key goals with

Improved password hashing for 1.4

In conjunction with Justine Tunney, Isaac Kelly and Russell KM, I'd like to introduce our plan of attack for including significantly better password hashing in Django 1.4. One of the key goals with this push is to include just enough functionality that we can improve this particular aspect of

Re: filter_horizontal back button issue under webkit

Hi John, On 9 September 2011 11:28, John wrote: > Hi All, > > This is in regards to ticket #13614 (Back button breaks many to many > widget). I'm hoping that bringing this up might bring some attention > to it. This is a rather nasty bug affecting the filter horizontal

[ANNOUNCE] Security releases issued

Today we've released Django 1.3.1 and Django 1.2.6 to deal with several security issues reported to us. Details of these issues and the releases, along with several important advisory notes, are available in the blog post on djangoproject.com:

Re: Proposal for a new templatetag definition syntax

Hi Alex, Probably I am thinking way too simple, but if you gave me a free choice of how to write templatetags in my code, I would prefer: def mytag(foo, bar): # some code return output or: class MyTag(Tag): def __init__(self, foo, bar): self.foo = foo self.bar =

Re: plea for re-opening ticket 13125 marked as won't fix

I added an active_login_required decorator. See: https://code.djangoproject.com/ticket/16797 Is it a good name? It is a good patch? Or is it stupid? Thanks, Wim On 10 sep, 02:27, Wim Feijen wrote: > Thanks Paul, > > I like the idea of the additional decorator! Let's do

Proposal for a new templatetag definition syntax

Hello all, For many years, writing templatetags has been among the most hilariously complicated things we Django developers did. Anyone who has written parsing for templatetags, over and over, shares this pain. Further, the current syntax present a tremendous problem for Armin Ronacher's GSOC

Re: plea for re-opening ticket 13125 marked as won't fix

> I'd like to make a case to re-open ticket 13125. Thanks for taking this to the mailing list rather than arguing in trac. > I understand that changing the current behaviour is backwards- > incompatible and therefor very unwanted. But, I'd say the current > implementation is

Re: plea for re-opening ticket 13125 marked as won't fix

> There are numerous counter arguments to the idea: Unintended > consequences. There is a possibility for race conditions, which would > then be security issues. Action at distance. I don't know if this is > possible to implement for all session backends. It's impossible to implement for

Re: class based views: object instead of dictionary as context?

On Sep 4, 12:44 pm, Reinout van Rees wrote: > On 04-09-11 21:28, Reinout van Rees wrote: > > > On the other hand, from an object oriented viewpoint, the class based > > views seem to be pretty powerless and non-object-oriented. To me, it > > almost seems like they're

Re: plea for re-opening ticket 13125 marked as won't fix

One approach would be to invalidate the sessions of the user when is_active is changed from True to False. This way the current registration method would work, and there would not be surprising "can use site as long as session is open" situations, because there would not be any open sessions.

#7198 - Better error message when app is missing models.py

Not sure why this particular ticket is marked as DDN, as it seems like a no-brainer. The patch provides a more clear error message when a user is attempting to load an app which doesn't have a models.py. https://code.djangoproject.com/ticket/7198 https://github.com/django/django/pull/39 Happy to

Re: ticket 13125 is waiting for a design decision for 18 months

Gert, do you want an inactive user to be able to see login_required views? On 9 sep, 12:19, Gert Van Gool wrote: > Well, we - and I imagine many others - are actively using this behavior. > So our use-case is simple: a user registers, the user remains inactive > until they

plea for re-opening ticket 13125 marked as won't fix

Jakob, thanks for looking into 13125 and taking action on it. I'd like to make a case to re-open ticket 13125. I understand that changing the current behaviour is backwards- incompatible and therefor very unwanted. But, I'd say the current implementation is forward-incompatible: meaning that

filter_horizontal back button issue under webkit

Hi All, This is in regards to ticket #13614 (Back button breaks many to many widget). I'm hoping that bringing this up might bring some attention to it. This is a rather nasty bug affecting the filter horizontal widget's use with webkit browsers. It causes data loss and incorrect data to be

Re: PHP-inspired user-friendly in-browser DJango install

Looks useable. Anyone interested in working with me to port this to DJango? (the reason I'm not doing it myself is that I am very new to Python and DJango) On Fri, Sep 9, 2011 at 5:38 PM, Jens Diemer wrote: > Am 09.09.2011 08:23, schrieb Aymeric Augustin: >> >>

Re: runfcgi umask unusable without daemonize=false.. why?

Hey Roberto, Yeah I wanted to use uWSGI for this client, but the fastcgi.py file had been originally monkey patched to integrate with the client application (yeah, a total pain in the ass), which meant we *had* to use the manage.py runfcgi stuff - otherwise it meant re-writing a chunk of stuff.

Re: runfcgi umask unusable without daemonize=false.. why?

Il giorno 09/set/2011, alle ore 16:05, Cal Leeming [Simplicity Media Ltd] ha scritto: > Hi, > > Is there any reason why umask is unusable without daemonize=false? > > This means I can't manage processes within supervisorctl (when having to use > fastcgi due to client not being able to have

runfcgi umask unusable without daemonize=false.. why?

Hi, Is there any reason why umask is unusable without daemonize=false? This means I can't manage processes within supervisorctl (when having to use fastcgi due to client not being able to have uwsgi). For example: srwxr-xr-x 1 tt tt 0 Sep 9 15:00 fastcgi That means that nginx

Re: ticket 13125 is waiting for a design decision for 18 months

Well, we - and I imagine many others - are actively using this behavior. So our use-case is simple: a user registers, the user remains inactive until they click on a link in their mailbox. That is the behavior is "defined" by django-registration. -- Gert Mobile: +32 498725202 Twitter: @gvangool

Re: PHP-inspired user-friendly in-browser DJango install

Am 09.09.2011 08:23, schrieb Aymeric Augustin: Nothing prevents you from altering the settings file dynamically and telling the user to restart the webserver. You can run wih an in-memory SQLite database until this is done. So your question isn't related to the development of Django itself;