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 should actually run. The
pr
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( {
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 effort to shepherd this al
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
for signed cookies (but
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 att
>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
RET_KEYS = 'your-new-secret-key'
3. Turn on the Django signed cookie upgrading middleware:
MIDDLEWARE_CLASSES += (
'django.middleware.signedcookies.UpgradeOldSignedCookies',
)
4. Tell that middleware which cookies to upgrade:
SIGNED_COOKIES_TO_UPGRADE = (
('name&#
On Dec 30 2009, 10:28 pm, Wim Feijen wrote:
> In the discussions on CSRF there have been several proposals to
> include RequestContext by default in render_to_response or in a
> similar function. As a side note to my previous post, I'd like to
> mention my favorite way to do this: render_to , see:
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 and all of it's
idiosync
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.
To
... 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 wis
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:
http://docs.djangoproject.com/en/dev/topics/db
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 by actually using it.
I'
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=...) and
> TimestampSigner(ttl=...).
The f
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 balancers and https hardward ac
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 default
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 thing. Is this kind o
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 need to implement. django.ut
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
http://github.com/
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 why I don't think it's
a
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 should
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 huge new feature, and then
On Dec 4, 8:38 am, Simon Willison 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 collide with each other.
I meant
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 outside of the gis tree itsel
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:
c.query("sele
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 t
On Oct 23, 3:30 pm, Jonas Obrist wrote:
> Oh... Well than consider this a 1.X suggestion. I've tried Rosetta
> however it just doesn't seem to work Also I don't really like to use
> 3rd Party apps for what I'd consider core functionality. I mean django
> boasts with having excellent i18n capa
On Oct 12, 9:03 am, Benjamin Slavin wrote:
> That means: I'm strongly in favor of any hook to allow code to be run
> before the Django environment is setup, and I'm not tied to any
> particular path of solving the problem.
I'm trying to avoid taking on any Django projects at the moment other
tha
On Oct 11, 2:32 am, Simon Willison 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
> solution
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.
--~--~---
On Oct 11, 2:32 am, Simon Willison wrote:
> Alternatively, should I just stick my log configuring code in the
> Setting class constructor and leave well alone?
For the moment, I've done exactly that:
http://github.com/simonw/django/commit/eb9737129501a6d17014afdb55c8bb4d5222b693
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': {
'
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 explore, it's not yet-another-
On Oct 10, 1:41 pm, Simon Willison 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 many
> statements the unit
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, but like I said, this
> >
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 be the critical facto
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
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 git (for those of us wh
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
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 within Django's test framewor
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 opi
On Oct 5, 6:33 pm, Matt Brubeck wrote:
> On Sep 24, 10:18 am, Simon Willison wrote:
> > This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> > generate and append signatures to bytestrings and confirm that they
> > have not been tampered with. dumps and
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" gr
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 Twisted logic, etc... But t
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
> possible. I included the TEST_RUN
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 fr
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 external project - but if it
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 test --failed
>
> Doe
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 should live. I've finally got
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, I'm sorry for disparaging of
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 should live. I've finally got
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 large dependency,
but 77 li
On Sep 26, 7:33 pm, Simon Willison wrote:
> 1. a {% selfclose %} template tag:
>
>
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
I've added an experimental {% slash %} tag to django-html to address
the reusable XHTML/HTML templates
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 future is now and the focus
I've started a project on GitHub to develop the signing
implementation:
http://github.com/simonw/django-signed
The TODO section in the readme shows the next things I'll be working
on.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
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 syntax" and generates
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
"extra_context" that's actually
On Sep 26, 6:34 pm, Rob Hudson wrote:
> This is the bit I was hoping we could get to. What would that
> refactoring look like, you think? Would it involve making forms use
> Templates? Or something else?
I don't think it would involve form widgets being rendered with
templates simply because
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 successor to XHTML 1.
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 Django doctype switch
rathe
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 Django template language
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 = signer.sign(v)
> v = signer.unsign(s)
>
On Sep 25, 3:39 pm, Simon Willison 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.
Here's a good arg
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 = signed.unsign('key', s)
> >>>
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 asking for that separa
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 the timestamp the cook
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 for every different
>
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 easier.
Great idea: htt
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 cookie values that match a
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 __getitem__() though, be
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 Djan
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 you explain a bit more abo
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 for any systematic CSRF
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 potentially has
> big implicatio
On Sep 17, 3:42 pm, Simon Willison 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
> see if I c
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
> configure different handlers
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 loggers already being us
th-Magee
wrote:
> On Thu, Sep 17, 2009 at 3:11 PM, Simon Willison
> wrote:
>
> > 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 usin
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 directly, *except* for
> > "what'
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 discussed should be forthcoming
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
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 using
> django.Forms are le
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 going? It was explicitly
>
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 which
case it might be good
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 interested in being able to h
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 cache backends - it's w
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, 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
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
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
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
> i
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
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
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 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
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
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
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 t
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:
1 - 100 of 297 matches
Mail list logo
