Re: password is None in check_password

[Łukasz Rekucki]

Hi,

I started working on a somehow related ticket #14390. Adrian suggested
to create a utils module, so I wanted to put there all useful
password-related functions: check_password(), make_password(),
is_password_usable() and the UNUSABLE_PASSWORD constant. So I'm
interested in API that this functions (and thus User's methods) should
provide.

On 7 October 2010 23:13, Laurent Luce  wrote:
> Hello,
>
> Regarding the issue about password is None in check_password (http://
> code.djangoproject.com/ticket/14354). I attached a patch with the
> following changes:
>
> - in set_password(), check for raw_password and if None or empty, call
> set_unusable_password(), otherwise same as before
In theory, someone could allow empty passwords which will get hashed properly.

>
> - in has_usable_password(), return True only if password is not None,
> not empty, or '!'
There are actually lot of other unusable values - at the moment,
anything that isn't a MD5 hash or a legitimate password string in
algo$salt$hash format. Is it ok, to only special case this three
values ?

>
> - because of the 2 changes above, we can simplify a bit create_user()
> by just calling set_password() for all cases. No need to test password
> inside this function anymore.
>
> - basic.py tests are now unittests and not doctests
Good work :)


-- 
Łukasz Rekucki

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

Re: Google Code-in: any volunteers?

[Steven Elliott Jr]

I'd be interested in helping out as well In any way I can. I'm a technical 
writer/editor by day so if there is a need for someone to oversee or assist 
with documentation I'd be delighted. Of course I'm willing to help out on 
anything. 

Best,
Steve

Sent from my iPhone

On Oct 7, 2010, at 4:15 PM, Marco Chomut  wrote:

> I'd definitely be up for helping out with this.
> 
> - Marco
> 
> On Oct 7, 3:36 pm, Shawn Davis  wrote:
>> I can participate if it's "several someones", but I'm afraid my schedule is 
>> too full to do it solo.
>> 
>> thanks,
>> Shawn
>> 
>> On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:
>> 
>> 
>> 
>>> Hi folks --
>> 
>>> Google's open source team is putting together a new program, called
>>> "Google Code-in". It's a program to get 13-18 years old students
>>> involved in open source by giving them sets of small, distinct tasks
>>> to work on. They did a similar program last year, called GHOP; Django
>>> didn't participate, but Python did.
>> 
>>> This might be a good way for us to get more younger developers
>>> involved, and we might be able to get some good work done --
>>> especially in the areas of documentation and testing.
>> 
>>> Though we didn't participate last year, Python did, and from what I
>>> hear it was successful, though a good deal of work. I don't have time
>>> myself to administer something like this this year, but I would love
>>> to see Django participate. Does anyone -- or several someones -- here
>>> think this sounds interesting enough to want to administer it from our
>>> end? I would be happy to help out in a supporting role, but there'd
>>> need to be someone else who's driving it.
>> 
>>> If you want to know more:
>> 
>>> http://google-opensource.blogspot.com/2010/10/google-code-in-schools-...
>>> http://code.google.com/opensource/gci/2010-11/faqs.html
>> 
>>> Thanks!
>> 
>>> Jacob
>> 
>>> --
>>> 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 
>>> 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-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.
> 

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

Re: Google Code-in: any volunteers?

[augdawg]

Great idea!

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

password is None in check_password

[Laurent Luce]

Hello,

Regarding the issue about password is None in check_password (http://
code.djangoproject.com/ticket/14354). I attached a patch with the
following changes:

- in set_password(), check for raw_password and if None or empty, call
set_unusable_password(), otherwise same as before

- in has_usable_password(), return True only if password is not None,
not empty, or '!'

- because of the 2 changes above, we can simplify a bit create_user()
by just calling set_password() for all cases. No need to test password
inside this function anymore.

- basic.py tests are now unittests and not doctests

I assumed that has_usable_password() will be called directly by the
user code so I didn't modify check_password().

Please let me know if my changes match what is expected.

Laurent
http://www.laurentluce.com
http://www.gourmious.com

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

Re: Google Code-in: any volunteers?

[Marco Chomut]

I'd definitely be up for helping out with this.

- Marco

