Re: Should user passwords be more strict?

[Paul McMillan]

I'm happy you're concerned about this, but suggest you search the
archives for similar material so that new threads can contribute new
content.

This search is probably a fantastic starting point for your reading pleasure:
http://groups.google.com/group/django-developers/search?group=django-developers=password+policy_g=Search+this+group

Regards,
-Paul

On Tue, Sep 13, 2011 at 3:52 PM, Wim Feijen  wrote:
> Having just finished a discussion on security, I'd like to raise a
> concern of mine.
>
> By default, users can have a one-character password.
>
> When their accounts get hacked, we suffer the consequences as well.
>
> Should we be more strict in that?
>
> 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.
>
>

-- 
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: #7198 - Better error message when app is missing models.py

[Russell Keith-Magee]

On Tue, Sep 13, 2011 at 4:41 PM, Jannis Leidel  wrote:
> On 12.09.2011, at 22:44, Carl Meyer wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi Gary,
>>
>> On 09/12/2011 12:04 AM, Gary Wilson Jr. wrote:
>>> I'm a fan of not requiring a models.py, as IMHO it shouldn't be any
>>> different than other common files found in an app e.g. urls.py,
>>> templatetags dir, etc.  If I don't need any models for my app, then
>>> why must I still have a models.py?  That said, it also seems there
>>> could be some backwards incompatibilities if code or external tools
>>> rely on a valid app including a models.py file.
>>
>> Actually, I think there's generally consensus that requiring models.py
>> is not ideal. There's already an existing GSoC branch (app-loading),
>> which already fixes the models.py issue (AFAIK) but is somewhat
>> languishing for lack of attention. So I think the best path towards
>> getting that fixed is to check out that branch and help get it in
>> merge-ready shape. Jannis was the mentor for that GSoC, he or Arthur
>> Koziel (the student) can probably comment most knowledgeably about what
>> needs to be done.
>
>
> Right now this needs a thorough code review to decide how to go forward. There
> are several open questions, e.g. how to get the general (non-app-loading) test
> suite integrated with the changes of the app loading. The main problem there
> is that runtests.py has a hardwired assumption about how the app cache works,
> basically a chicken-egg problem. That said, the app-loading changes itself is
> well tested separately as pure-Python unit tests [1].
>
> Some people have started to review but never got back to me, which -- and I
> hate to write that since Arthur and me spent so much time on it -- makes me
> wonder if we ever get close enough to merging this. I'm convinced it's really
> useful, but as it's such a core part of Django it also definitely needs more
> than two sets of eyes. Was there any interest at DjangoCon US?

Yes - there was a huge amount of interest; especially, given that it
provides a way to solve the "app startup" problem, and provides the
starting point for addressing the custom User model problem.

As one of the people who has let you down on reviews -- I apologize. I
was hoping to get a chance to look at this at DjangoCon, but I didn't
get the time. Now I'm back in the office, I'm being slowly swallowed
by work. I'd like to be able to commit to doing a review in the near
future, but being realistic, that isn't going to happen any time soon.

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

Should user passwords be more strict?

[Wim Feijen]

Having just finished a discussion on security, I'd like to raise a
concern of mine.

By default, users can have a one-character password.

When their accounts get hacked, we suffer the consequences as well.

Should we be more strict in that?

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.

Re: please reopen ticket 15567

[Wim Feijen]

Ladies and gentlemen,

Thanks for all the feedback, a patch is in ticket 16837:
https://code.djangoproject.com/ticket/16837

Feel free to try and review the patch.

Best regards and for now, good night.

Wim

On 13 sep, 23:42, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I agree 100% with what Russ had to say on the ticket: leaking
> information about admin accounts isn't OK, and we won't change that.
>
> If someone would like to submit a patch with different wording that
> covers all cases -- "this is an invalid user/password for admin
> access" or somesuch -- that's fine. Please open a new ticket for it so
> we don't get confused though. But having one and only one error
> message here is by design.
>
> 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-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: please reopen ticket 15567

[Jacob Kaplan-Moss]

Hi folks --

I agree 100% with what Russ had to say on the ticket: leaking
information about admin accounts isn't OK, and we won't change that.

