Re: Session/cookie based messages (#4604)

[Tobias McNulty]

On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee  wrote:

> In reality, I get a ping time closer to 300 ms. And that's to a
> high-end data center under ideal conditions - it can be much larger if
> I'm dealing with low end providers.
>

What?? 200 ms is the average quoted by Mr. Sproutcore himself!

No, in all seriousness, my apologies for making such a broad generalization
about packet latency.  I could/should have said 500 ms or even a second; the
argument and corresponding solution, if needed, remain the same.

Anyways..we digress.  I am marking this a non-issue in my own head - please
pipe up if there's a case to be made.

Tobias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ManyRelatedManager signals

[Stephen Sundell]

Is there a reason not to have a signal before and after creating an
entry into a ManyToMany table.  I have a piece of code i need to call
when this relationship is created.  I don't know of any signal that
exists already, so I created my own.  Thought it might be an
interesting feature to add, unless theres a reason its not there.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

set_urlconf/get_urlconf patch

[Sean Brant]

I have updated the patch on this ticket (http://code.djangoproject.com/
ticket/5034) that SmileyChris wrote a while back. I ensured that the
new patch works against rev:11590.

In talking to SmileyChris about this on the IRC channels he noticed
that not clearing the _urlconfs dict after each request could cause a
memory leak. I added a finally statement in
handlers.base.BaseHandler.get_response which will ensure that urlconf
gets reset after each requets/response.

I'm not sure what to do from here, it would be nice if some of the
core could chime in on this. It doesn't change to much with how stuff
works currently. Although we would probably have to take the warning
out until 1.3.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[Russell Keith-Magee]

On Wed, Sep 23, 2009 at 1:55 AM, Tobias McNulty  wrote:
> Vaclav,
> I think this is less of an issue, because you'd have to switch to another
> tab and perform a second operation that generated feedback in the ~200
> millisecond window of time between clicking a link and the new page loading.

Ah... the wonderful American perspective of the internet. :-)

As a proud resident of the antipodes, allow me to assure you that
200ms is not a representative sample of the time required to load a
page for those of us that don't live in the continental USA.

Let's consider Rackspace as a representative sample of a US based
server with plenty of bandwidth. As the crow flies, I'm about 17000 km
from a server in Texas. By simple laws of physics, it takes 60ms for
the signal to get from me to the server, and 60ms for the signal to
get back. That's 120ms, and I'm not even taking into account:

 * The time spent going through the 14 routing points between me and
Rackspace's servers

 * The fact that the cable between me and Texas doesn't follow the
same route as a crow

In reality, I get a ping time closer to 300 ms. And that's to a
high-end data center under ideal conditions - it can be much larger if
I'm dealing with low end providers.

Now add the time required to actually compute a response.

To put this in practical perspective - during DjangoCon, I heard lots
of people complaining about the speed of the hotel wireless network. I
didn't notice a serious change from what I use at home every single
day.

In this particular case, I think you're correct - I'm not especially
concerned about parallel cookie requests. However, there are plenty of
arguments that get made on the assumption that the internet is a form
of instant communication ( database connection lag ). I
want to drive home the point that Earth is a very large place, and no
matter where you are located, most of the world's population isn't
anywhere near you - and no amount of technology will fix problems
caused by the laws of physics.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

'str' object has no attribute '_default_manager' fix? (#10405)

[Steve]

http://code.djangoproject.com/ticket/10405#comment:10

Please forgive me (and point me to) if there's already a discussion
about this bug. I wasn't able to find it.

I linked above to Jacob's advice to 'just load Models before Forms'. Maybe
there is an easy way to do this, but if there is, I do not know it. I find
it unreasonable in all but the simplest (AKA tutorial) project. In a 50~ app
suite which 12~ projects pool, I'm really not sure how best to make certain
models is loaded before forms in every case. Could I perhaps get some
further guidance?

Thank you,

-Steve

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[Alex Gaynor]

On Tue, Sep 22, 2009 at 6:04 PM, Jacob Kaplan-Moss  wrote:
>
> On Tue, Sep 22, 2009 at 4:16 PM, Luke Plant  wrote:
>> James B - do we have a place to list things like this i.e. things
>> that probably should go in release notes?
>
> I think it'd probably be best to just start
> docs/releases/1.2-alpha.txt right now. We can list this stuff as we
> add it, and then someone (probably James or I) can clean it up into a
> solid doc in time for the release.
>
> Jacob
>
> >
>

Note that we now also have the:
http://docs.djangoproject.com/en/dev/internals/deprecation/#internals-deprecation
page for documenting depercated items.

Alex

-- 
"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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[Jacob Kaplan-Moss]

On Tue, Sep 22, 2009 at 4:16 PM, Luke Plant  wrote:
> James B - do we have a place to list things like this i.e. things
> that probably should go in release notes?

I think it'd probably be best to just start
docs/releases/1.2-alpha.txt right now. We can list this stuff as we
add it, and then someone (probably James or I) can clean it up into a
solid doc in time for the release.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[kmike]

Regarding key_prefix parameter: it's all simply about that:
http://code.djangoproject.com/ticket/11269
My proposal was to move things in opposite direction: to promote
`key_prefix` parameter, document it and make it more useful. If it is
an 'Design decision needed'-type of issue and design decision is made
then OK :)


