Re: Should user passwords be more strict?
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&q=password+policy&qt_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
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?
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
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
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
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
-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
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?
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
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
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
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
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?
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
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
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
+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
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
+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
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
+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
-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
+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
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
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
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
> 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
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
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?
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.