Re: Improved password hashing for 1.4

[Carl Meyer]

-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 this
> push is to include just enough functionality that we can improve this
> particular aspect of Django. 
[snip]
> I'm really excited that we finally have the momentum to bring this
> important change to Django!

Me too. The plan looks great to me.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5q+vgACgkQ8W4rlRKtE2dGKwCfXzm56E+whpY6Ns58l6HLrXlD
5CAAn3+UWmP+vtTyPIUFNARWiGcvR7hz
=Pwrt
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Improved password hashing for 1.4

[Paul McMillan]

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 Django. There's a lot of other great work that
could happen as part of a more general contrib.auth overhaul, but we
want to change as little as possible so we can get a patch out quickly
(in time for the 1.4 feature freeze).

The default password hashing algorithm will be changed to PBKDF2.
We'll include a pure python implementation, but preferably load faster
versions if available at the system level.

Password hashing will happen via pluggable backends that implement the
set_password() and check_password() methods on the current User model.
We're considering trying the generic backend module from armstrong for
this, with the idea that we can move our other adhoc backend
implementations to a unified generic module in the future.

We will include backends that implement all the existing hashing
schemes as well as an optional module for bcrypt that uses a system
library if available. We will work to provide a clean upgrade path for
users of django-bcrypt.

We will be extending the current system that allows users to upgrade
their password algorithms in place. We recognize that sysadmins may
change their mind about which algorithm they prefer (for example, if
PBKDF2 becomes more overhead than they like, or they decide to upgrade
from SHA1). We want people to be confident in trying the new hashing
algorithms, so we will provide a mechanism for choosing a preferred
hashing backend and converting passwords to that backend as they are
used.

We're looking at ways to mitigate the effects of DoS attacks against
the auth module due to the higher CPU usage for these new backends.
Suggestions on this topic are welcome, but will probably be
implemented as part of a separate commit.

I'm really excited that we finally have the momentum to bring this
important change to Django!

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Re: filter_horizontal back button issue under webkit

[Julien Phalip]

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
> widget's use with webkit browsers.  It causes data loss and incorrect
> data to be saved if the user isn't extremely careful.  Full details
> and steps to reproduce are in the ticket, however briefly the issue is
> if you save an object from a change form in the admin and then hit the
> back button the filter horizontal widget is populated with incorrect
> data.  Additionally simply navigating away from a change form and then
> hitting the back button results in the filter horizontal widget not
> being populated with data at all.  If the user saves after either of
> these cases, the incorrect data is saved to the database.
>
> This issue is severe enough that we've had to drop all filter
> horizontal widgets from our admin interface.


I concur that there is a serious data loss risk here. As a start, it would
be interesting to track down whether the root cause lives in Webkit itself
or in the admin's JS code. Any help investigating this would be appreciated.

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

[ANNOUNCE] Security releases issued

[James Bennett]

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:

https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Re: Proposal for a new templatetag definition syntax

[Wim Feijen]

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 = bar

and

def mytag(src, limit=1, offset=10, ??)

or:

class MyTag(Tag):
def __init__(self, limit=1, offset=10, ??):
self.limit = limit
self.offset = offset

   def render(self):
   """do some nasty stuff to limit and offset and return something."""

Just kick me if I am talking non-sense, that's ok.

Wim