On 23 сен, 03:16, Luke Plant  wrote:
> On Tuesday 22 September 2009 20:37:05 kmike wrote:
>
> > cache_page decorator previously used to have optional
> >  'key_prefix' argument, not only timeout. Is it gone? Can I use
>
> > @cache_page(3600, key_prefix='vasia')
> > def my_func(request)
> >    ...
>
> That wasn't documented anywhere as far as I can see, so now it's
> gone. I had to make some decision about how far the backwards
> compatibility went, and current policy is to go with documented API,
> which explicitly says "cache_page takes a single argument: the cache
> timeout, in seconds." [1]
>
> If there is some documentation/tutorial about the key_prefix
> argument, or if this change is going to cause lots of breakage,
> perhaps we'll have to revisit this.
>
> For the time being, you can create a 'cache_page' decorator that
> does what you want very easily, as in the example below.
>
> James B - do we have a place to list things like this i.e. things
> that probably should go in release notes?
>
> > Another question: in 'decorator_from_middleware_with_args'
> >  docstring example stated:
> > Use like::
>
> >     cache_page = decorator_from_middleware(CacheMiddleware)
>
> > Is it correct?
>
> Nope, should be decorator_from_middleware_with_args of course,
> thanks, will fix.
>
> Luke
>
> [1]http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-
> cache
>
> --
> "Pessimism: Every dark cloud has a silver lining, but lightning
> kills
> hundreds of people each year trying to find it." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Doug Blank]

On Tue, Sep 22, 2009 at 2:20 PM, Michael Feingold wrote:

>
> That's what we started with. It did not work out. While IronPython (as
> well as some other implementations of Python) are available in .Net,
> integrating an app written in Python with anything else written in any
> other .Net language proved to be a big challenge. You can run a Python
> app on .Net platform, but it still lives in its own world
>
>
That is not so much the case any more... you can now call Python functions
from other DLR scripting languages. So, you could conceivable run the Django
template parser in IronPython from IronRuby, for example. And with the new
dynamic syntax in .NET 4, this could work from F# too.

In any event, good luck with your project.

-Doug



> On Sep 22, 1:11 pm, Dj Gilcrease  wrote:
> > I dont know all that much about .Net but isnt the point of it that all
> > the .Net languages can be used together? eg using C#.Net components in
> > a VB.Net app and such.
> >
> > So why not just use the django template language as is via IronPython
> > instead of trying to port it to another language?
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[Luke Plant]

On Tuesday 22 September 2009 20:37:05 kmike wrote:
> cache_page decorator previously used to have optional
>  'key_prefix' argument, not only timeout. Is it gone? Can I use
> 
> @cache_page(3600, key_prefix='vasia')
> def my_func(request)
>...
> 

That wasn't documented anywhere as far as I can see, so now it's 
gone. I had to make some decision about how far the backwards 
compatibility went, and current policy is to go with documented API, 
which explicitly says "cache_page takes a single argument: the cache 
timeout, in seconds." [1]

If there is some documentation/tutorial about the key_prefix 
argument, or if this change is going to cause lots of breakage, 
perhaps we'll have to revisit this.

For the time being, you can create a 'cache_page' decorator that 
does what you want very easily, as in the example below.

James B - do we have a place to list things like this i.e. things 
that probably should go in release notes?

> Another question: in 'decorator_from_middleware_with_args'
>  docstring example stated:
> Use like::
> 
> cache_page = decorator_from_middleware(CacheMiddleware)
> 
> Is it correct?

Nope, should be decorator_from_middleware_with_args of course, 
thanks, will fix.

Luke

[1] http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-
cache


-- 
"Pessimism: Every dark cloud has a silver lining, but lightning 
kills 
hundreds of people each year trying to find it." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[Luke Plant]

On Tuesday 22 September 2009 21:31:08 James Bennett wrote:
> On Mon, Sep 21, 2009 at 9:04 PM, Luke Plant 
 wrote:
> > I've committed my change [1], and also replaced _CheckLogin
> > with my method [2] (it was essentially the same method, just
> > generalised).
> 
> The decorator_from_middleware change appears to have broken
> cache_page; I'm now getting "AttributeError: 'int' object has no
> attribute '__module__'" from views which use cache_page.