If someone would like to submit a patch with different wording that
covers all cases -- "this is an invalid user/password for admin
access" or somesuch -- that's fine. Please open a new ticket for it so
we don't get confused though. But having one and only one error
message here is by design.

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-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: please reopen ticket 15567

[Ian Kelly]

On Tue, Sep 13, 2011 at 11:24 AM, Adam Jenkins  wrote:
> +1 on making the error say more than incorrect username/password. That
> is confusing. In regards to leaking information about the user. The
> error message in general could be changed to something like this, of
> course with better wording:
>
> "Username and password incorrect or access to this page restricted".
>
> The current status is that we are telling the user something this is
> incorrect. I've actually run into this situation before where I had a
> user reset their password a few times before coming to me.

+1 on this suggestion.  This has no security implications and is
clearly an improvement over the existing message.

-1 on the idea of having two separate messages.  It gives away
information, and regardless of whether that information is useful to
an attacker, we should not be trying to predict that.  We can't
envision all possible scenarios, so we should just assume that the
information *is* useful and avoid doing that.

-- 
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: please reopen ticket 15567

[silent1mezzo]

-1

If a person brute forces your site and finds the correct username /
password they could try this on other sites (gmail, banking, etc..)
While it would make it a little more clear I think the implications
are too big.

On Sep 13, 3:14 pm, Adam Jenkins  wrote:
> On Tue, Sep 13, 2011 at 12:42 PM, Wim Feijen  wrote:
> > Hi, thanks for your quick responses!
>
> > Flavio, Jan and Florian, it only "gives away information" when an
> > attacker guesses both the username and the password right.
>
> I think this is the correct approach. Give them the access warning on
> correct login. It also seems to be the standard way to doing such
> things in my experience.
>
>
>
> > But if he can guess those right, he could already access the users
> > information using the normal login! So giving this message does not
> > change the danger. On the other hand, it would prevent lots of
> > confusion.
>
> We really shouldn't be confusing the end user. It's just bad design to do so.
>
>
>
>
>
>
>
>
>
> > But we are repeating arguments here, so could you please read:
>
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > before responding?
>
> > Thanks!
>
> > Wim
>
> > On 13 sep, 19:23, Flávio Amieiro  wrote:
> >> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>
> >>  wrote:
> >> > +1, if the user/pass is entered, that user is entitled so know what its 
> >> > own
> >> > permissions are.
> >> > The error should give "You have insufficient access to this page" or
> >> > something like that.
>
> >> The thing is: if someone does a brute force attack on '/admin/' and
> >> gets this message back, they know there's a user with that
> >> login/password in the system. Since brute force attacks using common
> >> login/password pairs in this kinds of urls is so common, I think this
> >> exposes your user more than necessary.
>
> >> -1
>
> > --
> > 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.

Re: please reopen ticket 15567

[Babatunde Akinyanmi]

The correct approach is to give a "one size fits all" error message.
While security is important, so also is user experience.

On 9/13/11, Adam Jenkins  wrote:
> On Tue, Sep 13, 2011 at 12:42 PM, Wim Feijen  wrote:
>> Hi, thanks for your quick responses!
>>
>> Flavio, Jan and Florian, it only "gives away information" when an
>> attacker guesses both the username and the password right.
>
> I think this is the correct approach. Give them the access warning on
> correct login. It also seems to be the standard way to doing such
> things in my experience.
>
>>
>> But if he can guess those right, he could already access the users
>> information using the normal login! So giving this message does not
>> change the danger. On the other hand, it would prevent lots of
>> confusion.
>
> We really shouldn't be confusing the end user. It's just bad design to do
> so.
>
>>
>> But we are repeating arguments here, so could you please read:
>>
>> http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef
>>
>> before responding?
>>
>> Thanks!
>>
>> Wim
>>
>>
>> On 13 sep, 19:23, Flávio Amieiro  wrote:
>>> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>>>
>>>  wrote:
>>> > +1, if the user/pass is entered, that user is entitled so know what its
>>> > own
>>> > permissions are.
>>> > The error should give "You have insufficient access to this page" or
>>> > something like that.
>>>
>>> The thing is: if someone does a brute force attack on '/admin/' and
>>> gets this message back, they know there's a user with that
>>> login/password in the system. Since brute force attacks using common
>>> login/password pairs in this kinds of urls is so common, I think this
>>> exposes your user more than necessary.
>>>
>>> -1
>>
>> --
>> 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.
>
>

