Max Battcher wrote:
> Have you seen Ivan Sagalaev's tag model? It needs updating to support
> the new GenericRelation (it currently uses a similar but proprietary
> clas),
I somewhat missed the whole discussion on generic relation though I get
the general idea. Do they work for ManyToMany rel
thats an interesting way of doing it.
(using a separate field for each tag)
but I was thinking it would be easier for the user to just type in a
string rather than click on things.
my problem really lies in not understanding what convert_post_data is
supposed to return.
On 23/06/2006, at 2:5
Ian Holsman wrote:
> Hi.
>
> I working on integrating the new GenericRelation field that was
> recently committed and making into into a 'tag field' where a user
> would just enter
> a list of strings into a single text field.
Have you seen Ivan Sagalaev's tag model? It needs updating to su
Hi.
I working on integrating the new GenericRelation field that was
recently committed and making into into a 'tag field' where a user
would just enter
a list of strings into a single text field.
all is good on the display side, I've got my 'TagField' populating
the input text field, and i
On 6/22/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2006-06-21 at 13:35 -0700, Tyson Tate wrote:
> What are the use cases for this sort of construction?
>
Here's another use case: you want to add fields to your table that
don't have a representation in the Django model.
For exa
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 real
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 stori
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 text
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 somethin
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 message
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 unnes
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 view
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 ha
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 implication
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 this,
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 w
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
* Ther
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 the
25 matches
Mail list logo