Bummer, I tried hard not to break it - I added backwards 
compatibility tests for the basic different uses.  Could you produce 
a test case?

Cheers,

Luke 

-- 
"Pessimism: Every dark cloud has a silver lining, but lightning 
kills hundreds of people each year trying to find it." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[James Bennett]

On Mon, Sep 21, 2009 at 9:04 PM, Luke Plant  wrote:
> I've committed my change [1], and also replaced _CheckLogin with my method [2]
> (it was essentially the same method, just generalised).

The decorator_from_middleware change appears to have broken
cache_page; I'm now getting "AttributeError: 'int' object has no
attribute '__module__'" from views which use cache_page.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Luke Plant]

On Tuesday 22 September 2009 12:57:16 Simon Willison wrote:

> The main reason I really like preserving form data is that it means
> CSRF failures are less of a problem, allowing us to be much more
> strict about how they work (setting form tokens to expire after a few
> hours, tying tokens to individual forms etc). This means we can reduce
> the damage caused in the case of a token leaking somehow. This becomes
> particularly important if tokens are going to be used to protect GET
> requests, which some applications may want to do (Flickr have CSRF-
> protected GETs for their logout and change-language links, for
> example) - GET tokens are more likely to leak in other people's
> referrer logs or to intermediate proxies.

I'm not convinced that token leakage is going to be a problem that can easily 
be fixed with timeouts.  Having someone's CSRF token isn't going to be useful 
in an attack unless you know whose it is.  (An attacker could possibly log IP 
addresses against CSRF tokens for later attacks, but that's not likely to be 
very successful).  The obvious and easy way to do any kind of systematic 
attack is to immediately send some attack javascript back in response to any 
incoming request that contains a Referer from an external target along with a 
csrf token. Timeouts are not going to help you there.

> I'd be enormously happy to see that go in as django.shortcuts.render -
> the name may not be as descriptive as render_to_response but for
> something used in practically every view I think terseness should beat
> descriptiveness. 

+1.  Your TemplateResponse class sounds cool, but perhaps too clever to be 
default way of doing things that we would put in documentation.

> 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 about the difficulties with generic views?  
AFAICS, decorators seem slightly worse than a middleware, because you end up 
using them twice e.g.:

@csrf_protect
def some_generic_view(request, **kwargs):
# POST processing here.

@csrf_protect
def my_view(request):
# some stuff here, then
return some_generic_view(request, blah='blah')

With a middleware, you don't have this duplication.  What are the 
disadvantages of the middleware?

> I'd be perfectly happy with a decorator that is also available
> as a middleware.

As it stands, there is a middleware and a decorator created using 
decorator_from_middleware.

> 3. I'd like to include support for CSRF form tokens to expire and be
> locked down to individual forms, as seen in SafeForm. Whether or not
> we actually go for that depends on how likely we are to find a
> solution to the next point...

> 4. I'd love it if we could find a way for developers who care (such as
> myself) to opt-in to CSRF-failing gracefully at the form validation
> level. I'm confident this should be possible, but I don't think it's
> necessary to make it the default behaviour (the CSRF 403 screen is
> probably fine for most people).

If I'm thinking correctly, this isn't too hard:

1) Implement your csrf_protect_form method.  That could easily add your 
requirement to lock down to individual forms and timeouts.  It would need 
cooperation from a new template tag, or additional optional arguments to the 
current template tag. It might also need an additional context processor in 
settings, but as an opt-in solution that's OK. 

I think the solution that manipulates request.POST sounds OK - yes a hack, but 
providing this method is not the default, most people won't have to deal with 
any problems with it.

2) Get the view to be exempted from the normal CSRF checks done by the 
middleware.  Thankfully, we already have not one but two ways of doing this - 
the manual @csrf_exempt decorator on views, and the internal mechanism that 
allows the decorator and middleware to avoid duplicate checking.  
Automatically doing the latter in csrf_protect_form is probably the way ahead.

So, if I'm thinking straight, it should just be a matter of this:

-- views.py ---
@csrf_protect_form(name="myform", timeout=60*60*24)
def my_view(request):
# ...
render(request, 'my_template.html', ...)

-- my_template.html --
{% csrf_token "myform" %}

The only question mark in my mind is what happens with multiple forms on a 
page (e.g. when you have a login box on every page).  It might not be an issue 
- the target of the login box will be another view anyway - but it needs 
thought.

Luke

-- 
"Pessimism: Every dark cloud has a silver lining, but lightning kills 
hundreds of people each year trying to find it." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to 

Re: decorator_from_middleware change

[kmike]

cache_page decorator previously used to have optional 'key_prefix'
argument, not only timeout. Is it gone? Can I use

@cache_page(3600, key_prefix='vasia')
def my_func(request)
   ...

Another question: in 'decorator_from_middleware_with_args' docstring
example stated:
Use like::

