I like Luke's arguments.
A middleware seems like the right place because CSRF protection is
about requests and responses. CSRF protection is more about POST
requests in generic, with HTML forms being a very common type of POST
request.
IMHO the default settings.py file (generated with 'django-ad
In #8149 [1] I reported that `UploadedFile` uses `StringIO` to iterate
through uploaded files line-by-line, but `StringIO` only treats `\n`
as a line ending, at least in the current version.
This effectively means we can't use line-by-line iteration over
uploaded files because we don't know what
On Wed, Sep 24, 2008 at 8:36 PM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I posted a patch for django.contrib.formtools.wizard that adds a
> SessionWizard class. I'd like to know if there's any interest in
> apply this or a similar patch, and if so I'll work on tests and
> doc
This is an issue with Python, not Django in particular, although
something could be done in Django to remedy this issue.
I've already encountered this problem before, and I developed a
solution which may (or may not) be optimal. I implemented the solution
in two parts:
* The first part was a g
On Sep 24, 11:17 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> It turns out it's not that straight-forward after all:
>
> http://icanhaz.com/csrfpdf(PDF link, "Robust Defenses for Cross-Site
> Request Forgery")
>
> The above paper introduces the "login CSRF" attack, where CSRF is used
> to force
Hi all,
I posted a patch for django.contrib.formtools.wizard that adds a
SessionWizard class. I'd like to know if there's any interest in
apply this or a similar patch, and if so I'll work on tests and
documentation.
http://code.djangoproject.com/ticket/9200
Thanks,
Dave
--~--~-~--~--
I should have made this more accessible ..
http://code.djangoproject.com/ticket/2949
"I want to be able to set the path to a directory that contains the
templates I want to render at runtime. [...] The basic thing I'm
looking for is to be able to load a template from a specific,
arbitrary p
Am 25.09.2008 um 00:39 schrieb Manuel Saelices:
>
> It's a different aproach. I consider my cache attempt a optimization
> like URL dispatcher cache, without considering django cache system,
> like url resolvers cache, _join_cache in orm or other many cases.
> Also, I'm not sure that #6262 consi
It's a different aproach. I consider my cache attempt a optimization
like URL dispatcher cache, without considering django cache system,
like url resolvers cache, _join_cache in orm or other many cases.
Also, I'm not sure that #6262 consider the inheritance problem (look
at copy.deepcopy(self.get_
Am 25.09.2008 um 00:10 schrieb Manuel Saelices:
>
> Hi,
>
> one week ago I've made a little change in template rendering engine to
> get a huge performance improvement, in template rendering:
>
> http://code.djangoproject.com/ticket/9154
>
> The optimizations where two:
> 1) cache loaded templa
On Wed, Sep 24, 2008 at 4:49 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
>
> I'll go upload a fix now, the current behavior doesn't make sense,
> since the SQL spec says that NULL != NULL, does anyone know if there
> are any dbs for which this isn't true?
>
There are a couple of oddball DB
Hi,
one week ago I've made a little change in template rendering engine to
get a huge performance improvement, in template rendering:
http://code.djangoproject.com/ticket/9154
The optimizations where two:
1) cache loaded templates that becames compiled. In a threaded
environment, with many con
Thanks Alex! You get one virtual beer...
shannon
On Sep 24, 3:49 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I'll go upload a fix now, the current behavior doesn't make sense,
> since the SQL spec says that NULL != NULL, does anyone know if there
> are any dbs for which this isn't true
Hi!
I set up nightly builds of ubuntu packages for Hardy (8.04) and
Intrepid (8.10) of django trunk. This runs via a bzr import of django
trunk on launchpad, and has the revision number of trunk embedded in
the package version number, so you should be able to upgrade each day.
The PPA is here: h
I'll go upload a fix now, the current behavior doesn't make sense,
since the SQL spec says that NULL != NULL, does anyone know if there
are any dbs for which this isn't true?
On Sep 19, 11:10 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 19, 2008 at 10:51 AM, smcoll <[EMAIL PROTECTE
i think this has to be fixed in the current code. i wish i knew how
to fix it, or i'd close #9062. The ticket hasn't gotten any
attention, but i feel like it's a biggie. i'm surprised it's not
breaking other people's apps.
shannon
On Sep 19, 10:10 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
On Sep 24, 2008, at 18:27, Alex Myodov wrote:
> Being curious, had tried several benchmarks as well.
> Indeed, the function-level imports have some overhead. But the
> overhead becomes less and less important, as long as the function
> complexity increases. If a function does nothing except import
Hi Simon,
> 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
Being curious, had tried several benchmarks as well.
Indeed, the function-level imports have some overhead. But the
overhead becomes less and less important, as long as the function
complexity increases. If a function does nothing except import (as in
your case), the performance hit is several hun
On Wed, Sep 24, 2008 at 9:00 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 24, 2:18 pm, zellyn <[EMAIL PROTECTED]> wrote:
>> Would it make sense to have the middleware/view decorator set a
>> property on the request, and pass the request to all forms, and have
>> *all* forms CSRF-protec
On Sep 24, 10:00 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> That's an interesting idea. I'm a bit cautious of requiring ALL forms
> to take a request object though - Django's current form library is
> decoupled from Django's request object, which is actually a really
> useful property. I've
#7815[1]:
* Adds a loader kwarg to Context which should be something with a
get_template(name) function. Default would be django.template.loader.
* Provides get_template() and select_template() methods on Context.
These are used in {% include %}, {% extends %} and inclusion_tag.
* Caches temp
On Sep 24, 2:18 pm, zellyn <[EMAIL PROTECTED]> wrote:
> Would it make sense to have the middleware/view decorator set a
> property on the request, and pass the request to all forms, and have
> *all* forms CSRF-protect themselves when the property is set? That
> would make it easy to add protection
On Sep 24, 2008, at 14:52, Simon Willison wrote:
> Not entirely sure how I managed to miss your benchmark figures when I
> read your mail, but I'm wrong here - there's clearly a performance
> overhead involved in importing inside a function. It would be
> interesting to see how much this affects D
I like the middleware/view decorator for setting the cookie.
Would it make sense to have the middleware/view decorator set a
property on the request, and pass the request to all forms, and have
*all* forms CSRF-protect themselves when the property is set? That
would make it easy to add protection
On Sep 24, 1:40 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> As a result the performance overhead from having imports inside
> functions as opposed to at module level should be virtually non-
> existent.
Not entirely sure how I managed to miss your benchmark figures when I
read your mail, but
On Sep 24, 8:37 am, David Cramer <[EMAIL PROTECTED]> wrote:
> I was digging through some code today, and I noticed imports are
> happening within a lot of functions. It was my knowledge that it works
> like so:
>
> import in a function is the same as ruby's load or php's include --
> its executed
Note that in some cases, dynamic imports are done to avoid loading a
Django subsystem, large external library, or optional dependency until
it is strictly necessary.
There are certainly still examples where none of those good reasons
apply.
On Sep 24, 2008, at 2:37 AM, David Cramer <[EMAIL
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
I'd like to discuss if forms should try to be secure by default? It's
a bit like the autoescaping discussion.
The new Form class would need to accept dictionaries or request
objects as input. A dictionary is however only accepted if you
explicitly disable CSRF protection:
form = MyForm(request.PO
Denormalized for me personally happens a LOT when it's not just a
simple foreign key. Maybe I want to store a many to many field as
name,name,name in a column (tags). We're already inside of Django so
it should already be available (it's not going to be much slower than
it is executing the subquer
I just wanted to touch on this point:
models.IntegerField(default=0) does not translate to INT(11) default
0; in SQL :)
Django doesn't nescesarily try to interact with the database properly
when it should, because it requires too much thinking (and more code
that hasn't been written).
I would s
I was digging through some code today, and I noticed imports are
happening within a lot of functions. It was my knowledge that it works
like so:
import in a function is the same as ruby's load or php's include --
its executed everytime the function is
import in a module outside a function is lik
33 matches
Mail list logo