On 10 sep, 02:29, Alex Gaynor  wrote:
> 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 towards template
> compilation: template tags define a ``render()`` method, which takes the
> current context (a stack of dictionaries) and perform some behavior which is
> opaque to the caller. This is a problem because one of the core objectives
> of
> the template compilation infrastructure is to store the template context in
> Python local variables, rather than in dictionaries. For all these reasons,
> several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> out a
> proposal that solves these problems, taking inspiration from the plethora of
> libraries that exist today.
>
> We ultimately created two possible solutions, one inspired primarily by
> django-classy-tags and django-templatetag-sugar, the other mostly inspired
> by
> django-ttags. We came to a fragile agreement on the first. We primarily
> evaluated two cases for these, one very simple, the other more complex, and
> compared the resulting implementations.
>
> The first case we considered was a templatetag which takes two, required,
> arguments. Invocation looks like ``{% mytag foo bar %}``.  The two
> definitions
> look like:
>
>     class MyTag(Tag):
>         args = [
>             Argument("foo"),
>             Argument("bar"),
>         ]
>
>     class MyTag(Tag):
>         foo = Argument()
>         bar = Argument()
>
> the second case we considered was a tag which has one required, positional,
> argument, and two optional, keyword arguments, which can occur in any order,
> followed by a final, optional keyword argument, meaning any of the following
> invocations are valid:
>
>     {% mytag src limit 1 offset 10 %}
>     {% mytag src limit 1 offset 10 with foo %}
>     {% mytag src limit 1 %}
>     {% mytag src offset 10 limit 1 %}
>     {% mytag src %}
>
> and the two implementations were:
>
>     class MyTag(Tag):
>         args = [
>             Argument("source"),
>             Unordered(
>                 NamedArgument("limit", required=False),
>                 NamedArgument("offset", required=False),
>             ),
>             NamedArgument("as", required=False, resolve=False)
>         ]
>
>     class MyTag(Tag):
>         source = Argument()
>         limit = NamedArgument(required=False)
>         offset = NamedArgument(required=False)
>         as_ = BasicArgument(required=False)
>
>         class Meta:
>             ordering = (
>                 ('source',),
>                 Unordered('limit', 'offset'),
>                 ('as_',)
>             )
>
> The general consensus was that the second implementation was *very* slightly
> preferable in the simple case, however it was significantly more complicated
> in
> the second case, and thus the first implementation was preferable overall.
>
> We notable did *not* discuss what the syntax for defining the output was, at
> this stage we were only concerned with the syntax definition. This is
> because
> the actual ``render()`` equivalent will be orthogonal to the parsing stage
> equivalent.
>
> For your consideration,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Wim Feijen]

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 that.
>
> Wim
>
> On 10 sep, 02:03, Paul McMillan  wrote:
>
>
>
>
>
>
>
> > > 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 forward-incompatible: meaning that current and
> > > future users will stumble on something counter-intuitive and be amazed
> > > that an inactive user can pass a login_required.
>
> > No. Django makes an incredibly strong promise about backwards
> > compatibility to its users. Security releases are the ONLY reason we
> > modify behavior in backwards incompatible fashions, and we try very
> > hard to avoid that.
>
> > > For me, the current behaviour is contrary to most peoples expectation,
> > > and my proposal would be to make the backwards-incompatible change to
> > > make django more consistent (I might even say: more logical), which I
> > > think is a good thing.
>
> > Yeah, I agree that the current behavior is counter intuitive. It is an
> > oddity and a wart that exists.
>
> > > My proposal is also to add an active_or_inactive_login_required
> > > decorator (a better name is welcome) which just checks whether a user
> > > is authenticated; and then people could import that as login_required.
>
> > I wouldn't be opposed to an additional decorator which makes better
> > grammatical sense and does explicitly what you want. We just can't
> > change the behavior of the current one. If you can come up with two
> > new ones that make better sense there might be an argument for slowly
> > deprecating the existing one.
>
> > > The consequence is that some people would need to make a change to
> > > keep their code working in Django 1.4 , but it is my belief that this
> > > is only a small part of the Django population who have the skills to
> > > adapt and that it will have a benificial effect to most current and
> > > all future users.
>
> > No. We do not do this. Otherwise every release would end up stuffed
> > full of dozens of "tiny easy changes" which means nobody would bother
> > updating.
>
> > Regards,
> > -Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Proposal for a new templatetag definition syntax

[Alex Gaynor]

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 towards template
compilation: template tags define a ``render()`` method, which takes the
current context (a stack of dictionaries) and perform some behavior which is
opaque to the caller. This is a problem because one of the core objectives
of
the template compilation infrastructure is to store the template context in
Python local variables, rather than in dictionaries. For all these reasons,
several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
out a
proposal that solves these problems, taking inspiration from the plethora of
libraries that exist today.

We ultimately created two possible solutions, one inspired primarily by
django-classy-tags and django-templatetag-sugar, the other mostly inspired
by
django-ttags. We came to a fragile agreement on the first. We primarily
evaluated two cases for these, one very simple, the other more complex, and
compared the resulting implementations.

The first case we considered was a templatetag which takes two, required,
arguments. Invocation looks like ``{% mytag foo bar %}``.  The two
definitions
look like:

class MyTag(Tag):
args = [
Argument("foo"),
Argument("bar"),
]


class MyTag(Tag):
foo = Argument()
bar = Argument()