-- 
Sent from my mobile device

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

[Reinout van Rees]

On 13-09-11 20:33, Tobias McNulty wrote:

I love it when problems solve themselves :-)


That's a good point.  Are there *any* methods in the CBVs that don't
take arguments, that also modify data?  The only one that I found in the
list I'd initially proposed that can be called without arguments is
as_view(), and I'm not sure that really even needs protection.  Maybe
there's no need to protect anything with alters_data / proxying?


There's not really anything useful you can do with as_view in your 
template, should you attempt it. I also don't think you can do anything 
destructive with it.


So it sounds like we don't need the proxy. Good that you added it anyway 
as it helps us dig deeper into the problem :-) Luckily it seems we don't 
have to dig very deep.



Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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: please reopen ticket 15567

[Adam Jenkins]

On Tue, Sep 13, 2011 at 12:42 PM, Wim Feijen  wrote:
> Hi, thanks for your quick responses!
>
> Flavio, Jan and Florian, it only "gives away information" when an
> attacker guesses both the username and the password right.

I think this is the correct approach. Give them the access warning on
correct login. It also seems to be the standard way to doing such
things in my experience.

>
> But if he can guess those right, he could already access the users
> information using the normal login! So giving this message does not
> change the danger. On the other hand, it would prevent lots of
> confusion.

We really shouldn't be confusing the end user. It's just bad design to do so.

>
> But we are repeating arguments here, so could you please read:
>
> http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef
>
> before responding?
>
> Thanks!
>
> Wim
>
>
> On 13 sep, 19:23, Flávio Amieiro  wrote:
>> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>>
>>  wrote:
>> > +1, if the user/pass is entered, that user is entitled so know what its own
>> > permissions are.
>> > The error should give "You have insufficient access to this page" or
>> > something like that.
>>
>> The thing is: if someone does a brute force attack on '/admin/' and
>> gets this message back, they know there's a user with that
>> login/password in the system. Since brute force attacks using common
>> login/password pairs in this kinds of urls is so common, I think this
>> exposes your user more than necessary.
>>
>> -1
>
> --
> 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: please reopen ticket 15567

[Florian Apolloner]

Hmm, actually my text was supposed to go below the quotes, but apperently 
the new google interface is a bit buggy -- nevertheless I hope you still 
understand the point I am trying to make even without correct quoting order…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/GNQaTZ6QSB0J.
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: please reopen ticket 15567

[Paul Egges]

On Tue, Sep 13, 2011 at 12:27 PM, Anssi Kääriäinen
wrote:

> On Sep 13, 8:24 pm, Adam Jenkins  wrote:
> > +1 on making the error say more than incorrect username/password. That
> > is confusing. In regards to leaking information about the user. The
> > error message in general could be changed to something like this, of
> > course with better wording:
> >
> > "Username and password incorrect or access to this page restricted".
>
> +1. This solves the problem nicely. the login does not leak
> information and the error message is correct.
>

I'm also +1 on this solution. Although maybe "is" should be inserted before
the word restricted.

Paul


>
>  - 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-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: please reopen ticket 15567

[Florian Apolloner]

Hi,

On Tuesday, September 13, 2011 7:42:24 PM UTC+2, Wim Feijen wrote:
>
> Flavio, Jan and Florian, it only "gives away information" when an 
> attacker guesses both the username and the password right. 
>

No! Assume the admin view is the only login view in your project (since it 
only consists of the admin or whatever), then if the attacker guesses the 
correct username/password he knows that the user/password is valid (if we 
take your approach) and doesn't need to try other passwords since you told 
him he is no admin… Given the current state he never can make that 
assumptions and might try further with the same user.
 

> So giving this message does not 
> change the danger. On the other hand, it would prevent lots of 
> confusion. 
>

You assume that there is another login! Now you might say that my example is 
a bit obscure, but we do have some public sites with no admin which are 
managed by a dedicated admin instance (which has to be public [in the sense 
of reachable from everywhere] due to customer requests). So it does decrease 
security for us… I understand your point, but please don't assume that your 
proposed change can't leak information!

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/dWOzTQfFmgUJ.
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 McNulty]

