> I propose django.forms should include a SafeForm class, which is a
> subclass of Form that includes built-in protection against CSRF. I
> imagine the interface looking something like this:
Why wouldn't the safe form class be the forms.Form class instead? We
do XSS-protection by default
On Sep 23, 12:53 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > The significant downside is that having a render() method on a form
> > that performs the same function as render_to_response feels really,
> > really strange. It's
On Sep 23, 1:53 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > The significant downside is that having a render() method on a form
> > that performs the same function as render_to_response feels really,
> > really strange. It's
On Tue, Sep 16, 2008 at 2:41 AM, oggy <[EMAIL PROTECTED]> wrote:
> On Sep 15, 10:49 pm, "Justin Fagnani" <[EMAIL PROTECTED]>
> I can clearly see the appeal of the idea. Django can stay Javascript-
> agnostic, while the community could develop a PrototypeForms,
> DojoForms, etc. and it would be a
On Sep 23, 12:21 am, "Justin Fagnani" <[EMAIL PROTECTED]>
wrote:
> In my experience at least, denormalization occurs
> a lot and leaves a lot of room for mistakes, so it's something a
> framework should handle if possible.
Just so it's on the record, I'd like any denormalisation tools in
Django
On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> The significant downside is that having a render() method on a form
> that performs the same function as render_to_response feels really,
> really strange. It's convenient, but it just doesn't feel right and
> I'm not sure I can
On Sep 23, 3:54 am, mrts <[EMAIL PROTECTED]> wrote:
> +1 for adding a way to say "process_response should never be called on
> this response".
>
> Taking a quick look at the source, HttpResponse seems to support
> iteration already:
>
> def __iter__(self):
> self._iterator =
On Sep 23, 12:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> return form.render('add_article.html', {
> 'extra_context_args': 'Go here',
> })
Using render_response as the method name might make this a little more
palatable:
return
On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> - If there's some other way to spell form.protect(response).
Here's a crazy idea that might just work:
class AddArticleForm(forms.SafeForm):
headline = forms.CharField()
# ...
def add_article(request):
form =
I think any discussion of denormalization needs to include aggregation
as well, since most uses will involve more than simply looking up one
value form a related model. I also think this is something definitely
to include in core. In my experience at least, denormalization occurs
a lot and leaves
On Sep 22, 10:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm
On Sep 22, 11:09 pm, Jan Oberst <[EMAIL PROTECTED]> wrote:
> I'd protect all my forms if there's a neat way to do it. Why would it
> only apply to logged-in users? I'm not using contrib.auth.
It doesn't need to only apply to contrib.auth logged in users, but it
should only be used for forms
On Sep 22, 10:21 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> This makes me think -- is it possible that CSRF protection at the form
> level is too low? Perhaps it's something that needs to be happening
> at, say, the view level? Some sort of decorator, and/or a tag to spit
> out the CSRF
Hi,
this would be very useful for a lot of use cases. View counts that
originally came from a foo viewed bar table with timestamps for every
viewer, or storing some sort of sum calculation from a list of
related objects. Basically all that stuff you would display in an
"overview table" of some
On Mon, Sep 22, 2008 at 3:25 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I propose django.forms should include a SafeForm class, which is a
> subclass of Form that includes built-in protection against CSRF. I
> imagine the interface looking something like this:
Yes, indeed -- we should do
On Sep 22, 5:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> One thing that might help out in this case would be the ability to
> create a SafeForm from a regular Form (which might be an argument for
> csrf protection as a feature of django.forms.Form rather than a
> subclass). If the third
On Sep 22, 10:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> > > -- What about third-party app forms that aren't SafeForms, but need to
> > > be? The situation dictates this, not the form author.
> > I think we keep CSRF middleware around to deal with that. We also very
> > actively encourage
On Sep 22, 5:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> But still, the situation dictates the need for SafeForm, not the form
> author. If this becomes best practice, essentially *every* form will
> need to be initialized with a request.
What about something like:
def
On Sep 22, 4:55 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> > -- What about third-party app forms that aren't SafeForms, but need to
> > be? The situation dictates this, not the form author.
> I think we keep CSRF middleware around to deal with that. We also very
> actively encourage third
On Sep 22, 4:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm
CSRF[1] is one of the most common web application vulnerabilities, but
continues to have very poor awareness in the developer community.
Django ships with CSRF protection in the form of middleware, but it's
off by default. I'm willing to bet most people don't turn it on.
I don't believe
On Mon, Sep 22, 2008 at 4:03 PM, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> So, I'd love people's opinions about where I should take this - to a
> dark corner and hide it, to a separate app like django-extensions (which
> involves keeping the horrid hacks in there), into a separate app but
> with
I've been working for some time on a pure-Python PostgreSQL driver, and
have recently worked on getting it to function with Django. It's to the
point now where it seemed to pass all Django 1.0 unittests. The
bpgsql-2.0alpha1.tgz package can be found here:
So, hello everyone. I figure this list is the best place to ask this,
but please feel free to deride me if not...
After all the talk of multiple databases, and non-relational databases
(bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've
been thinking about denormali[s/z]ation
On Jul 4, 2:26 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> > The only thing that might be worth doing in this are is adding a way to
> > say "middleware should never be called on this response" and then
> > somebody can write their own HttpResponse subclass and be in complete
> > control of their
> Can we figure out what this thread is about, and stick to it, please?
As the person who originally started the thread ;-)
I'd like to agree a design for a patch which will be accepted into
Django trunk and will enable us to close the #3460 ticket.
The current #3460 patch needs more work.
On Mon, Sep 22, 2008 at 11:39 AM, HenrikV <[EMAIL PROTECTED]>wrote:
>
> I hope your reply was helpful to others. I asked a question because I
> am not as knowledgeable about Django internals as you obviously are,
> and this is this is to my knowledge the place to ask.
> I make no assumptions
I hope your reply was helpful to others. I asked a question because I
am not as knowledgeable about Django internals as you obviously are,
and this is this is to my knowledge the place to ask.
I make no assumptions about where there is a bug, or if there is one,
as I haven't figured out how
On Sep 20, 8:20 am, Erik Allik <[EMAIL PROTECTED]> wrote:
> I see your point about overriding reusable app media.
>
> I got an idea though when reading your post. Since people want to
> update reusable apps to a more recent version/revision and since that
> means the media files will/might
On Mon, Sep 22, 2008 at 9:11 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> However, Django also misuses transactions in other cases (exactly the
> ones you mention). A transaction does not guarantee consistency of
> multiple operations, at least not in the default READ COMMITTED
>
> I've done a quick non-scientific test. Here's the code:
> ...
> So the default level is indeed faster but I have to confess I'm a lousy
> tester so I encourage anybody to conduct their own experiment.
I appreciate the test case here. Note that we were in the millions of
queries a day before
On Mon, Sep 22, [EMAIL PROTECTED] wrote:
> Django with #3460 is _significantly_ faster when the query load is
> high. If I ran stock Django on Chesspark, the database overhead would
> cripple the site.
I'd really like to see a kind of benchmark that I can try out to check your
measurements.
A
> It will also leave things vulnerable to having only some of your objects
> updated, some of them deleted, some of them saved with no way to restore
> to a known state. This proposed change is a bit more complicated than
> the patches in #3460, since it's kind of a good thing to preserve
>
> When it comes to overhead... As far as I know PostgreSQL in autocommit
> mode will wrap each statement (even SELECT) in an implicit transaction.
So what? Should we wrap it in 5 more just for giggles? Each one adds
overhead.
> > While you may think that you are not using transactions for
> I don't want to get into the argument about ticket 3460 itself but I
> just don't get this paragraph... What is special in web applications
> that makes them not require transactions? And more, how transactions --
> a mechanism for preventing DB to end up in an inconsistent state -- can
> get
On 21 Wrz, 14:35, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> kubiku wrote:
> > May I suggest using word "stable" instead of final? While "final" is
> > great mood improver for internal django developers, "stable" gives
> > stronger message to django users and especially their bosses. And
> >
Richard Davies wrote:
> That's an interesting article, and I follow your logic. However,
> Jack's original patch follows from profiling work he did on his
> Chesspark site (see
> http://metajack.wordpress.com/2007/07/25/do-you-know-what-your-database-is-doing/
> ) in which he claimed a 2-3x
37 matches
Mail list logo