the second case we considered was a tag which has one required, positional,
argument, and two optional, keyword arguments, which can occur in any order,
followed by a final, optional keyword argument, meaning any of the following
invocations are valid:

{% mytag src limit 1 offset 10 %}
{% mytag src limit 1 offset 10 with foo %}
{% mytag src limit 1 %}
{% mytag src offset 10 limit 1 %}
{% mytag src %}

and the two implementations were:

class MyTag(Tag):
args = [
Argument("source"),
Unordered(
NamedArgument("limit", required=False),
NamedArgument("offset", required=False),
),
NamedArgument("as", required=False, resolve=False)
]


class MyTag(Tag):
source = Argument()
limit = NamedArgument(required=False)
offset = NamedArgument(required=False)
as_ = BasicArgument(required=False)

class Meta:
ordering = (
('source',),
Unordered('limit', 'offset'),
('as_',)
)

The general consensus was that the second implementation was *very* slightly
preferable in the simple case, however it was significantly more complicated
in
the second case, and thus the first implementation was preferable overall.

We notable did *not* discuss what the syntax for defining the output was, at
this stage we were only concerned with the syntax definition. This is
because
the actual ``render()`` equivalent will be orthogonal to the parsing stage
equivalent.

For your consideration,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Paul McMillan]

> 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 forward-incompatible: meaning that current and
> future users will stumble on something counter-intuitive and be amazed
> that an inactive user can pass a login_required.

No. Django makes an incredibly strong promise about backwards
compatibility to its users. Security releases are the ONLY reason we
modify behavior in backwards incompatible fashions, and we try very
hard to avoid that.

> For me, the current behaviour is contrary to most peoples expectation,
> and my proposal would be to make the backwards-incompatible change to
> make django more consistent (I might even say: more logical), which I
> think is a good thing.

Yeah, I agree that the current behavior is counter intuitive. It is an
oddity and a wart that exists.

> My proposal is also to add an active_or_inactive_login_required
> decorator (a better name is welcome) which just checks whether a user
> is authenticated; and then people could import that as login_required.

I wouldn't be opposed to an additional decorator which makes better
grammatical sense and does explicitly what you want. We just can't
change the behavior of the current one. If you can come up with two
new ones that make better sense there might be an argument for slowly
deprecating the existing one.

> The consequence is that some people would need to make a change to
> keep their code working in Django 1.4 , but it is my belief that this
> is only a small part of the Django population who have the skills to
> adapt and that it will have a benificial effect to most current and
> all future users.

No. We do not do this. Otherwise every release would end up stuffed
full of dozens of "tiny easy changes" which means nobody would bother
updating.

Regards,
-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Paul McMillan]

> 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 cookie-based session backends. I'd
probably be opposed to a behavior like that which worked with some
backends and not others (though that backend is a weird special case).

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Tobias]

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 artificially "castrated" to make function
> > views look good :-) That's probably not the intention, but...
>
> Ehm, the current classes based views are pretty good, apart from the
> view-not-in-context problem that I see.
>
> That's the one point on which I find those CBV's to be somewhat powerless.
>
> Upon re-reading it sounded a bit like I think the whole of class based
> views is powerless and bad, but that was *totally* not my intention :-)
> I love 'em :-)

This is probably an overly simplistic implementation, but would
something like this work, more broadly covering Jacob's concerns in
the ticket about template authors being able to shoot themselves in
the foot?  It seems less effective to mark all required methods with
alters_data, as this method also wouldn't prevent get(), post(), etc.
from being called in subclassed views (which could potentially
generate recursive loops).

https://github.com/tobiasmcnulty/django/compare/master...ticket-16744

On a side note, I noticed that get_context_data in TemplateView
behaves differently than all the others, as it puts kwargs in a
'params' variable instead of copying the kwargs directly into the
context.  Is this intentional?  I'm not super-familiar with class
based generic views, but it seemed odd to me.

Cheers,
Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Anssi Kääriäinen]

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.

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.

Just an idea maybe worth discussing.

 - Anssi