On Mon, Sep 12, 2011 at 2:10 PM, Reinout van Rees wrote:

> On 12-09-11 18:25, Florian Apolloner wrote:
>
>> On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote:
>>
>>Addition: disallow attributes/methods starting with an underscore?
>>
>>That's a handy way to stow away dangerous methods should you have them
>>in your view.
>>
>> That's already the case for resolving variables in templates, I don't
>> think we need any specialcasing here.
>>
>> > The only way I can see yourself shooting in the foot is
>>when you have a
>> > form view that reacts to get() and post(). Upon "get()",
>>the template
>>
>> > *could* call data-modifying methods on the class.
>>
>>
>> Not easily, since the templates can only call methods which don't
>> require extra params, get/post do take request at least.
>>
>
> I love it when problems solve themselves :-)


That's a good point.  Are there *any* methods in the CBVs that don't take
arguments, that also modify data?  The only one that I found in the list I'd
initially proposed that can be called without arguments is as_view(), and
I'm not sure that really even needs protection.  Maybe there's no need to
protect anything with alters_data / proxying?

That would certainly be the simplest, and would eliminate the possibility
that someone will later ask for us to expose a certain method or attribute
that we thought it best to hide now.

Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.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-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: please reopen ticket 15567

[Anssi Kääriäinen]

On Sep 13, 8:24 pm, Adam Jenkins  wrote:
> +1 on making the error say more than incorrect username/password. That
> is confusing. In regards to leaking information about the user. The
> error message in general could be changed to something like this, of
> course with better wording:
>
> "Username and password incorrect or access to this page restricted".

+1. This solves the problem nicely. the login does not leak
information and the error message is correct.

 - 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-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: please reopen ticket 15567

[Flávio Amieiro]

On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> +1, if the user/pass is entered, that user is entitled so know what its own
> permissions are.
> The error should give "You have insufficient access to this page" or
> something like that.

The thing is: if someone does a brute force attack on '/admin/' and
gets this message back, they know there's a user with that
login/password in the system. Since brute force attacks using common
login/password pairs in this kinds of urls is so common, I think this
exposes your user more than necessary.

-1

-- 
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: please reopen ticket 15567

[Babatunde Akinyanmi]

+1 again.
If a correct username and password combination are given, the person
submitting the credentials should know that he doesn't have access
just like cal pointed out. Its unfair and frustrating to say that the
combination is wrong

On 9/13/11, Cal Leeming [Simplicity Media Ltd]
 wrote:
> +1, if the user/pass is entered, that user is entitled so know what its own
> permissions are.
>
> The error should give "You have insufficient access to this page" or
> something like that.
>
> Cal
>
> On Tue, Sep 13, 2011 at 6:12 PM, Florian Apolloner
> wrote:
>
>> -1, This would leak information about the users (But I am sure that's
>> discussed at length in the other threads)
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
>>
>> 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.
>
>

-- 
Sent from my mobile device

-- 
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: please reopen ticket 15567

[Wim Feijen]

Hi, thanks for your quick responses!

Flavio, Jan and Florian, it only "gives away information" when an
attacker guesses both the username and the password right.

But if he can guess those right, he could already access the users
information using the normal login! So giving this message does not
change the danger. On the other hand, it would prevent lots of
confusion.

But we are repeating arguments here, so could you please read:

http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef

before responding?

Thanks!

Wim


On 13 sep, 19:23, Flávio Amieiro  wrote:
> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>
>  wrote:
> > +1, if the user/pass is entered, that user is entitled so know what its own
> > permissions are.
> > The error should give "You have insufficient access to this page" or
> > something like that.
>
> The thing is: if someone does a brute force attack on '/admin/' and
> gets this message back, they know there's a user with that
> login/password in the system. Since brute force attacks using common
> login/password pairs in this kinds of urls is so common, I think this
> exposes your user more than necessary.
>
> -1

-- 
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: please reopen ticket 15567

[Adam Jenkins]

+1 on making the error say more than incorrect username/password. That
is confusing. In regards to leaking information about the user. The
error message in general could be changed to something like this, of
course with better wording:

"Username and password incorrect or access to this page restricted".

The current status is that we are telling the user something this is
incorrect. I've actually run into this situation before where I had a
user reset their password a few times before coming to me.