cache_page = decorator_from_middleware(CacheMiddleware)

Is it correct?

Or maybe I've missed something?

Please excuse my English :)

On 22 сен, 08:04, Luke Plant  wrote:
> On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote:
>
> > On Mon, Sep 21, 2009 at 1:21 PM, Luke Plant  wrote:
> > > However, decorator_from_middleware is a pain, since it doesn't always
> > > return a an actual decorator, for "historical reasons".  I need to change
> > > this to fix the bug.  Is anyone against this?
>
> > No, I think this is precisely correct. I've been meaning to do exactly
> > what you're proposing for a while myself; just haven't gotten around
> > to it.
>
> > > decorator_from_middleware isn't actually documented anywhere
>
> > I actually avoided documenting it because it's broken. Once you fix
> > it, we should (i.e. I will, if you don't have time) document it.
>
> I've committed my change [1], and also replaced _CheckLogin with my method [2]
> (it was essentially the same method, just generalised).
>
> I haven't added any docs, because I'm not sure it's perfect yet (and also
> because I am lazy and I was mainly working on something else, this just got in
> the way).  In the 'normal' case where you don't need to pass any args to the
> middleware, it is exactly the same (but works for decorating methods now).  In
> the abnormal case, you have to use decorator_from_middleware_with_args, which
> is a pretty ugly name, if explicit.  I don't know if you had other ideas about
> what to do with this.  Changing that name is easy, it's only used by
> cache_page.
>
> Luke
>
> [1]http://code.djangoproject.com/changeset/11586
> [2]http://code.djangoproject.com/changeset/11587
>
> --
> Parenthetical remarks (however relevant) are unnecessary
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Michael Feingold]

That's what we started with. It did not work out. While IronPython (as
well as some other implementations of Python) are available in .Net,
integrating an app written in Python with anything else written in any
other .Net language proved to be a big challenge. You can run a Python
app on .Net platform, but it still lives in its own world

On Sep 22, 1:11 pm, Dj Gilcrease  wrote:
> I dont know all that much about .Net but isnt the point of it that all
> the .Net languages can be used together? eg using C#.Net components in
> a VB.Net app and such.
>
> So why not just use the django template language as is via IronPython
> instead of trying to port it to another language?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Dj Gilcrease]

I dont know all that much about .Net but isnt the point of it that all
the .Net languages can be used together? eg using C#.Net components in
a VB.Net app and such.

So why not just use the django template language as is via IronPython
instead of trying to port it to another language?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

Vaclav,
I think this is less of an issue, because you'd have to switch to another
tab and perform a second operation that generated feedback in the ~200
millisecond window of time between clicking a link and the new page loading.

If you need to support this functionality, you could write a storage to put
the message directly in the URL query string, either by adding it to the
request Location header for HttpResponseRedirect objects or by parsing the
response output and sticking in the extra parameter for all URLs on the
page, but this is obviously pretty ugly and in my mind not worth the effort.

Tobias




On Tue, Sep 22, 2009 at 11:17 AM, veena  wrote:

>
> Hi Tobias,
> good idea with start a wiki page.
>
> I'm not sure if we don't forget one issue.
>
> How about same session (or same cookie sent by browser) with
> simultaneously opened windows of one browser? Then message could
> appear in different window not the right one where we invoke the
> event. Is it a problem? Is only possibility to get of this issue that
> flash app should add a query parameter into redirected url which would
> identify the right window?
>
> Vaclav
>
>
>
>
> On Sep 22, 3:08 am, Tobias McNulty  wrote:
> > On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
> >
> > freakboy3...@gmail.com> wrote:
> >
> > > You also mention that there are a number of other implementations, but
> > > you haven't really given a compelling survey or analysis of the
> > > alternatives - you've just blessed one in particular. Why?
> >
> > I started a wiki page comparing some of the different options out there:
> http://code.djangoproject.com/wiki/SessionMessages
> >
> > Feel free to update with (your messaging backend here).
> >
> > Tobias
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Michael Feingold]

Well, we liked the language, and it is too late anyway - it is
implemented

On Sep 22, 12:18 pm, Anton Bessonov  wrote:
> Hello,
>
> if you need template engine only, then make more sence to port pure
> template engine such as jinja2. IMHO.
>
> Michael Feingold schrieb:
>
>
>
> > I am working on NDjango project. NDjango is a port of Django template
> > language to .Net. It is an open source project. If you are curious you
> > can get all information about it here:www.ndjango.org.
>
> > The reason I am posting here is that while one of our design goals is
> > to keep ndjango templates compatible with django sometimes we cant
> > help it. In such situations even though we cannot follow django
> > scripture to the letter we are trying to follow the spirit.
>
> > The specific question I would love to get some authorative answer to
> > has to do with nested blocks. I am talking about block tags defining
> > new content for blocks defined in a parent template. The django
> > documentation does not asy anything certain about whether is it valid
> > to have such blocks nested inside other tags. In my opinion this
> > should be disallowed because it creates ambiguity and does not really
> > buy anything.
>
> > I posted the same question with more details on our mailing list:
> >http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac776- 
> >Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Anton Bessonov]

