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
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 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
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
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 some
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 be
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
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 set
+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 momen
