Re: Logging format decision

On Jan 14, 1:57 am, Russell Keith-Magee wrote: > The other issue that I think still needs to be addressed is the > internal usage of logging by Django itself. My biggest hangup with the logging implementation was figuring out exactly when the logging configuration code

Model validation incompatibility with existing Django idioms

A couple of related tickets filed today about model validation: http://code.djangoproject.com/ticket/12513 http://code.djangoproject.com/ticket/12521 The first one describes the issue best - the new model validation code breaks the following common Django convention: form = SecretQuestionForm(

Re: Design and code review requested for Django string signing / signed cookies

On Jan 4, 6:18 pm, James Bennett wrote: > Simon, the amount of pushback this is getting, and the changes which > need to be made to start bringing it up to snuff, make me feel far too > nervous about this being ready in time to make 1.2 at all. I know > you've put in the

Re: Design and code review requested for Django string signing / signed cookies

On Jan 4, 2:45 pm, Jordan Christensen wrote: > Is there a good way to make it forward upgradeable? Allow the > developer to decide on the shorter SHA-1 hash or the (theoretically) > more secure SHA-256? There is - we can expand the BACKEND setting which is already in place

Re: Design and code review requested for Django string signing / signed cookies

Had some good feedback on news.ycombinator and programming.reddit - you can follow the threads here: http://news.ycombinator.com/item?id=1030290 http://www.reddit.com/r/programming/comments/ald1m/calling_crypto_security_experts_help_review_the/ tptacek on news.ycombinator pointed out a timing

Re: Design and code review requested for Django string signing / signed cookies

>From Jordan Christensen on Twitter: >http://twitter.com/thebigjc/status/7366243197 "@simonw why sha-1 instead of sha-256? NIST has recommended not using SHA-1 in new systems: http://bit.ly/6bIf5h; I chose sha-1 over sha-256 for reasons of signature length. A base64 encoded signature generated

Design and code review requested for Django string signing / signed cookies

eedback Does this look sane? Have we overlooked anything? Is there anything we can do to make this more secure by default? I'll read any replies here, or you can e-mail feedback to simon AT simonwillison.net. Please say if you don't want stuff sent to that address to be shar

Re: 1.2 Feature freeze

On Dec 23, 8:34 am, James Bennett wrote: > * URLs-1 (get_absolute_url replacement) The code's not ready - I have the get_url / get_url_path methods but I don't have a good enough hold yet on what actually needs to be done to replace the existing get_absolute_url behaviour

Re: Call for feedback: django.utils.signed and signed cookies

Having talked to James about this I'm holding off on the commit until we've had it reviewed by real cryptographers. I'll aim to get it in before the 1.2 beta feature freeze. Cheers, Simon -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: Congratulations Alex and Russell on committing multidb!