Hello,

if you need template engine only, then make more sence to port pure 
template engine such as jinja2. IMHO.

Michael Feingold schrieb:
> I am working on NDjango project. NDjango is a port of Django template
> language to .Net. It is an open source project. If you are curious you
> can get all information about it here: www.ndjango.org.
>
> The reason I am posting here is that while one of our design goals is
> to keep ndjango templates compatible with django sometimes we cant
> help it. In such situations even though we cannot follow django
> scripture to the letter we are trying to follow the spirit.
>
> The specific question I would love to get some authorative answer to
> has to do with nested blocks. I am talking about block tags defining
> new content for blocks defined in a parent template. The django
> documentation does not asy anything certain about whether is it valid
> to have such blocks nested inside other tags. In my opinion this
> should be disallowed because it creates ambiguity and does not really
> buy anything.
>
> I posted the same question with more details on our mailing list:
> http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac7762c764519f83.
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

NDjango - .Net port of Django template langauage

[Michael Feingold]

I am working on NDjango project. NDjango is a port of Django template
language to .Net. It is an open source project. If you are curious you
can get all information about it here: www.ndjango.org.

The reason I am posting here is that while one of our design goals is
to keep ndjango templates compatible with django sometimes we cant
help it. In such situations even though we cannot follow django
scripture to the letter we are trying to follow the spirit.

The specific question I would love to get some authorative answer to
has to do with nested blocks. I am talking about block tags defining
new content for blocks defined in a parent template. The django
documentation does not asy anything certain about whether is it valid
to have such blocks nested inside other tags. In my opinion this
should be disallowed because it creates ambiguity and does not really
buy anything.

I posted the same question with more details on our mailing list:
http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac7762c764519f83.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[veena]

Hi Tobias,
good idea with start a wiki page.

I'm not sure if we don't forget one issue.

How about same session (or same cookie sent by browser) with
simultaneously opened windows of one browser? Then message could
appear in different window not the right one where we invoke the
event. Is it a problem? Is only possibility to get of this issue that
flash app should add a query parameter into redirected url which would
identify the right window?

Vaclav




On Sep 22, 3:08 am, Tobias McNulty  wrote:
> On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
>
> freakboy3...@gmail.com> wrote:
>
> > You also mention that there are a number of other implementations, but
> > you haven't really given a compelling survey or analysis of the
> > alternatives - you've just blessed one in particular. Why?
>
> I started a wiki page comparing some of the different options out 
> there:http://code.djangoproject.com/wiki/SessionMessages
>
> Feel free to update with (your messaging backend here).
>
> Tobias
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: opener.dismissAddAnotherPopup error tinymce

[Alex Gaynor]

On Tue, Sep 22, 2009 at 10:57 AM, Ali Rıza Keleş  wrote:
>
> Hi all,
>
> There is something strange with popups on admin page while this page
> includes tinymce editor.
>
> When i click  to add a relating object, a popup is being opened and i
> enter values and try to save. It is saved but popup is not closed and
> give this error on firefox:
>
> """
> opener.dismissAddAnotherPopup(window,"2",
> "some_value");
>
> Permission denied to get property Window.dismissAddAnotherPopup
> http://local.arha.com.tr/admin/content/author/add/?_popup=1
> Line 1
>
> 
>
> and this error on opera:
>
> """
> opener.dismissAddAnotherPopup(window,"2", "some_value");
>
> Inline script thread
> Error:
> name: ReferenceError
> message: Security error: attempted to read protected variable
> 'dismissAddAnotherPopup'
> stacktrace: n/a; see  opera:config#UserPrefs|Exceptions Have Stacktrace
>
> 
>
> If same page has no tinymce, everything works very well.
>
> My tinymce initializer has
>
> """
> document.domain = 'arha.com.tr'
> tinyMCE.init({
>    mode: "textareas",
> 
> 
>
> """
>
> because media files are being served via another server named as a
> subdomain.
>
> Thanks..
>
> --
> Ali Rıza Keleş,
>
>
>
> >
>

Please don't cross post to django-dev and  django-users, in this case
django-users is the appropriate place for your question.

Alex

-- 
"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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

opener.dismissAddAnotherPopup error tinymce

[Ali Rıza Keleş]

Hi all,

There is something strange with popups on admin page while this page
includes tinymce editor.

When i click  to add a relating object, a popup is being opened and i
enter values and try to save. It is saved but popup is not closed and
give this error on firefox:

