CSRF - next step?
Luke Plant
I just want to know what the status is before committing the CSRF
stuff:
* Jacob am I waiting for a thumbs up? I think you said you were going
to try out the code.
* Simon am I waiting for your patch?
If I'm not waiting for either, my plan would be:
* Commit what I've got pretty much as is.
* Then move it all from contrib to core
* Question: where should the docs (currently ref/contrib/csrf.txt)
be moved to? ref/csrf.txt seems like a sensible place, but I
don't know.
* Then add a render_to_response_with_request shortcut (once we
can decide on a colour...) and adjust the tutorials.
Simon:
* I could wait for you to write your csrf_protect_form code before
doing any of this, merge it and then do the above.
* You could write it against my lp-csrf_rework branch (which is not
going to change substantially), and I can move your patch
over to core (or you could move it).
* You could wait 'til I'm done so that we don't have to worry about
the fact that everything is going to move.
Personally, I think your patch would be better going in separately, as
it is additional functionality that is not used by default anywhere.
Also, I have written a Python script that attempts to help people find
all the <form>s and view code that needs attention. It has a whole
bunch of limitations and caveats, but I think it's pretty useful 90%
solution and automates a lot of what people would have done using grep
etc. Where should it go? It's currently in 'extras/' which seems to
be the right place.
Luke
--
"Smoking cures weight problems...eventually..." (Steven Wright)
Luke Plant || http://lukeplant.me.uk/
Alex Gaynor
>
> Hi all,
>
> I just want to know what the status is before committing the CSRF
> stuff:
>
> * Jacob am I waiting for a thumbs up? I think you said you were going
> to try out the code.
> * Simon am I waiting for your patch?
>
> If I'm not waiting for either, my plan would be:
> * Commit what I've got pretty much as is.
> * Then move it all from contrib to core
> * Question: where should the docs (currently ref/contrib/csrf.txt)
> be moved to? ref/csrf.txt seems like a sensible place, but I
> don't know.
> * Then add a render_to_response_with_request shortcut (once we
> can decide on a colour...) and adjust the tutorials.
>
direct_to_template doesn't already?
> Simon:
> * I could wait for you to write your csrf_protect_form code before
> doing any of this, merge it and then do the above.
> * You could write it against my lp-csrf_rework branch (which is not
> going to change substantially), and I can move your patch
> over to core (or you could move it).
> * You could wait 'til I'm done so that we don't have to worry about
> the fact that everything is going to move.
>
> Personally, I think your patch would be better going in separately, as
> it is additional functionality that is not used by default anywhere.
>
> Also, I have written a Python script that attempts to help people find
> all the <form>s and view code that needs attention. It has a whole
> bunch of limitations and caveats, but I think it's pretty useful 90%
> solution and automates a lot of what people would have done using grep
> etc. Where should it go? It's currently in 'extras/' which seems to
> be the right place.
>
> Luke
>
> --
> "Smoking cures weight problems...eventually..." (Steven Wright)
>
> Luke Plant || http://lukeplant.me.uk/
>
> >
>
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
Luke Plant
> So I'm still a little unclear on what this shortcut does that
> direct_to_template doesn't already?
It just has a slightly different and simpler API, and an import that
does not involve generic views. It also *doesn't* do some things that
direct_to_template *does* do, like the params dictionary. I think it
needs to be simple and obvious enough to be used early in the
tutorials, before generic views have even been introduced.
But it's certainly an optional part of the CSRF stuff - just something
to make using RequestContext easier and simpler.
Simon Willison
> So I'm still a little unclear on what this shortcut does that
> direct_to_template doesn't already?
remember (so I rarely import it), has an argument called
"extra_context" that's actually just the regular context, sets up a
surprising 'params' key in the context dictionary that contains the
function's **kwargs, executes any of the context arguments that are
callables before passing them to the template (even though the
template language usually does that anyway) and has an argument called
mimetype when as-of Django 1.0 content_type is the preferred name for
that parameter [1]. direct_to_template is also an odd name - it makes
sense for a generic view, but it feels strange when you're using it to
render a template from within your view code.
Personally, I want a shortcut called django.shortcuts.render which
looks like this:
def render(request, template, context=None,
content_type=DEFAULT_CONTENT_TYPE):
return render_to_response(template, context or {},
context_instance=RequestContext(request),
mimetype=content_type
)
Much less surprising than direct_to_template, and much easier to
import. I use this in basically every single one of my view functions
so I'd prefer a name that is concise over one that is more
descriptive. That's assuming I can't get any buy-in for my
TemplateResponse concept[2].
Cheers,
Simon
[1] (On further inspection it looks like my attempt to get mimetype
replaced by content_type throughout Django 1.0 was something of an
abject failure, since mimetype is used by both render_to_response and
direct_to_template)
[2] http://github.com/simonw/django-openid/blob/master/django_openid/response.py
- I really like the idea of custom HttpResponse classes that are
lazily evaluated just like QuerySets are, but I've got enough stuff to
evangelise for 1.2 already ;)