On Oct 7, 3:36 pm, Shawn Davis  wrote:
> I can participate if it's "several someones", but I'm afraid my schedule is 
> too full to do it solo.
>
> thanks,
> Shawn
>
> On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:
>
>
>
> > Hi folks --
>
> > Google's open source team is putting together a new program, called
> > "Google Code-in". It's a program to get 13-18 years old students
> > involved in open source by giving them sets of small, distinct tasks
> > to work on. They did a similar program last year, called GHOP; Django
> > didn't participate, but Python did.
>
> > This might be a good way for us to get more younger developers
> > involved, and we might be able to get some good work done --
> > especially in the areas of documentation and testing.
>
> > Though we didn't participate last year, Python did, and from what I
> > hear it was successful, though a good deal of work. I don't have time
> > myself to administer something like this this year, but I would love
> > to see Django participate. Does anyone -- or several someones -- here
> > think this sounds interesting enough to want to administer it from our
> > end? I would be happy to help out in a supporting role, but there'd
> > need to be someone else who's driving it.
>
> > If you want to know more:
>
> >http://google-opensource.blogspot.com/2010/10/google-code-in-schools-...
> >http://code.google.com/opensource/gci/2010-11/faqs.html
>
> > Thanks!
>
> > Jacob
>
> > --
> > 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 
> > 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-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.

Re: Google Code-in: any volunteers?

[Shawn Davis]

I can participate if it's "several someones", but I'm afraid my schedule is too 
full to do it solo.

thanks,
Shawn

On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:

> Hi folks --
> 
> Google's open source team is putting together a new program, called
> "Google Code-in". It's a program to get 13-18 years old students
> involved in open source by giving them sets of small, distinct tasks
> to work on. They did a similar program last year, called GHOP; Django
> didn't participate, but Python did.
> 
> This might be a good way for us to get more younger developers
> involved, and we might be able to get some good work done --
> especially in the areas of documentation and testing.
> 
> Though we didn't participate last year, Python did, and from what I
> hear it was successful, though a good deal of work. I don't have time
> myself to administer something like this this year, but I would love
> to see Django participate. Does anyone -- or several someones -- here
> think this sounds interesting enough to want to administer it from our
> end? I would be happy to help out in a supporting role, but there'd
> need to be someone else who's driving it.
> 
> If you want to know more:
> 
> http://google-opensource.blogspot.com/2010/10/google-code-in-schools-out-codes-in.html
> http://code.google.com/opensource/gci/2010-11/faqs.html
> 
> Thanks!
> 
> Jacob
> 
> -- 
> 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.
> 

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

Re: Google Code-in: any volunteers?

[Alex Gaynor]

On Thu, Oct 7, 2010 at 3:30 PM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> Google's open source team is putting together a new program, called
> "Google Code-in". It's a program to get 13-18 years old students
> involved in open source by giving them sets of small, distinct tasks
> to work on. They did a similar program last year, called GHOP; Django
> didn't participate, but Python did.
>
> This might be a good way for us to get more younger developers
> involved, and we might be able to get some good work done --
> especially in the areas of documentation and testing.
>
> Though we didn't participate last year, Python did, and from what I
> hear it was successful, though a good deal of work. I don't have time
> myself to administer something like this this year, but I would love
> to see Django participate. Does anyone -- or several someones -- here
> think this sounds interesting enough to want to administer it from our
> end? I would be happy to help out in a supporting role, but there'd
> need to be someone else who's driving it.
>
> If you want to know more:
>
> http://google-opensource.blogspot.com/2010/10/google-code-in-schools-out-codes-in.html
> http://code.google.com/opensource/gci/2010-11/faqs.html
>
> Thanks!
>
> Jacob
>
> --
> 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.
>
>

Jacob,

I'd love to help with mentoring or admin stuff on this.

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.

Re: AutoFields, legacy databases and non-standard sequence names.

[akaariai]

> Sorry, I should have been more clear.
>
> What I'm trying to do is solicit suggestions from django developers as
> to how I *can* move ticket #1946 forward. I can find a way to work
> around it in my own project, but it would be ideal to solve it on the
> Django side, for everybody.
>
> I mentioned there were three possible suggestions in the ticket
> discussion as to how to solve the problem.  If a Django developer can
> give me some guidance as to what approach seems to be the best long-term
> solution, I'm happy to try my hand at writing a patch that can hopefully
> be incorporated into the codebase.

Django doesn't expect the sequence name to be tablename_columname_seq,
at least not in trunk. The last_insert_id method in backends/
postgresql/operations.py uses select
currval(pg_get_serial_sequence(tablename, columname)).
pg_get_serial_sequence will return the correct sequence only if the
sequence is owned by the tablename, columname combination. If you
happen to have just one table per sequence, then issuing
ALTER SEQUENCE sequencename OWNED BY tablename.columname;
should fix the problem.