On Sep 10, 12:03 am, Wim Feijen  wrote:
> 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 current and
> future users will stumble on something counter-intuitive and be amazed
> that an inactive user can pass a login_required.
>
> For me, the current behaviour is contrary to most peoples expectation,
> and my proposal would be to make the backwards-incompatible change to
> make django more consistent (I might even say: more logical), which I
> think is a good thing.
>
> My proposal is also to add an active_or_inactive_login_required
> decorator (a better name is welcome) which just checks whether a user
> is authenticated; and then people could import that as login_required.
>
> The consequence is that some people would need to make a change to
> keep their code working in Django 1.4 , but it is my belief that this
> is only a small part of the Django population who have the skills to
> adapt and that it will have a benificial effect to most current and
> all future users.
>
> Sorry that I raise this question again, but it is my strongest belief
> that it will make Django better.
>
> Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Justin Lilly]

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 respond to any feedback, as I think this is a worthwhile
change.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Wim Feijen]

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 click on a link in their mailbox.
> That is the behavior is "defined" by django-registration.
>
> -- Gert
>
> Mobile: +32 498725202
> Twitter: @gvangool
> Web:http://gertvangool.be
>
>
>
>
>
>
>
> On Fri, Sep 9, 2011 at 07:24, subs...@gmail.com  wrote:
> > Could anyone provide a use case where I want a de-activated user to
> > remain authenticated? Who is this option for? Why is it default?
>
> > When I originally reported this ticket I did so because this is a
> > plain security risk--non-technical users uncheck 'is active' when they
> > want to lock someone out of access. They don't realize that the
> > session remains active and I believe this to be an oversight within
> > the original design, not a design preference.
>
> > On Sep 8, 2:11 am, Vladimir Kryachko  wrote:
> >> I think it has been done on purpose, and should not be changed.
> >> Because different authentication backends may choose to support
> >> inactive users or not. And the default (ModelBackend) supports
> >> inactive users which is expressed in
> >> ModelBackend.supports_inactive_user = True. So I would suggest you
> >> write a custom decorator.
>
> >> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen  wrote:
> >> > I'd like to draw attention to an open ticket which needs a design
> >> > decision.
>
> >> > Description:
> >> > "The login_required decorator is not checking User.is_active, as
> >> > staff_member_required does. If an authenticated user is deactivated
> >> > (via setting is_active to False), the user is still able to browse
> >> > login_required-protected views."
>
> >> > For probably most people, the expected and (most likely) wanted
> >> > behavior would be not to let inactive users have access to
> >> > login_required files.
>
> >> > Wim
>
> >> > --
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Django developers" group.
> >> > To post to this group, send email to django-developers@googlegroups.com.
> >> > To unsubscribe from this group, send email to 
> >> > django-developers+unsubscr...@googlegroups.com.
> >> > For more options, visit this group 
> >> > athttp://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Wim Feijen]

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 current and
future users will stumble on something counter-intuitive and be amazed
that an inactive user can pass a login_required.

For me, the current behaviour is contrary to most peoples expectation,
and my proposal would be to make the backwards-incompatible change to
make django more consistent (I might even say: more logical), which I
think is a good thing.

My proposal is also to add an active_or_inactive_login_required
decorator (a better name is welcome) which just checks whether a user
is authenticated; and then people could import that as login_required.

The consequence is that some people would need to make a change to
keep their code working in Django 1.4 , but it is my belief that this
is only a small part of the Django population who have the skills to
adapt and that it will have a benificial effect to most current and
all future users.

Sorry that I raise this question again, but it is my strongest belief
that it will make Django better.

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

filter_horizontal back button issue under webkit

[John]

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 saved if the user isn't extremely careful.  Full details
and steps to reproduce are in the ticket, however briefly the issue is
if you save an object from a change form in the admin and then hit the
back button the filter horizontal widget is populated with incorrect
data.  Additionally simply navigating away from a change form and then
hitting the back button results in the filter horizontal widget not
being populated with data at all.  If the user saves after either of
these cases, the incorrect data is saved to the database.

This issue is severe enough that we've had to drop all filter
horizontal widgets from our admin interface.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Alec Taylor]

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:
>>
>> 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; it
>> would be more appropriate on django-users.
>>
>> Note that deploying a Django project is a bit more complicated than a PHP
>> project (just throw the files in WWW_ROOT). IMO setting up the database
>> isn't the most difficult step. I don't know any projects that provide this
>> feature.
>
>
> For PyLucid CMS i created a "standalone package" with a Web-GUI
> installation. You need not shell to install it.
>
> Here some screenshots:
>
> http://www.pylucid.org/permalink/340/pylucid-screenshots/PyLucid-standalone/
>
> The Web-GUI install is a simple CGI script for running syncdb, south migrate
> and create a first superuser etc.
>
> The script is here:
> 
>
>
> The install procedure is really simple:
>        * Upload all files via FTP to webserver
>        * request http://www.my_server.tld/install_pylucid.cgi
>        * run "syncdb", "migrate", "create superuser", "loaddata"
>
> Complete instruction here:
> http://www.pylucid.org/permalink/331/1b-install-pylucid-standalone-package
>
>
>
> But the prefered way to install PyLucid is a bootscript which creates a
> virtualenv:
> 
>
>
> --
>
> Mfg.
>
> Jens Diemer
>
>
> 
> http://www.jensdiemer.de
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Cal Leeming [Simplicity Media Ltd]]

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. :/