On Tue, Sep 13, 2011 at 12:18 PM, Jan Schotsmans  wrote:
> I can imagine several situation where you would like the user not to know
> that, until they talk to an administrator.
> -1 for me too, both giving away user info and giving info to the user that
> would be better given by a talk to an administrator.
>
> 2011/9/13 Cal Leeming [Simplicity Media Ltd]
> 
>>
>> +1, if the user/pass is entered, that user is entitled so know what its
>> own permissions are.
>> The error should give "You have insufficient access to this page" or
>> something like that.
>> Cal
>>
>> On Tue, Sep 13, 2011 at 6:12 PM, Florian Apolloner 
>> wrote:
>>>
>>> -1, This would leak information about the users (But I am sure that's
>>> discussed at length in the other threads)
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
>>> 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.
>
> --
> 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: please reopen ticket 15567

[Jan Schotsmans]

I can imagine several situation where you would like the user not to know
that, until they talk to an administrator.

-1 for me too, both giving away user info and giving info to the user that
would be better given by a talk to an administrator.

2011/9/13 Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk>

> +1, if the user/pass is entered, that user is entitled so know what its own
> permissions are.
>
> The error should give "You have insufficient access to this page" or
> something like that.
>
> Cal
>
>
> On Tue, Sep 13, 2011 at 6:12 PM, Florian Apolloner 
> wrote:
>
>> -1, This would leak information about the users (But I am sure that's
>> discussed at length in the other threads)
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
>>
>> 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.
>

-- 
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: please reopen ticket 15567

[Cal Leeming [Simplicity Media Ltd]]

+1, if the user/pass is entered, that user is entitled so know what its own
permissions are.

The error should give "You have insufficient access to this page" or
something like that.

Cal

On Tue, Sep 13, 2011 at 6:12 PM, Florian Apolloner wrote:

> -1, This would leak information about the users (But I am sure that's
> discussed at length in the other threads)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
>
> 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: please reopen ticket 15567

[Florian Apolloner]

-1, This would leak information about the users (But I am sure that's 
discussed at length in the other threads)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
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: please reopen ticket 15567

[Babatunde Akinyanmi]

+1

On 9/13/11, Wim Feijen  wrote:
> Hello,
>
> When a user tries to login on the admin, with correct username &
> password, but is_staff is set to False, the error message is
> misleadingly wrong:
>
> "Please enter a correct username and password. Note that both fields
> are case-sensitive."
>
> Ticket 15567 deals with this and is currently marked as wont fix.
> After a lenghty discussion on
>
> http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef
>
> the general consensus seems in favor of changing the error message and
> thus to re-open the ticket.
>
> Could the ticket please be reopened?
>
> Thanks,
>
> Wim
>
> Ticket 15567:
> https://code.djangoproject.com/ticket/15567
>
> A patch:
> https://code.djangoproject.com/attachment/ticket/16834/admin_not_allowed.diff
>
> --
> 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.
>
>

-- 
Sent from my mobile device

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

please reopen ticket 15567

[Wim Feijen]

Hello,

When a user tries to login on the admin, with correct username &
password, but is_staff is set to False, the error message is
misleadingly wrong:

"Please enter a correct username and password. Note that both fields
are case-sensitive."

Ticket 15567 deals with this and is currently marked as wont fix.
After a lenghty discussion on

http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef

the general consensus seems in favor of changing the error message and
thus to re-open the ticket.

Could the ticket please be reopened?

Thanks,

Wim

Ticket 15567:
https://code.djangoproject.com/ticket/15567

A patch:
https://code.djangoproject.com/attachment/ticket/16834/admin_not_allowed.diff

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

[Adam Jenkins]

On Tue, Sep 13, 2011 at 10:00 AM, h3  wrote:
> Most of them were competent developers, but they didn't see the point
> of learning a how to get started with Django because it seemed too
> complicated to setup and use for starters. So they preferred to stay
> in their comfort zone: PHP.

One option a third part could put time into to solve this issue is a
prebuilt machine. A wrapped up, distributable vagrant install. That
could easily take 90% of the complexity away.

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

Agreed