"""
opener.dismissAddAnotherPopup(window,"2",
"some_value");

Permission denied to get property Window.dismissAddAnotherPopup
http://local.arha.com.tr/admin/content/author/add/?_popup=1
Line 1



and this error on opera:

"""
opener.dismissAddAnotherPopup(window,"2", "some_value");

Inline script thread
Error:
name: ReferenceError
message: Security error: attempted to read protected variable
'dismissAddAnotherPopup'
stacktrace: n/a; see  opera:config#UserPrefs|Exceptions Have Stacktrace



If same page has no tinymce, everything works very well.

My tinymce initializer has 

"""
document.domain = 'arha.com.tr'
tinyMCE.init({
mode: "textareas",



"""

because media files are being served via another server named as a
subdomain.

Thanks..

--
Ali Rıza Keleş,



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Luke Plant]

On Tuesday 22 September 2009 13:12:51 Russell Keith-Magee wrote:
> On Tue, Sep 22, 2009 at 10:34 AM, Luke Plant  wrote:
> > I've left most of the code itself under django/contrib/csrf because:
> >
> >  1) backwards compatibility with people importing the middleware
> >means we have to leave django/contrib/csrf for some things
> >anyway.
> >  2) In this case, I don't see any great advantage in having stub modules
> >which just import other stuff for backwards compatibility
> 
> This isn't just a "moving deckchairs on the Titantic" thing - I can
> think of at least three good reasons we should be moving the code into
> core modules:
> 
>  * Maintaining the basic contract of django.contrib - that you should
> be able to delete the contrib directory and have Django still work. If
> all the CSRF code is in contrib, this won't be the case.

That doesn't happen to be true at the moment - django.core.context_processors 
depends on django.contrib.auth.  (Not saying that's a good thing, just 
highlighting a fact). But on the other hand, you can at least disable the auth 
context processor, and you can't disable the CSRF one.

The other reason for leaving it as it is at the moment is for the sake of the 
patch - it's much harder to see what's going if you are moving code as well as 
changing it.  If the other devs agree it needs to move to core, I'd prefer to 
do two commits, the first which is just functionality changes - for the sake 
of a comprehensible changelog - and the second that moves the files and 
changes all the imports etc.  To do this properly, we'd also need to 
reorganise docs, fix all the :ref:s etc.

Another problem with moving it all is that is makes upgrade instructions a bit 
more complex (which had just got a bit simpler), but I guess we may as well do 
it all at once.

> I'm reasonably happy with the testing approach you've taken - or, at
> least, I can't think of anything substantially better.
> 
>
> My only comment is that we might want to put an underscore on the
> magic variable (i.e., request._dont_enforce_csrf_checks) to reinforce
> the fact that this really isn't public API.

Good call, I'll fix that. I have mentioned the existence of the attribute in 
the docs in the 'testing' section, but not its name, precisely because it's 
not a public API, but some people might need to know about it in order to fix 
their tests.

> At this point, I'm convinced, mod the minor things I've flagged.
> However, I'd like to see Jacob and Malcolm chime in before this is
> committed.

Agreed.

Luke

-- 
"Pessimism: Every dark cloud has a silver lining, but lightning kills 
hundreds of people each year trying to find it." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Translation problem in from django.utils.translation.trans_real : get_language_from_request()

[Tom Evans]

On Tue, 2009-09-22 at 06:15 -0700, Lewis Taylor wrote:
> I'm not sure if this has been discussed before, my guess is yes,
> however i can't find anything about it.
> 
> I noticed that the get_language_from_request method in trans_real only
> checks whether the django.mo file for a given locale is available in
> the django locale directory, and not an app or projects locale
> folders.
> 
> To me this doesn't make sense, it's not acceptable to have to create a
> language folder in the django conf/locale directory just to make
> django work. If no folder exists there, it will revert back to
> settings.LANGUAGE_CODE.
> 
> Does anyone have any particular reason why this approach has been
> chosen?
> 
> Thanks
> 
> Lewis
> 

It is a limitation of gettext I believe. It is documented here[1] and
here[2].

Cheers

Tom

[1] http://docs.djangoproject.com/en/dev/topics/i18n/#id1
[2]
http://docs.djangoproject.com/en/dev/topics/i18n/#locale-middleware-notes



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Translation problem in from django.utils.translation.trans_real : get_language_from_request()

[Lewis Taylor]

I'm not sure if this has been discussed before, my guess is yes,
however i can't find anything about it.

I noticed that the get_language_from_request method in trans_real only
checks whether the django.mo file for a given locale is available in
the django locale directory, and not an app or projects locale
folders.

To me this doesn't make sense, it's not acceptable to have to create a
language folder in the django conf/locale directory just to make
django work. If no folder exists there, it will revert back to
settings.LANGUAGE_CODE.

Does anyone have any particular reason why this approach has been
chosen?