Cal

On Fri, Sep 9, 2011 at 3:24 PM, Roberto De Ioris  wrote:

>
> 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 uwsgi).
>
> Not related to your specific question, but remember that uWSGI can natively
> speaks fastcgi (both in static and dynamic way)
>
> static config:
> uwsgi --fastcgi-socket  ...
>
> dynamic (apache passing the socket as fd 0)
> uwsgi --protocol=fastcgi ...
>
>
> --
> Roberto De Ioris
> http://unbit.it
> JID: robe...@jabber.unbit.it
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Roberto De Ioris]

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 uwsgi).

Not related to your specific question, but remember that uWSGI can natively 
speaks fastcgi (both in static and dynamic way)

static config:
uwsgi --fastcgi-socket  ...

dynamic (apache passing the socket as fd 0)
uwsgi --protocol=fastcgi ...


--
Roberto De Ioris
http://unbit.it
JID: robe...@jabber.unbit.it

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

runfcgi umask unusable without daemonize=false.. why?

[Cal Leeming [Simplicity Media Ltd]]

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 (www-data) is unable to write to the socket.

Same discussion here:
http://stackoverflow.com/questions/3431029/socket-permissions-when-running-django-with-fastcgi

Cal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Gert Van Gool]

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
Web: http://gertvangool.be



On Fri, Sep 9, 2011 at 07:24, subs...@gmail.com  wrote:
> Could anyone provide a use case where I want a de-activated user to
> remain authenticated? Who is this option for? Why is it default?
>
> When I originally reported this ticket I did so because this is a
> plain security risk--non-technical users uncheck 'is active' when they
> want to lock someone out of access. They don't realize that the
> session remains active and I believe this to be an oversight within
> the original design, not a design preference.
>
> On Sep 8, 2:11 am, Vladimir Kryachko  wrote:
>> I think it has been done on purpose, and should not be changed.
>> Because different authentication backends may choose to support
>> inactive users or not. And the default (ModelBackend) supports
>> inactive users which is expressed in
>> ModelBackend.supports_inactive_user = True. So I would suggest you
>> write a custom decorator.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen  wrote:
>> > I'd like to draw attention to an open ticket which needs a design
>> > decision.
>>
>> > Description:
>> > "The login_required decorator is not checking User.is_active, as
>> > staff_member_required does. If an authenticated user is deactivated
>> > (via setting is_active to False), the user is still able to browse
>> > login_required-protected views."
>>
>> > For probably most people, the expected and (most likely) wanted
>> > behavior would be not to let inactive users have access to
>> > login_required files.
>>
>> > Wim
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Django developers" group.
>> > To post to this group, send email to django-developers@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

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

[Jens Diemer]

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; it would be 
more appropriate on django-users.

Note that deploying a Django project is a bit more complicated than a PHP 
project (just throw the files in WWW_ROOT). IMO setting up the database isn't 
the most difficult step. I don't know any projects that provide this feature.



For PyLucid CMS i created a "standalone package" with a Web-GUI installation. 
You need not shell to install it.


Here some screenshots:

http://www.pylucid.org/permalink/340/pylucid-screenshots/PyLucid-standalone/

The Web-GUI install is a simple CGI script for running syncdb, south migrate and 
create a first superuser etc.


The script is here:



The install procedure is really simple:
* Upload all files via FTP to webserver
* request http://www.my_server.tld/install_pylucid.cgi
* run "syncdb", "migrate", "create superuser", "loaddata"

Complete instruction here:
http://www.pylucid.org/permalink/331/1b-install-pylucid-standalone-package



But the prefered way to install PyLucid is a bootscript which creates a 
virtualenv:



--

Mfg.

Jens Diemer



http://www.jensdiemer.de

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@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.