> in fact, it takes us back to the
> original proposal of a SafeForm that just takes the request object as
> an argument to its constructor.
Well this seems much simpler, although there is still the requirement
to add the csrf_fields whenever you write out the form in the template
(which isn't mu
On Sep 23, 2008, at 18:32, [EMAIL PROTECTED] wrote:
> Django's saving can trample data unintentionally, and indeed, we've
> seen this in production. Trampling data is an extremely hard to find
> problem since it amounts to a race condition. Since this could be
> easily avoided in several differe
So I guess it's not my brain farting.
On Sep 24, 12:23 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Unsurprisingly, I've been totally over-engineering this. There's no
...
> I think we solve this with a setting, the default of which looks like
> this:
At least you haven't been writing over-en
On Sep 23, 11:02 pm, Jan Oberst <[EMAIL PROTECTED]> wrote:
> Adding a signed field with a timestamp would be a much easier way to
> secure forms. But it's not nearly as as secure as having the token
> signed with an additional cookie. By setting a signed cookie you can
> verify that this very form
On Sep 23, 11:51 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> There is another option, a template tag. I would implement it as a
> middleware and a template tag. Template tag csrf_protect, will require
> CSRFMiddleware and django.core.context_processors.request, will add a
> input file contain
On Sep 24, 1:04 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> There's another option that avoids the need for any cookies at all:
> generating a persistent one-use-only token when a form is saved,
> storing that in the database and only allowing submissions that
> include a token that was previo
On Sep 23, 11:23 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF attacks are a problem for systems where an action is only meant
> to be available to a specific logged in user. This user is inevitably
> identified by a unique cookie. This is normally a session cookie,
> hence many CSRF protec
On Tue, Sep 23, 2008 at 8:43 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
> The problem is that any token, no matter where we generate it, isn't
> going to be submitted back with the POST request unless it's a field
> in the form that was submitted. So the only options I see are
> mangling the HTML
On Wed, Sep 24, 2008 at 3:54 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> On Sep 23, 3:40 pm, "Adam J. Forster" <[EMAIL PROTECTED]> wrote:
>> Hi Eric,
>>
>> That's what I have done at the moment, but as you say it's a bit of a
>> hack and I'm not sure that I'm happy with it.
>
> I ran across this
On Sep 23, 1:06 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Since all form.protect(response) actually does is ensure that there's
> a csrf cookie, you should only actually have to do it once for one of
> the forms.
Unsurprisingly, I've been totally over-engineering this. There's no
need for f
On Sep 23, 10:17 pm, "Robert Coup" <[EMAIL PROTECTED]>
wrote:
> then when you get a form submission, base64-decode it, split at "/", check
> the hash matches by recalculating it, then use the proximity-to-timestamp
> and the remote_addr to check the form validity.
Anything that relies on remote_a
On Tue, Sep 23, 2008 at 12:52 AM, David Cramer <[EMAIL PROTECTED]> wrote:>
> For me, personally, it would be great if this could accept callables
> as well. So you could store the username, like so, or you could store
> a choices field like:
>
>field = models.IntegerField(choices=CHOICES)
>
On Wed, Sep 24, 2008 at 5:29 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> > Could we just include something like a signed salt+timestamp
> > +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> > of the possibility of a same
On Sep 23, 6:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> Could we just include something like a signed salt+timestamp
> +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> of the possibility of a same-IP-CSRF (affecting people behind
> proxies), but it's dead simple and doesn't req
On Sep 23, 3:40 pm, "Adam J. Forster" <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
> That's what I have done at the moment, but as you say it's a bit of a
> hack and I'm not sure that I'm happy with it.
I ran across this bug the other day too; quite annoying. It's ticket
#3310 and there appears to be
On 23 sep, 01:27, Simon Willison <[EMAIL PROTECTED]> wrote:
> 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.
Hi Eric,
That's what I have done at the moment, but as you say it's a bit of a
hack and I'm not sure that I'm happy with it.
--
Adam J. Forster
On 23 Sep, 20:33, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
> You can just put a models.py there that is empty. A slight hack, but it
> should work ju
You can just put a models.py there that is empty. A slight hack, but it
should work just fine. (Think of it as __init__.py's big brother :))
Eric
On Tue, Sep 23, 2008 at 2:27 PM, Adam J. Forster <[EMAIL PROTECTED]>wrote:
>
> Firstly I'm sorry if I have posted this in the wrong place, but I
> thi
Firstly I'm sorry if I have posted this in the wrong place, but I
think that it belongs here and not on the django-users list.
Here's my problem, in most of our projects at work we have an app
called 'core' which contains modules that are either used by several
other apps or are not specific/larg
On Tue, Sep 23, [EMAIL PROTECTED] wrote:
>
> > You completely missed my point that if there's some integrity or other
> > database error in the sequence of multiple updates or deletes (and when
> > Django does updates to multiple tables or deletes, it extracts the id
> > values first), we can cu
On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> Could we just include something like a signed salt+timestamp
> +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> of the possibility of a same-IP-CSRF (affecting people behind
> proxies), but it's dead simple and doesn't re
> I think that we
> should try to write a patch which a) makes 3460 a configuration option
> as suggested, and b) supports transactions on top of the autocommit
> connection when explicitly requested (3460 currently doesn't, so parts
> of the test suite currently fail when it is applied).
+1 from
> You completely missed my point that if there's some integrity or other
> database error in the sequence of multiple updates or deletes (and when
> Django does updates to multiple tables or deletes, it extracts the id
> values first), we can currently roll back to the start of the sequence
> and
Could we just include something like a signed salt+timestamp
+REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
of the possibility of a same-IP-CSRF (affecting people behind
proxies), but it's dead simple and doesn't require a lot of code
change: Form -> SafeForm + request as the
On Tue, Sep 23, 2008 at 7:44 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> This appears to be a proposal to re-implement triggers inside Django.
>
> I can see there are benefits if the underlying DB platform won't support
> triggers, but wouldn't triggers be the preferred solution when they're
>
On Sep 23, 10:56 am, oggie rob <[EMAIL PROTECTED]> wrote:
> I'm sorry, I used the wrong term here. I didn't mean that CSRF
> protection isn't worthwhile, just that going the route of an extended
> form might not be the best way to do it.
> As for suggestions, I'm not sure I have one exactly, but I
On Sep 23, 3:26 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
>> Is it worth a gut check to make sure this is worthwhile?
>
> Here's a useful case in point: the admin. Django's admin should ship
> with CSRF protection turned on and baked i
On Sep 23, 2:00 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> Without some Python-based approach, all I could see is maybe adding a
> cross-platform "create trigger" API (ugh) to Django, which an
> application could then use to set up its triggers during syncdb.
> Otherwise, something like that
Hello!
Before I wrote this e-mail, I look at the tickets but I haven't found
none with this approach.
I have this models:
class ArticleManager(models.Manager):
def get_query_set(self):
return super(ArticleManager, self).get_query_set().extra(
select={'comments_count': 's
On Tue, Sep 23, 2008 at 8:44 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> This appears to be a proposal to re-implement triggers inside Django.
I suppose it is. But then, perhaps triggers were a re-implementation
of application-based denormalization. ... The chicken? The egg? The
world may never
Yes, Steve, it's true that triggers do have much of the same
functionality as this kind of proposal, but as you say, part of the
proposal is to make these hopefully work with future non-SQL databases
(although, admittedly, that's only a small piece of the puzzle).
To be honest, my main drive i
This appears to be a proposal to re-implement triggers inside Django.
I can see there are benefits if the underlying DB platform won't support
triggers, but wouldn't triggers be the preferred solution when they're
available? That way there is no chance that changes can be made outside
the scope o
Michael Radziej wrote:
> There is no way to agree about the "#3460 ticket", because the ticket does
> not really state what you want to solve, but how you want to change Django.
...
> Now, please, pick only one pain
I certainly agree that we've been all over the place on this thread!
And my think
On Mon, 2008-09-22 at 07:11 -0700, [EMAIL PROTECTED] wrote:
[...]
I've snipped the explanation of serialization levels. That's known
stuff. It's also pretty much irrelevant to this discussion, but since
you insist, I've addressed why the current behaviour is also a valid
possibility, below.
You
On Jul 1, 1:02 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I've implemented iterable HttpResponse
> in the first place out of purely practical reason: web server times out
> if a particularly long file was passed into an HttpResponse. And also it
> was really slow and was consuming all the memo
On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
> I just read this thread now, and by the end of it, things are looking
> pretty complicated. Is it worth a gut check to make sure this is
> worthwhile? Although the middleware might be a hack now, it seems
> sensible that it fits in request
David Cramer wrote:
> If you're not doing denormalization in your database, most likely
> you're doing something wrong. I really like the approach that is
> offered here.
>
> For me, personally, it would be great if this could accept callables
> as well. So you could store the username, like so, o
On Mon, Sep 22, Richard Davies wrote:
>
> > 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
On Sep 22, 1: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 w
If you're not doing denormalization in your database, most likely
you're doing something wrong. I really like the approach that is
offered here.
For me, personally, it would be great if this could accept callables
as well. So you could store the username, like so, or you could store
a choices fie
40 matches
Mail list logo