Thanks

Lewis

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Jacob Kaplan-Moss]

On Tue, Sep 22, 2009 at 7:12 AM, Russell Keith-Magee
 wrote:
> At this point, I'm convinced, mod the minor things I've flagged.
> However, I'd like to see Jacob and Malcolm chime in before this is
> committed.

I've mostly stayed out of the discussion because I haven't had much
helpful to say that isn't being better expressed by someone else. But
for the record I am following this closely, and it seems to me that
y'all are narrowing in on a pretty good solution.

That is, making CSRF protection built-in seems to be the best
approach. I did a quick survey of other web frameworks' CSRF
protection, and found:

* CSRF protection is an optional component (something like SafeForm)
in Pylons and TurboGears, and nobody seems to use it (judging by the
lack of documentation, lack of examples, and lack of questions about
it on mailing lists)
* CSRF protection is optional (again, something like SafeForm) in
Symfony and CakePHP, and nobody seems to use it (similar criteria).
* CSRF protection is a built-in-but-optional bit in Zend (you can add
a "csrf field" any form to get automatic CSRF protection), and it
seems to be used regularly.
* Rack::CSRF provides middleware-level CSRF protection to Rack apps,
and seems to be used with microframeworks (e.g. Sinatra) regularly.
* Ruby on Rails provides built-in, completely transparent CSRF
protection, and nearly everyone uses it.

Based on this quick-and-dirty evaluation, it seems the unifying factor
is that nobody really uses CSRF protection unless (a) it's built in or
(b) it's too late.

Or, put another way, how many people got template auto-escaping right
before we made it automatic?

I'm gonna give Luke's latest a try tonight if I can, but it looks pretty good.

Jacob

PS: I'm with Simon that we need a better shortcut for
render-with-request-context. I'm gonna have to think a bit more about
what that should be, though.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[James Bennett]

On Tue, Sep 22, 2009 at 6:57 AM, Simon Willison  wrote:
> Yeah, I'd like a builtin shortcut like that - used like this:
>  render(request, 'template_name.html', {'foo':bar })
> The biggest problem, for me, is finding a decent name - since
> 'render_to_response' is already taken.  Maybe something as vague as
> 'standard_response' would work.

FWIW most people I know seem to be using the direct_to_template
generic view for this; its argument signature is close to what's
desired, and it uses RequestContext.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Russell Keith-Magee]

On Tue, Sep 22, 2009 at 10:34 AM, Luke Plant  wrote:
>
> OK, you convinced me.  I really would rather this wasn't baked in, but given
> the migration issues and the fact that it is security related, I guess I can
> stomach it.
>
> I've updated the patch [1] to move things to builtin functionality.  I also
> had to fix some bugs to get the csrf_protect decorator working for methods,
> which are in trunk already.
>
> I've left most of the code itself under django/contrib/csrf because:
>
>  1) backwards compatibility with people importing the middleware
>    means we have to leave django/contrib/csrf for some things
>    anyway.
>  2) In this case, I don't see any great advantage in having stub modules
>    which just import other stuff for backwards compatibility

This isn't just a "moving deckchairs on the Titantic" thing - I can
think of at least three good reasons we should be moving the code into
core modules:

 * Maintaining the basic contract of django.contrib - that you should
be able to delete the contrib directory and have Django still work. If
all the CSRF code is in contrib, this won't be the case.

 * Making it clear that this really is a core feature - it's a core
template tag, a core middleware, and a core context. Just like the URL
is part of the UI for a web app, the module namespace is part of the
UI for a library like Django.

 * For deprecation purposes, we can say that the whole contrib.csrf
module will be deprecated in 1.4 (at which point, CSRF will be an
entirely core feature).

>  3) I really can't be bothered to change all the imports
>    at this point in time!

I can understand this as interim measure while we get consensus with
other core developers, but I'd be -1 to leaving the code as is for the
final commit.

> I moved the template tag itself to core code, because it was causing import
> cycles otherwise, and there are no backwards compatibility issues, nor does it
> add any actual imports of contrib code to core.

Which reinforces the point. Some of the code is going to be in core.
Do you want to write the documentation explaining why some code is in
contrib and some isn't?

> I think the patch now addresses all your/our concerns:

Agreed.

> I fixed the tests by a custom attribute on request objects that tells the
> middleware/decorator to not actually reject requests.  This is better than
> disabling completely, because it means that the middleware will still send
> cookies etc., and it's always good to have tests as close as possible to the
> real code.  The test client adds the custom attribute to HttpRequests after it
> has created them.  I had to add the attribute in one other place in the code
> as well - a test that was manually calling a view function that had
> csrf_protect applied.
>
> This method of fixing tests was also the best for testing the CSRF middleware
> - globally mocking the middleware out would have made it hard to test the
> middleware itself!