There is one more proposal in ticket #13295. The proposed solution
should allow using the same sequence for multiple tables, though
management of the manually defined sequence is a bit hard when trying
to build the schema and when resetting the sequence. Sorry if the
proposal is a bit hard to follow...

I don't know well enough how databases other than postgresql work, so
I don't know if the solution is valid for other databases.

 - Anssi

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

Re: django.contrib.comments is judging me

[Adrian Holovaty]

On Thu, Oct 7, 2010 at 9:42 AM, Jacob Kaplan-Moss  wrote:
> You know, I really don't think this is a big enough deal to bother
> being completely picky about the deprecation policy here. It's a silly
> setting that should have been removed pre-open-source when we did the
> whole Django/Ellington split.
>
> I'm +1 on Luke's idea: set it to the empty list in 1.3, then remove it
> entirely in 1.4.
>
> Yes, it doesn't exactly follow our normal process. No, I don't
> particularly care.

Thank you for the pragmatism, Jacob. It saved me from going on a
public rant about overly cautious backwards-compatibility policies.
Yes, it's a silly setting that should have been removed circa 2006.
Anybody with mission-critical systems relying on it deserves to be
branded with the profanities contained therein.

I've set it to an empty tuple in http://code.djangoproject.com/changeset/13996 .

As a next step, I'd like to remove PROFANITIES_LIST and
COMMENTS_ALLOW_PROFANITIES from global_settings.py entirely, moving
the default values directly into django.contrib.comments. (I.e., the
django.contrib.comments code will check for the existence of a
setting, use it if it exists, and fall back on hard-coded defaults
otherwise.)

Adrian

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

Re: django.contrib.comments is judging me

[Jacob Kaplan-Moss]

On Wed, Oct 6, 2010 at 10:30 PM, Russell Keith-Magee
 wrote:
> Strictly, it needs to be put on a deprecation path [...]

You know, I really don't think this is a big enough deal to bother
being completely picky about the deprecation policy here. It's a silly
setting that should have been removed pre-open-source when we did the
whole Django/Ellington split.

I'm +1 on Luke's idea: set it to the empty list in 1.3, then remove it
entirely in 1.4.

Yes, it doesn't exactly follow our normal process. No, I don't
particularly care.

Jacob

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

Re: django.contrib.comments is judging me

[Russell Keith-Magee]

On Thu, Oct 7, 2010 at 7:33 PM, Luke Plant  wrote:
> On Thu, 2010-10-07 at 18:50 +0800, Russell Keith-Magee wrote:
>
>> The set of people that will be affected here are are all opt-in --
>> they've had to set COMMENTS_ALLOW_PROFANITIES=True -- so I would have
>> assumed that some subset will be happy with the default
>> PROFANITIES_LIST as currently defined. The behavior in question is
>> pretty useless, but it is a known quantity; changing the default
>> behavior while we're also deprecating just sounds like a source of
>> confusion to me.
>
> ? AFAICS, the filter is on by default, so everyone who uses
> contrib.comments is affected unless they've opted *out* - resulting in
> the surprise shown by Owen at the beginning of this thread.
>
> If we don't change the default behaviour, it might be worth fixing the
> Scunthorpe problem [1] - it's a genuine bug in it's own right, and it
> can catch people who haven't enabled opted in to anything. Patch for
> that attached.

My apologies, you're right -- I had the logic reversed in my head. I'm
not having a good day.

Clearing the PROFANITIES_LIST could be considered a "fix" for
Scunthorpe, but it's a bit extreme given that it is the existing
behavior (and again, people *could* be relying on it). I'm inclined to
say that your improved regex approach is a better option for the short
term, along with deprecation for the long term.

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.

Re: django.contrib.comments is judging me

[Luke Plant]

On Thu, 2010-10-07 at 18:50 +0800, Russell Keith-Magee wrote:

> The set of people that will be affected here are are all opt-in --
> they've had to set COMMENTS_ALLOW_PROFANITIES=True -- so I would have
> assumed that some subset will be happy with the default
> PROFANITIES_LIST as currently defined. The behavior in question is
> pretty useless, but it is a known quantity; changing the default
> behavior while we're also deprecating just sounds like a source of
> confusion to me.

? AFAICS, the filter is on by default, so everyone who uses
contrib.comments is affected unless they've opted *out* - resulting in
the surprise shown by Owen at the beginning of this thread.

