Re: Default project layout / directory structure
I like the idea too, since I've run into a lot of situations where some more convention here would make a decision much easier to make. However, it isn't clear what exactly should be better defined and I think the first step to a serious proposal would be to figure that out. The only example that comes to mind is Pinax's apps/ directory for a project's internal apps – it's a good convention that many people already follow. My other gripe has already been taken care of, with the integration of django-staticfiles. What other things did you have in mind? -- 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: Default project layout / directory structure
I'm +1 on this. Project conventions tend to be the biggest problem when adding new people to the team, especially when it comes to configuration management - everyone has their own way. It would be great if there will be at least an official list of best practices on building Django project layout. On Mar 11, 7:14 am, Simon Litchfield wrote: > Who votes we should come up with a django-blessed 'official' default project > layout / directory structure? > > Might sound like a triviality, but sometimes it's the little things. > > 1. Newcomers -- startproject throws 9/10 into confusion and results in a > messy first few projects. > > 2. Gurus -- each have their own way, what a waste, not DRY. > > 3. The new breed of django hosting platforms that are on their way -- gives > them something to base their tools on. > > Why not have a standard way, standard tools, etc etc- built in, batteries > included. DRY. > > Whether it be a plain old manage.py-friendly directory layout, something > virtualenv+pip powered, maybe something like Lincoln Loop's startproject > style, Eric Holscher's, or whatever. Lets not go too nuts on directories > though, they get tiring (especially in textmate) > > Thoughts? -- 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: #14733: A vote in favor of no validation of .raw() queries
On Fri, 2011-03-11 at 23:20 -0500, Jacob Kaplan-Moss wrote: > Hi Christophe -- > > Interesting; I didn't know about these constructs. > > I'm not opposed to this change, but I am a bit concerned about opening > up the ability to use raw() for stuff like UPDATE/DELETE where it'd be > a nasty code smell. I'd be interested in your thoughts on that: is > there a way we can prevent folks from shooting themselves in the foot > this way, or do you think trying itself is futile? If they're going to do it, they're going to do it - I can immediately think of several people who, on finding that they can't do what they want with raw(), would naturally progress to writing a postgres function to do the dirty work (on the grounds that that can then be called using "select"). Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- 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.
Postgres sequence names (I've reopened #8901)
The fix in #8901 partially fixes #1946, making it easier to use django with some egacy postgres databases. It does not however aid in the use of legacy databases that uses postgres' own inheritance as pg_get_serial_sequence() doesn't work on these. Until postgres gets its act together :) we can add a function to postgres itself that looks up the sequence names in more cases than what pg_get_serial_sequence() can handle. Since this might be the first time this particular type of solution has been suggested the core devs need to have a think about whether it is at all desirable. HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 14261 - add basic clickjacking protection to Django
I personally like the idea of a decorator On Mar 13, 12:30 pm, Ryan N wrote: > I personally do not believe XFrameOptionsMiddleware should be on by > default. There are plenty of folks using Django for simple static > sites or RESTful APIs where clickjacking doesn't apply. > > I'd prefer it's something that requires you to intentionally turn it > on by adding the middleware to your settings and/or using the > decorators on views you want to clickjack protect. > > With that said, I could change the patch if the core devs say > otherwise. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 14261 - add basic clickjacking protection to Django
This is awesome - very progressive and I hope other frameworks follow suite. Have you done a poll of users to see how many would be affected by a "SAMEORIGIN" setting? Maybe that would be a good place to start. Is there some other way to test the overall impact of this prior to committing to it being on by default? On Mar 13, 2:51 am, Ryan N wrote: > See approved ticket:http://code.djangoproject.com/ticket/14261 > > There, Luke Plant said: > > """ > +1, I was going to suggest it myself. The patch looks pretty good. > After Django 1.3 is out, we should have some discussion on django-devs > about: > > - what the default value should be (I think SAMEORIGIN would make it > better for general use, with very little decrease in security). > - whether we can avoid a new setting > - whether the middleware should be on by default or in the project > template. > """ > > I already changed the patch to default to SAMEORIGIN instead of DENY, > so that should be cool. So it seems the other two points are what's up > for some discussion. Anything else? -- 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: Wrong error message when user having is_staff=False tries to login to admin
To summarize - if I understand correctly the only way a more specific error message can result in a problem is the following scenario: 1) An attacker correctly guesses credentials for a user on the admin site 2) The attacker does not try to authenticate with the same credentials on the regular site The attacker is able to determine that the credentials are correct AND the user is *not* an administrator. This is only a risk if #2 holds, which leads to me believe it's a very low risk scenario. You could argue there's some incremental security benefit in withholding information, but I'm not sure it justifies the hit to usability. My primary job is to help prevent security vulnerabilities, but I'd still say +1 for giving a more specific message in this context. On Mar 13, 10:41 am, TiNo wrote: > +1 for giving a correct message. It has bitten me more than once, and I > really don't think it would make any attack harder. > > The information you would give is the same information that can be acquired > by logging in to the main site first, and then trying to log in to the admin > site. So at the moment we are trying to obscure something that isn't obscure > now either... > > > > > > > > On Sat, Mar 12, 2011 at 13:35, Peter wrote: > > I think some people seem to be confused about what is being asked for. > > > I think the suggestion is that you should get this new "not an admin > > account" message iff > > the provided username _and_ password are correct. If you don't have > > permission, but > > provide an incorrect password, then you still get the old message. > > > That way, you can only gain more information than with the current > > system when you have > > both a username and correct password. If an attacker has that > > information, then frankly, > > it's too late to be thinking about how to make things more secure. > > > Regards, > > > Peter > > > -- > > 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: Ticket 14261 - add basic clickjacking protection to Django
I personally do not believe XFrameOptionsMiddleware should be on by default. There are plenty of folks using Django for simple static sites or RESTful APIs where clickjacking doesn't apply. I'd prefer it's something that requires you to intentionally turn it on by adding the middleware to your settings and/or using the decorators on views you want to clickjack protect. With that said, I could change the patch if the core devs say otherwise. -- 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: Wrong error message when user having is_staff=False tries to login to admin
+1 for giving a correct message. It has bitten me more than once, and I really don't think it would make any attack harder. The information you would give is the same information that can be acquired by logging in to the main site first, and then trying to log in to the admin site. So at the moment we are trying to obscure something that isn't obscure now either... On Sat, Mar 12, 2011 at 13:35, Peter wrote: > I think some people seem to be confused about what is being asked for. > > I think the suggestion is that you should get this new "not an admin > account" message iff > the provided username _and_ password are correct. If you don't have > permission, but > provide an incorrect password, then you still get the old message. > > That way, you can only gain more information than with the current > system when you have > both a username and correct password. If an attacker has that > information, then frankly, > it's too late to be thinking about how to make things more secure. > > Regards, > > Peter > > -- > 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.