On Wed, Sep 14, 2011 at 1:00 AM, h3  wrote:
>> Beyond that, what I am wondering is how much users will be able  understand 
>> how Django work if they can't do the installation.
>
> Each year I accept foreign students for internship in my company and
> most of then either never heard of Django or didn't bother to learn
> how it works just to try it.
>
> Most of them were competent developers, but they didn't see the point
> of learning a how to get started with Django because it seemed too
> complicated to setup and use for starters. So they preferred to stay
> in their comfort zone: PHP.
>
> But when I gave them no other choices than to learn and use Django,
> most of them picked it up in less than a week and they "saw the
> light".
>
> Just last week my last intern wrote me on facebook to say he continued
> to use django back in his country and he think it's really awsome.
>
> The point is not to lower the bar for the "less gifted" as you imply,
> it's to lower the bar so more developers can give it a try without
> having to learn about every possible approaches and test them to see
> which one fits their needs.
>
> If they can get started and play with django with little efforts and
> they like it, *then* they will have a good incentive to spend time
> learning more about the many ways you can use and deploy it.
>
> I think that's what "lowering the bar" is mostly about. It's not about
> making it dumb-friendly by any means.
>
> regards
>
> On Sep 13, 2:07 am, Xavier Ordoquy  wrote:
>> Le 13 sept. 2011 à 05:44, Justine Tunney a écrit :
>>
>> > I agree with you that reducing the barriers to using Django is very 
>> > important.  But what we need is not necessarily a web based installer, but 
>> > something to get people off the ground so they can start playing around 
>> > with Django very quickly.  Back in the day (like circa 2004) the thing 
>> > that really helped me learn PHP was this program called EasyPHP which was 
>> > a simple Windows based installer that got me up and running and writing 
>> > code on my local machine in five minutes.
>>
>> PHP and Django installation are very different.
>>
>> For PHP you need a couple of things:
>>  - apache or equivalent
>>  - php module
>>  - configuration tuning
>>  - find the apache root to put your files under
>>  - a database
>>  - database modules for php
>> and I might have missed a couple of things
>>
>> For Django, you'll need:
>>  - Python
>>  - Django
>>
>> At this point you can go ahead with the dev server and sqlite. No need to 
>> tune/configure things further. I hardly see how one can lower this further.
>>
>> Beyond that, what I am wondering is how much users will be able to 
>> understand how Django work if they can't do the installation.
>>
>> Regards,
>> Xavier.
>
> --
> 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

[h3]

> Beyond that, what I am wondering is how much users will be able to understand 
> how Django work if they can't do the installation.

Each year I accept foreign students for internship in my company and
most of then either never heard of Django or didn't bother to learn
how it works just to try it.

Most of them were competent developers, but they didn't see the point
of learning a how to get started with Django because it seemed too
complicated to setup and use for starters. So they preferred to stay
in their comfort zone: PHP.

But when I gave them no other choices than to learn and use Django,
most of them picked it up in less than a week and they "saw the
light".

Just last week my last intern wrote me on facebook to say he continued
to use django back in his country and he think it's really awsome.

The point is not to lower the bar for the "less gifted" as you imply,
it's to lower the bar so more developers can give it a try without
having to learn about every possible approaches and test them to see
which one fits their needs.

If they can get started and play with django with little efforts and
they like it, *then* they will have a good incentive to spend time
learning more about the many ways you can use and deploy it.

I think that's what "lowering the bar" is mostly about. It's not about
making it dumb-friendly by any means.

regards

On Sep 13, 2:07 am, Xavier Ordoquy  wrote:
> Le 13 sept. 2011 à 05:44, Justine Tunney a écrit :
>
> > I agree with you that reducing the barriers to using Django is very 
> > important.  But what we need is not necessarily a web based installer, but 
> > something to get people off the ground so they can start playing around 
> > with Django very quickly.  Back in the day (like circa 2004) the thing that 
> > really helped me learn PHP was this program called EasyPHP which was a 
> > simple Windows based installer that got me up and running and writing code 
> > on my local machine in five minutes.
>
> PHP and Django installation are very different.
>
> For PHP you need a couple of things:
>  - apache or equivalent
>  - php module
>  - configuration tuning
>  - find the apache root to put your files under
>  - a database
>  - database modules for php
> and I might have missed a couple of things
>
> For Django, you'll need:
>  - Python
>  - Django
>
> At this point you can go ahead with the dev server and sqlite. No need to 
> tune/configure things further. I hardly see how one can lower this further.
>
> Beyond that, what I am wondering is how much users will be able to understand 
> how Django work if they can't do the installation.
>
> Regards,
> Xavier.

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