... and congratulations to Marc Garcia and Jannis Leidel for the i18n/ l10n improvements that just went in as well. Also congratulations to everyone for the other awesome commits going in at the moment. There are far too many congratulations to spell them all out at the moment (with hindsight I

Congratulations Alex and Russell on committing multidb!

And a big congratulations to all involved. Here's the changeset log (on GitHub since Trac seems not to like being linked to at the moment): http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611 And here's the documentation:

Re: Call for feedback: django.utils.signed and signed cookies

On Dec 22, 6:22 am, Russell Keith-Magee wrote: > As far as the patch itself is concerned, looks good to me. My only > other request would be a serving of dogfood - if we're going to > include a signed cookie module, it would be nice to prove that it can > actually be used

Re: Call for feedback: django.utils.signed and signed cookies

On Dec 22, 12:52 am, Johannes Dollinger wrote: > I'd like some more kwargs to Signer and TimestampSigner. Mostly what's   > inhttp://dpaste.com/136418/(except the `separator` kwarg, which was   > a bad idea as it depends on encode()): Signer(serializer=...)

Re: What do people think about the get_absolute_url proposal?

On Dec 8, 3:23 am, Rick Yazwinski wrote: > I think that this may be too simplified: >         protocol = getattr(settings, "PROTOCOL", "http") >         domain = Site.objects.get_current().domain >         port = getattr(settings, "PORT", "") > > Many sites put load

Re: Call for feedback: django.utils.signed and signed cookies

I've made some changes based on the feedback in this thread: http://github.com/simonw/django/commit/802952bbb8b763e65ee545c6a8f39524b20e147c "Use sha('signer' + secret_key + salt) to derive the key for use in the signature() method, addressing feedback from the django-developers list" The

Re: Loading Backends

On Dec 21, 2:22 pm, Marty Alchin wrote: > Looking over Simon's patch for signed cookies, I noticed that yet > another feature needs to write its own "load a backend from a setting" > function. Yup - and as I copied and pasted it from somewhere else I thought exactly the same

Re: Call for feedback: django.utils.signed and signed cookies

On Dec 21, 2:40 pm, Russell Keith-Magee wrote: >  * I'm not sure I like this being in django.utils. To me, it feels > like something that should be in django.core - along with caching, > serialization, etc, signing is a core piece of functionality that a > website will

Call for feedback: django.utils.signed and signed cookies

I've uploaded the patch for adding signing and signed cookies to Django: http://code.djangoproject.com/attachment/ticket/12417/ticket12417.diff You can also read the documentation directly on my GitHub branch: http://github.com/simonw/django/blob/signed/docs/topics/signing.txt

Re: adding rosetta for enhanced user experience

On Dec 14, 9:41 pm, Suno Ano wrote: > What do folks think about shippinghttp://code.google.com/p/django-rosetta > with Django? Enabling it per default even? imho that app is totally > worth being shipped with Django per default. This came up a couple of months ago. Here's

What do people think about the get_absolute_url proposal?

This made it to the 1.2 feature list: http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl If we want this in 1.2, it could be as simple as merging the get_url / get_url_path methods in to the base Model class, rolling a few unit tests and writing some documentation. It feels like we

Re: Multiple database support: Request for feedback and testing

On Dec 5, 4:20 pm, Russell Keith-Magee wrote: > Trust me - I don't want to do mindless busy work. However, we need to > have some sort of answer for the admin interface - Django's admin is a > big selling point for Django for some people, so we can't really > introduce a

Re: Multiple database support: Request for feedback and testing

On Dec 4, 8:38 am, Simon Willison <si...@simonwillison.net> wrote: > We now have two blog posts in each database. But, if I do the > following: > > e1.save(using = 'db2') > > It has the effect of replacing e3 with the values from e2, since the > primary keys collid

Re: Multiple database support: Request for feedback and testing

On Dec 3, 4:10 pm, Russell Keith-Magee wrote: > Alex Gaynor's GSoC project to add multiple database support to Django > is on the final straight. The only piece of the puzzle that is left is > updating contrib.gis - but this hopefully won't require any major > changes

How hard would it be to make bits of Django compatible with async servers?

I've been getting very excited about Node.js recently: http://simonwillison.net/2009/Nov/23/node/ It's basically Twisted / Tornado but in JavaScript, and with the huge advantage that, because it's brand new, it doesn't have any legacy blocking APIs. Database access looks like this:

Should docs.djangoproject.com link to 1.1 frozen docs by default, not SVN dev docs?

Now that 1.2 features have started to merge (great work everyone involved with the Email backends and ManyToMany refactorings, they look fantastic) we're entering one of those relatively rare periods of instability in trunk. This is exactly the kind of time that we want most of our regular users

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 11, 2:32 am, Simon Willison <si...@simonwillison.net> wrote: > Is there a straight forward solution to this that I've been missing, > or is it an ongoing problem? If it's a problem, can we fix it? What > makes it so difficult to fix (I'm going to guess there's no easy &g

Re: Proposal for 1.2: built-in logging with django.core.log

I'm now tracking the logging implementation in ticket #12012: http://code.djangoproject.com/ticket/12012 I've started posting patches from my branch there. Again, this is just exploratory code at the moment but I'm keen to receive as much feedback on the implementation as possible.

Best place for code that processes stuff from settings.py once (for logging implementation)

I've got to the point in the logging implementation where I want to add support for logging related settings in settings.py. The current idea (suggested by Ivan Sagalaev) is to allow for a standard Django-style setting that look something like this: LOGGING = { 'django.db.sql': {

Re: Proposal: Tutorial Refresh

On Oct 10, 2:04 pm, Ned Batchelder wrote: > My strong feeling is that these two goals will quickly become impossible > to reconcile.  I think the idea of a conference site is a good one > (everyone will understand the problem domain, lots of interesting > avenues to

Re: Proposal for 1.2: built-in logging with django.core.log

On Oct 10, 1:41 pm, Simon Willison <si...@simonwillison.net> wrote: > Oops, yes you're right - I misread the numbers. A 2.5 second different > would correspond to around 350,000 log messages (assuming the rate of > 130,000/second from my microbenchmark) - I have no idea how ma

Re: Proposal for 1.2: built-in logging with django.core.log

On Oct 10, 12:55 pm, Luke Plant wrote: > > master: 314.442s > > logging: 317.096s > > > Since there's nothing at all in my logging code that will speed > > anything up, I'm putting that down to chance (I did run the suite a > > few times first to "warm up" the VM I used,

Re: Proposal for 1.2: built-in logging with django.core.log

On Oct 9, 4:54 pm, Jacob Kaplan-Moss wrote: > One big question I have is about performance: have you done any a/b > testing against trunk to see how much adding logging -- especially > upon every SQL query -- impacts performance? > > For me, at least, performance is going to

Re: Proposal: Tutorial Refresh

Put me down as a other +1 for a full site tutorial, especially one that covers pip, virtualenv, unit testing and the like. I have a suggestion for a site, too: How about the conference website for the next DjangoCon? It's meant to be a community run conference so the job needs to be done at some

Re: Proposal for 1.2: built-in logging with django.core.log

On Oct 9, 11:12 am, Luke Plant wrote: > >http://github.com/simonw/django/tree/logging > > Is there some easy way to see the patch?  Preferably a link which will > just show the diff between the latest of your branch and trunk, but > failing that, a recipe of commands using

Re: Proposal for 1.2: built-in logging with django.core.log

For anyone interested in following this, I've just started a (currently experimental) branch on GitHub: http://github.com/simonw/django/tree/logging So far I've added a 'django' logger which is silent by default, and hooked up a new CursorLoggingWrapper to log all SQL statements from the ORM to

Re: Brand new projects should pass their tests (the django.contrib.auth thing from #7611)

On Oct 6, 1:25 pm, Russell Keith-Magee wrote: > I think we need something else. In particular, I think we need to > address the problem at a slightly deeper level - we need to > acknowledge that we don't differentiate between application tests and > integration tests

Brand new projects should pass their tests (the django.contrib.auth thing from #7611)

One of the things that has been established at DjangoCon is that, as a community, we don't have a strong enough culture of testing. This is despite Django shipping with some good testing tools (TestClient and the like). Anything we can do to make testing more attractive is a Good Thing. In my

Re: Adding signing (and signed cookies) to Django core

On Oct 5, 6:33 pm, Matt Brubeck <mbrub...@limpet.net> wrote: > On Sep 24, 10:18 am, Simon Willison <si...@simonwillison.net> wrote: > > This offers two APIs: sign/unsign and dumps/loads. sign and unsign > > generate and append signatures to bytestrings and confirm

Re: Branchy Django developement on GitHub

Thanks for putting this together - that's a really useful summary of commands. Any chance you could save it on the wiki somewhere? Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Re: Adding an option to re-test only failed tests

On Oct 2, 12:09 pm, Ned Batchelder wrote: > I would think the same logic applies to Django.  Nose needs to work with > lots of different projects, so they can't own the Django details, since > by that logic they'd also own the TurboGears logic, the Pylons logic, > the

Re: Adding an option to re-test only failed tests

On Sep 30, 5:47 am, Russell Keith-Magee wrote: > I'm yet to be convinced that Nose should be the default test runner > for the simple reason that it doesn't come out of the box with Python. > However, I agree that using Nose with Django should be as painless as >

Re: Proposal for 1.2: built-in logging with django.core.log

So I've read through the Python Logging 101 (really useful) and the logging docs: http://plumberjack.blogspot.com/2009/09/python-logging-101.html http://docs.python.org/library/logging.html Here's my understanding of what we need to do for Django. 1. Create a 'django' logger somewhere in the

Re: Adding an option to re-test only failed tests

On Sep 29, 7:34 pm, Rob Madole wrote: > TEST_RUNNER = 'django.contrib.test.nose.run_tests' > > There might be some futzy bits to make that actually work, but I think > it'd doable. I'd love to see this working. Obviously this would work just as well implemented as an

Re: Adding an option to re-test only failed tests

On Sep 29, 5:03 pm, Rob Madole wrote: > I've been using nose for our tests, and one of the features that I > really like is the ability to run the tests again but filter only the > ones that caused a problem. > > I'm thinking it would look something like this > > ./manage.py

Re: Model.objects.raw() (#11863)

On Sep 29, 2:24 am, SeanOC wrote: > During the Djangocon sprints I started to work on a patch which would > add a nicer interface for dealing with raw SQL queries.  While there I > talked to RKM about where it should fit into the ORM API and where in > the code base

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 29, 9:36 am, Vinay Sajip wrote: > Simon, I'm the author of Python's logging package. Sorry for the delay > in replying, I've been away from this list awhile. I think the "Java > heritage shines through" is just FUD. Hi Vinjay, Thanks for dropping by. Firstly,

Re: Model.objects.raw() (#11863)

On Sep 29, 2:24 am, SeanOC wrote: > During the Djangocon sprints I started to work on a patch which would > add a nicer interface for dealing with raw SQL queries.  While there I > talked to RKM about where it should fit into the ORM API and where in > the code base

Re: Proposal: Better HTML4 support

On Sep 28, 6:57 pm, Rob Hudson wrote: > For lack of knowing about anything better, I keep falling back to > Werkzeug's HTMLBuilder class[1].  Pulled out and stripped of comments, > it weighs in at 77 lines of code... That's not so bad. I was worried about pulling in a

Re: Proposal: Better HTML4 support

On Sep 26, 7:33 pm, Simon Willison <si...@simonwillison.net> wrote: > 1. a {% selfclose %} template tag: > >     <br{% selfclose %}> > > {% selfclose %} outputs either blank or " /" depending on the doctype. I've added an experimental {% slash %} tag to djan

Re: Proposal: Better HTML4 support

On Sep 28, 5:20 pm, Max Battcher wrote: > I really don't see what the fuss here is about. If we are worried about > forwards-compatibility, HTML 5 takes care of it. If we are worried about > better backwards-compatibility with HTML 4, everyone else is saying that > the

Re: Proposal: Better HTML4 support

On Sep 27, 10:49 am, veena wrote: > my bits to discussion about supporting various (X)HTML versions. > > 1) Problem with (X)HTML in python code (in applications) > I discovered this python packagehttp://pypi.python.org/pypi/html/1.6 > It allows you to write "python like HTML

Re: CSRF - next step?

On Sep 26, 7:44 pm, Alex Gaynor wrote: > So I'm still a little unclear on what this shortcut does that > direct_to_template doesn't already? It's a bit less weird. direct_to_template lives somewhere I can't remember (so I rarely import it), has an argument called

Re: Proposal: Better HTML4 support

On Sep 26, 10:17 am, Max Battcher wrote: > Furthermore, support for XHTML "5" (which is indeed a part of the HTML 5 > standard) shows that XHTML 1's principles are still around and still > respected. Django's XHTML output can't be "out of date" if XHTML 5 is > considered a

Re: Proposal: Better HTML4 support

On Sep 26, 5:48 am, Rob Hudson wrote: > First, let's not let this turn into an argument about HTML vs XHTML. Oops, sorry! > People have their preference one way or the other, and I believe > Django should be agnostic. Completely agree - that's why I'm in favour of a

Re: Proposal: Better HTML4 support

On Sep 26, 6:50 am, Jerome Leclanche wrote: > This is a non-issue. Obviously I disagree - this is a tiny thing that has bugged me ever since newforms. It's also something I find myself constantly apologising to front-end developers about, who for the most part love the

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 4:44 pm, Johannes Dollinger wrote: > Regarding parity, let me advertise a Signer object again: > >         signer = signed.Signer( >                 key=settings.SECRET_KEY, >                 expire_after=3600 >         ) > >         s =

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 3:39 pm, Simon Willison <si...@simonwillison.net> wrote: > While that makes sense for caching, I couldn't say if it makes sense > for signatures or not - when we sign something, will we always know > the point at which we want that signature to expire? I don't know.

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 3:10 pm, Marty Alchin wrote: > The timestamp would then be the actual expiration > time, rather than the time it was signed, so the API can look like > this instead (with a key added per prior discussion). > > >>> s = signed.sign('key', 'value') > >>> v =

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 1:57 pm, Marty Alchin wrote: > I think this is good for everywhere the raw signing API is accessed, > perhaps to the point where that API can't even be used without a key > (a namespace, really - honking great idea!). Helpers on top of that > API could do without

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 1:57 pm, Marty Alchin wrote: > I wish there was > a way to sign the expiration as well, so people couldn't artificially > extend the life of the cookie, but since that doesn't come back in the > request, there'd be no way to validate it. We can do that by baking

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 12:02 pm, Luke Plant wrote: > In other web apps (I think Wordpress?), there have been problems > associated with use of secret keys when the same key is used for > different purposes throughout the application. > ... >  - we add unique prefixes to the SECRET_KEY

Re: Adding signing (and signed cookies) to Django core

On Sep 25, 4:48 am, Russell Keith-Magee wrote: > By way of greasing the wheels towards trunk: if the outcome of this > mailing list thread was a wiki page that digested all the ideas, > concerns and issues into a single page, it will make the final > approval process much

Re: Adding signing (and signed cookies) to Django core

On Sep 24, 8:22 pm, Benjamin Slavin wrote: > Unfortunately, this approach won't work. > > A malicious client can just send "key" rather than "key__Xsigned" and > you'll never know that the cookie hasn't gone through validation. > This also means that you can't look for

Re: Adding signing (and signed cookies) to Django core

On Sep 24, 7:37 pm, Marty Alchin wrote: > Another option would be to have request.COOKIES be a custom > dictionary, with an extra .get_unsigned(key) method that would work > like .get(), but validates the signature along the way. That behavior > can't be added straight to

Adding signing (and signed cookies) to Django core

As mentioned in the thread about cookie-based notifications, at the DjangoCon Sprints I raised the subject of adding signing (and signed cookies) to Django core. I've found myself using signing more and more over time, and I think it's a concept which is common enough to deserve inclusion in

Re: CSRF proposal and patch ready for review

On Sep 22, 9:24 pm, Luke Plant wrote: > > 2. I'm not at all keen on the implementation as a middleware > > (especially a view middleware, which doesn't play well with generic > > views and redispatching to other view functions, both patterns I like > > a lot). > > Could

Re: CSRF proposal and patch ready for review

On Sep 19, 4:56 pm, Russell Keith-Magee wrote: > End users should be allowed to be as lazy as they like, but > their laziness shouldn't open security holes in an app that Django > ships, since the contrib apps (and admin in particular) are the > obvious first port of call

Re: CSRF proposal and patch ready for review

On Sep 18, 12:09 am, Luke Plant wrote: > OK, here is my response.  I hope this doesn't turn into a personal my-code-vs- > your-code match (especially as most of "my code" is really other people's code > and ideas :-) but I want to make sure we do this right, as it

Re: CSRF proposal and patch ready for review

On Sep 17, 3:42 pm, Simon Willison <si...@simonwillison.net> wrote: > All good points - the change in function signature naturally fell out > of the CSRF work (since the form needs access to the request object in > both cases) but you've convinced me that it's a step too far - I'll

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 18, 6:21 pm, Eric Holscher wrote: > I have looked into Logging before for another project, and I found that > SQLAlchemy's support seemed to be a pretty good model to follow. They define > all of their loggers under the sqlalchemy namespace, and then you can >

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 17, 4:04 pm, Russell Keith-Magee wrote:  > I've seen several attempts to wrap Java loggers in a "nicer" > interface, and every one of them ended up hobbling some of the power > features of the logger. There is also the issue of our wrapper playing > nicely with the

Re: CSRF proposal and patch ready for review

<freakboy3...@gmail.com> wrote: > On Thu, Sep 17, 2009 at 3:11 PM, Simon Willison <si...@simonwillison.net> > wrote: > > > On Sep 15, 2:57 pm, Luke Plant <l.plant...@cantab.net> wrote: > >> OK, I'll wait and see. > > > Here's the code:http://github.com

Re: Replacing get_absolute_url, I am against it

On Sep 15, 12:04 pm, Ivan Sagalaev wrote: > James Bennett wrote: > > Except I can't help thinking this is an awfully arbitrary distinction > > to draw. In effect you're saying that nearly every question about an > > object should be answerable by interrogating it

Re: SoC merge plans?

On Sep 13, 12:52 pm, Russell Keith-Magee wrote: > Although the branch isn't ready for merge yet, the code that is > present is all up to spec. I think the sprints have produced workable > solutions for the outstanding problems; fixes implementing the > solutions we

Proposal for 1.2: built-in logging with django.core.log

I think we should add logging to Django in version 1.2, implemented as a light-weight wrapper around the Python logging module (django.core.log maybe?) plus code to write errors to the Apache error log under the mod_python handler and environ['wsgi.errors'] under WSGI (meaning mod_wsgi will write

Re: CSRF proposal and patch ready for review

On Sep 15, 2:57 pm, Luke Plant wrote: > OK, I'll wait and see. Here's the code: http://github.com/simonw/django-safeform >  * it requires using Django's form system.  I've got plenty of views that > don't (e.g. anything with a dynamic number of controls).  People not

Re: Long-term direction for shortcuts

On Aug 3, 3:53 am, chairface wrote: > Also, it is only a single video, but that video > is a pretty good resource for the topic of Django's future. It was > the topic of the entire hour. Are you implying that it's a poor > source for people wondering where Django is

Re: Multi-DB Update

On May 2, 12:19 am, Malcolm Tredinnick wrote: > I'd prefer dictionaries to strings, because strings are tough to modify > dynamically -- as has already been demonstrated a few times in Django's > history. That's a pretty strong argument in favour of dictionaries - in

Re: Multi-DB

On Apr 30, 12:25 am, Alex Gaynor wrote: > My question would be how is using a DSN and letting those be passed directly > to using() any advantage over letting someone pass a dict of those options > to using(), or a connection object itself. No advantage at all - I'm

Re: Multi-DB

On Apr 25, 7:11 am, Alex Gaynor wrote: > Simon uses a new DSN based syntax for specifying DBs, however I find this > pretty akward in the presence of our existing way for defining DB settings. I had a few reasons for suggesting DSNs: * We already use DSN-style syntax for

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Inner imports in core code

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

Re: Inner imports in core code

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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, &g

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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 &g

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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, &g

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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.

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Denormalisation, magic, and is it really that useful?

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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 re

Re: Denormalisation, magic, and is it really that useful?

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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 form.render_response('a

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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 =

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Proposal: django.forms.SafeForm - forms with built in CSRF protection

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

Re: Template inheritance and {% include %} tags

On Sep 18, 11:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > I think you missed the point, Simon. > > Michael isn't talking about self-referencing extending, he's talking > about blocks in statically included templates ({% include "bit.htm" > %}). Ah yes, sorry - misunderstood the original

  1   2   3   >