I'm reasonably happy with the testing approach you've taken - or, at
least, I can't think of anything substantially better.

My only comment is that we might want to put an underscore on the
magic variable (i.e., request._dont_enforce_csrf_checks) to reinforce
the fact that this really isn't public API.

> Docs are all updated, all tests passing etc.
>
> If people are happy for this to go in, it would be very helpful if other
> people could have a go updating their apps and give the general docs/upgrade
> instructions/tutorials a good check after I commit it.  I can't easily do
> checks like that, because I just won't spot the holes after having the code in
> my head for so long.

Whew. Well, that was a year well spent :-)

At this point, I'm convinced, mod the minor things I've flagged.
However, I'd like to see Jacob and Malcolm chime in before this is
committed.

> The only thing left is a nicer render_to_response shortcut for using
> RequestContext, which is a refinement we can add later.

Agreed, and it's a mostly orthogonal change anyway.

Russ %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Simon Willison]

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 attack.
>
> So - let's have both. A middleware enabled by default protects the
> rest of the views. However, we can also have a view decorator lets us
> protect admin (and other contrib apps) explicitly.

I'm a big +1 for that.

>  * The SafeForm method of reporting errors as part of form validation
> is much nicer than the 403 page, IMHO. However, I'm not sure what we
> can do to provide form-level CSRF error handling without introducing a
> whole bunch of other fragility.

I've been scratching my head over this one - inline error messages and
(in particular) not using a form submission are the single thing that
makes me favour SafeForm over the template tag approach for my own
stuff. That's why I designed SafeForm to complement the forms
framework - correctly handling CSRF feels like a form validation
problem to me, and reusing Django's redisplay-the-form-with-errors
flow is a really neat thing to be able to do.

The main reason I really like preserving form data is that it means
CSRF failures are less of a problem, allowing us to be much more
strict about how they work (setting form tokens to expire after a few
hours, tying tokens to individual forms etc). This means we can reduce
the damage caused in the case of a token leaking somehow. This becomes
particularly important if tokens are going to be used to protect GET
requests, which some applications may want to do (Flickr have CSRF-
protected GETs for their logout and change-language links, for
example) - GET tokens are more likely to leak in other people's
referrer logs or to intermediate proxies.

There is a way we could achieve form validation, but it isn't
particularly pretty. Say the CSRF check is performed by a decorator
(which has an accompanying middleware for applying that decorator to
the entire site). The problem we have is that in the case of a
failure, the fact that the check failed needs to be communicated
through to the form /inside/ that view. The form doesn't have access
to the request, so we're stuck.

But... the form does have access to request.POST. The dirty solution
would be for the decorator to rewrite request.POST to include a new
key:

request.POST.mutable = True
request.POST['__validation_must_fail'] = True
request.POST.mutable = False

django.forms.Form.is_valid() could then be hard-coded to always fail
if '__validation_must_fail' is present in the data dictionary. I've
avoided including the string "csrf" in the form key because this
feature feels like it could be useful for other things as well (I
might use it for testing out my form error styles). I don't think it's
a security vulnerability - if someone fakes a "__validation_must_fail"
key in their own submission I don't see that there's anything bad they
can do.

It's a pretty monstrous hack, but it would allow a CSRF protecting
decorator to inform a form inside a view that the check had failed and
the form should not validate.

I wouldn't suggest this as the default behaviour for the overall CSRF
protection scheme - it would leave hand-rolled forms unprotected, and
I imagine there are new error cases it would introduce. That said, it
would placate users like myself who want the nicer invalidation
messages and are willing to do a bit of work to achieve them. Maybe
something like this:

@csrf_protect
def view(request):
"""A view that fails the CSRF check with a full page 403,
as seen in Luke's current middleware"""

@csrf_protect_form
def view(request):
"""A view that won't 403 directly, but will ensure that any
calls to form.is_valid() fail due to the presence of a
__validation_must_fail key"""

Thinking more pie-in-the-sky-ly, maybe this approach could be
generalised further, to specify a mechanism by which request.POST can
include a set of validation errors that should be shown by the form.
This might have other uses in things like wizards where validation
errors may want to persist between different pages.

>  * The requirement for using RequestContext is somewhat annoying. I
> can't see any obvious way to piggyback CSRF data onto the base Context
> itself, but perhaps we can make RequestContext a more prominent
> default? The most obvious solution here is to make render_to_response
> use RequestContext by default.

Yes, yes and thrice yes - my only complaint about RequestContext is
how horrible the syntax for using it is:

render_to_response('template.html', {
'name': 'Foo',
'blah': 'baoenuth',
}, context_instance=RequestContext(request))



Yeah, I'd like a builtin shortcut like that - used like this:
  render(request, 'template_name.html', {'foo':bar })
The biggest problem, for me, is finding a decent name - since