django test-runner annoyances

[mvr]

Why doesn't the django test management command / test builder allow
fully-qualified package names instead of just app-relative ones?

At work we've been using the method below to monkey-patch the test
builder, so that

 $ django-admin.py test my_module.my_app.tests.some_test_file

always works as expected.  We'd like to get rid of this monkey-patch,
and since this functionality can be added in such a way that it's
completely backwards compatible, where is the harm?  I'm also willing
to submit a diff that modifies django in-place, but the monkey patch
below should be easy to read and first I wanted to hear if anyone has
any thoughts on why the existing behaviour really is exactly what it
should be.



def _support_dotpaths():
""" allows real dotpaths to be used as test labels for
django's test runner
first we maintain the status quo by doing whatever django
does, then
just do it the way that they should have done it in the
first place.
"""
import unittest
from django.db.models.loading import ImproperlyConfigured
from django.test import simple
django_build_test_test = simple.build_test
def my_build_test(label):
fallback = lambda:
unittest.TestLoader().loadTestsFromName(label)
try:
return django_build_test_test(label)
except ValueError, v:
if 'should be of the form' in str(v):
return fallback()
else:
raise
except ImproperlyConfigured,e:
if 'App with label' in str(e):
return fallback()
else:
raise
simple.build_test = my_build_test
return my_build_test

-- 
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: #7198 - Better error message when app is missing models.py

[Jannis Leidel]

On 12.09.2011, at 22:44, Carl Meyer wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Gary,
> 
> On 09/12/2011 12:04 AM, Gary Wilson Jr. wrote:
>> I'm a fan of not requiring a models.py, as IMHO it shouldn't be any
>> different than other common files found in an app e.g. urls.py,
>> templatetags dir, etc.  If I don't need any models for my app, then
>> why must I still have a models.py?  That said, it also seems there
>> could be some backwards incompatibilities if code or external tools
>> rely on a valid app including a models.py file.
> 
> Actually, I think there's generally consensus that requiring models.py
> is not ideal. There's already an existing GSoC branch (app-loading),
> which already fixes the models.py issue (AFAIK) but is somewhat
> languishing for lack of attention. So I think the best path towards
> getting that fixed is to check out that branch and help get it in
> merge-ready shape. Jannis was the mentor for that GSoC, he or Arthur
> Koziel (the student) can probably comment most knowledgeably about what
> needs to be done.


Right now this needs a thorough code review to decide how to go forward. There
are several open questions, e.g. how to get the general (non-app-loading) test
suite integrated with the changes of the app loading. The main problem there
is that runtests.py has a hardwired assumption about how the app cache works,
basically a chicken-egg problem. That said, the app-loading changes itself is
well tested separately as pure-Python unit tests [1].

Some people have started to review but never got back to me, which -- and I
hate to write that since Arthur and me spent so much time on it -- makes me
wonder if we ever get close enough to merging this. I'm convinced it's really
useful, but as it's such a core part of Django it also definitely needs more
than two sets of eyes. Was there any interest at DjangoCon US?

Jannis

1: https://github.com/jezdez/django/tree/app-loading/tests/appcachetests

-- 
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: CSRF token not validated?

[Jens Diemer]

Am 12.09.2011 22:32, schrieb Carl Meyer:

Sanity-checking the length sounds reasonable to me - do you mind opening
a ticket for this and attaching your patch?


Done ;)

Ticked:
https://code.djangoproject.com/ticket/16827

Patch:
https://github.com/django/django/pull/45


--

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.

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

[Mikhail Korobov]

Hi all,

There are a lot of projects for making django deployment easier (a bit of 
them are listed here: http://djangopackages.com/grids/g/deployment/ ) but 
there is no clear winner, everybody have different preferences and 
requirements. I think this all doesn't relate to development of django 
itself now: if somebody have an idea for an another deployment app she 
should go and implement it and see if it will work for other people. 
Deployment approaches can be very different, they are subject to holy wars 
so I think for now the diversity is for good.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/GJEiOX1eg80J.
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.