If you really want an "empty" model -- but with a primary key, you
could define an "auto" field and delcare it to be the primary key. This
would give you in the DB the exact same thing as an empty model would.
One use case is implementing object inheritance in DB. One overall
"base" model is
James Bennett wrote:
> On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> > Some are suggesting that this text should be escaped before being
> > written to the db. It is true that the above text should be rendered as
> > follows in html/xml documents:
>
> I don't think we should escape before
Michael Radziej wrote:
[snip]
>
> I assume this is about Jacob's proposal, and it's handling this
> case correctly. Let's go through the steps he specified:
>
[snip]
Whether it is handling this case correctly or not, it still needs to be
escaped in an html or xml template, but not in a plain
Hi Jacob!
>
> On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
>> Rather than directly accessing GET and POST data
>> you do it through some mechanism that /guarantees/ the format of the
>> data returned - and raises an exception if it can't make that
>> guarantee. There is no possible way of
On 6/22/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Ouch! Sometimes this Django thing changes too fast :-)
Though the default 500 view has since gone back to a standard Context.
As Adrian explained in the commit message, this is to avoid having
context processors in the 500 view raise
Adrian Holovaty wrote:
> We changed the default 404 and 500 views to use RequestContext a
> couple of days ago, so you may not have seen that change. :)
Ouch! Sometimes this Django thing changes too fast :-)
Thanks!
--~--~-~--~~~---~--~~
You received this
Hi,
waylan wrote:
> I've been following this thread since the get-go with interest, but am
> a first time commenter here. Although I think the devs have a clear
> picture, I get the feeling that some participants in this discussion
> are geting input validation and output escaping confused which
On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> Some are suggesting that this text should be escaped before being
> written to the db. It is true that the above text should be rendered as
> follows in html/xml documents:
I don't think we should escape before storing. I think we should
*validate*
I've been following this thread since the get-go with interest, but am
a first time commenter here. Although I think the devs have a clear
picture, I get the feeling that some participants in this discussion
are geting input validation and output escaping confused which is
generating lots of
On 6/22/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Currently the default handler404 view uses simple Context. This results
> that often people relying on passing their stylesheet URLs with context
> processors loose this for 404 pages (I have an app that is written
> entirely with generic
Currently the default handler404 view uses simple Context. This results
that often people relying on passing their stylesheet URLs with context
processors loose this for 404 pages (I have an app that is written
entirely with generic views except a custom handler404 for the single
purpose of
On 6/22/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> I disagree that it's easy to write that kind of validator function -
> and I think trying to do so is a mistake. What if I want to post a
> comment on a forum like this?
Then you'd get caught by the validator.
Thinking about the
Hi Jacob,
Jacob Kaplan-Moss wrote:
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this, but I'm sure a good syntax could be found.
I'm not sure I missed a point; is this, for html, the
Hi, all. Yes, I like this much better, too.
> 1. request.GET['whatever'] returns a ``untrusted_string`` object, not
> a regular string
>
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell
On 22 Jun 2006, at 04:50, James Bennett wrote:
>> following that, I think Django should, of the two options, cover the
>> majority, which I believe is "escape by default" and allow {%
>> autoescape off %}. For the sake of security, I'm really hoping to see
>> escaping automatically turned on.
>
On 22 Jun 2006, at 08:48, James Bennett wrote:
> For given values of "validate", yes. It is, however, easy to write
> validator functions which will reject anything that looks like HTML,
> and HTML is the most important threat.
I disagree that it's easy to write that kind of validator function
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, I don't like to put the whole burden into the input validation,
And nobody's really suggesting that we should; we already provide a
template filter for sanitizing on output, and a block tag for doing
the same seems like a decent idea.
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, come on, that's a completely different thing than auto-escaping
> of variables in the template. I had no idea php is/was *that* brain-
> dead (*shiver*)
The problem of suddenly having to figure out ways to tell whether
you're dealing
Hey,
First, let me note that we're discussing one aspect of Django and
whether or not there is a sensible way to harden it agains XSS
exploits. It is not whether this or the other way is better ...
Now, I don't like to put the whole burden into the input validation,
since I believe
*
Am 22.06.2006 um 06:54 schrieb James Bennett:
>
> On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
>> Oh - I haven't heard of the magic_quotes fiasco. Do you have any
>> links or more information about this? If it blew up for the PHP
>> folks, I think I'd be prone to changing my position on
20 matches
Mail list logo