If we don't change the default behaviour, it might be worth fixing the
Scunthorpe problem [1] - it's a genuine bug in it's own right, and it
can catch people who haven't enabled opted in to anything. Patch for
that attached.

Luke

[1] http://code.djangoproject.com/ticket/8794
 
-- 
"Dysfunction: The only consistent feature of all of your 
dissatisfying relationships is you." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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

diff -r 1a1428431cca django/contrib/comments/forms.py
--- a/django/contrib/comments/forms.py	Wed Oct 06 22:56:52 2010 +
+++ b/django/contrib/comments/forms.py	Thu Oct 07 12:30:15 2010 +0100
@@ -1,3 +1,4 @@
+import re
 import time
 import datetime
 
@@ -168,7 +169,8 @@
 """
 comment = self.cleaned_data["comment"]
 if settings.COMMENTS_ALLOW_PROFANITIES == False:
-bad_words = [w for w in settings.PROFANITIES_LIST if w in comment.lower()]
+bad_words = [w for w in settings.PROFANITIES_LIST
+ if re.search(r'\b%s\b' % w, comment, flags=re.IGNORECASE)]
 if bad_words:
 plural = len(bad_words) > 1
 raise forms.ValidationError(ungettext(
diff -r 1a1428431cca tests/regressiontests/comment_tests/tests/comment_form_tests.py
--- a/tests/regressiontests/comment_tests/tests/comment_form_tests.py	Wed Oct 06 22:56:52 2010 +
+++ b/tests/regressiontests/comment_tests/tests/comment_form_tests.py	Thu Oct 07 12:30:15 2010 +0100
@@ -72,6 +72,10 @@
 f = CommentForm(a, data=dict(d, comment="What a rooster!"))
 self.failIf(f.is_valid())
 
+# Check for Scunthorpe problem
+f = CommentForm(a, data=dict(d, comment="What a brooster!"))
+self.failUnless(f.is_valid())
+
 # Now with COMMENTS_ALLOW_PROFANITIES on
 settings.COMMENTS_ALLOW_PROFANITIES = True
 f = CommentForm(a, data=dict(d, comment="What a rooster!"))

Re: django.contrib.comments is judging me

[Russell Keith-Magee]

On Thu, Oct 7, 2010 at 6:15 PM, Luke Plant  wrote:
> On Thu, 2010-10-07 at 11:30 +0800, Russell Keith-Magee wrote:
>
>> Strictly, it needs to be put on a deprecation path, because it *is*
>> documented, in ref/settings.txt. So the earliest we can truly remove
>> it is in 1.5, after a PendingDeprecationWarning in 1.3 and a full
>> Warning in 1.4.
>>
>> Along the way, we should also be removing COMMENTS_ALLOW_PROFANITIES,
>> since there isn't much point having one without t'other.
>
> Although we cannot remove it in 1.3, could we set the default value to
> an empty list? I imagine that people who are depending on its
> functionality will have set their own value in their settings.py, and
> they can easily do so if they haven't already.

The set of people that will be affected here are are all opt-in --
they've had to set COMMENTS_ALLOW_PROFANITIES=True -- so I would have
assumed that some subset will be happy with the default
PROFANITIES_LIST as currently defined. The behavior in question is
pretty useless, but it is a known quantity; changing the default
behavior while we're also deprecating just sounds like a source of
confusion to me.

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.

Re: Suspected bug: testing with multiple references to same database

[Shai Berger]

On Thursday 07 October 2010 07:31:49 Russell Keith-Magee wrote:
> 
> It certainly sounds to me like a legitimate bug (or group of bugs).
> 
It is now bug #14415.

Thanks,
Shai.

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

Re: django.contrib.comments is judging me

[Luke Plant]

On Thu, 2010-10-07 at 11:30 +0800, Russell Keith-Magee wrote:

> Strictly, it needs to be put on a deprecation path, because it *is*
> documented, in ref/settings.txt. So the earliest we can truly remove
> it is in 1.5, after a PendingDeprecationWarning in 1.3 and a full
> Warning in 1.4.
> 
> Along the way, we should also be removing COMMENTS_ALLOW_PROFANITIES,
> since there isn't much point having one without t'other.

Although we cannot remove it in 1.3, could we set the default value to
an empty list? I imagine that people who are depending on its
functionality will have set their own value in their settings.py, and
they can easily do so if they haven't already.

Luke

-- 
"Dysfunction: The only consistent feature of all of your 
dissatisfying relationships is you." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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