Re: Why is the CSRF template context processor hardcoded?

2014-09-20 Thread Russell Keith-Magee 
Hi Aymeric,

As I recall, the reasoning was:

a) CSRF should almost always be on anyway

b) The cost of having the CSRF token in place if you actually aren't using
CSRF was pretty low

c) Template documentation essentially says "put {% csrf_token %} in your
template always; if it's hardcoded, there's no "if CSRF is enabled"
question required.

d) If templates are being distributed as part of the third party package,
you want to make sure they work out of the box

e) We didn't want have two moving parts to enable it (middleware *and*
context processor).

Russ %-)


On Sun, Sep 21, 2014 at 5:16 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I'm wondering why django.template.context defines:
>
> # We need the CSRF processor no matter what the user has in their settings,
> # because otherwise it is a security vulnerability, and we can't afford to
> leave
> # this to human error or failure to read migration instructions.
> _builtin_context_processors = ('django.core.context_processors.csrf',)
>
> and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.
>
> If the template context processor was missing, {% csrf_token %} wouldn't
> output anything in templates. Then it would be impossible to submit forms,
> but that would be a bug.
>
> The CSRF context processor even has a branch that returns NOTPROVIDED. {%
> csrf_token %} specifically tests for this case and doesn't output anything
> when it happens.
>
> So I fail to find the security vulnerability the comment talks about. I
> didn't find the answer in:
> -
> https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
> - https://code.djangoproject.com/ticket/9977
> - https://code.djangoproject.com/wiki/CsrfProtection
>
> Does anyone remembers the reasoning?
>
> Thanks,
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9EFBA6B8-F6F3-4DD4-9911-2B13906BEC2C%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848uH6B_GmM58FLX1pSw8ciXW%2BK-MqY%2BGsnMQdzB8sA2Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why is the CSRF template context processor hardcoded?

2014-09-20 Thread Aymeric Augustin 
Hello,

I'm wondering why django.template.context defines:

# We need the CSRF processor no matter what the user has in their settings,
# because otherwise it is a security vulnerability, and we can't afford to leave
# this to human error or failure to read migration instructions.
_builtin_context_processors = ('django.core.context_processors.csrf',)

and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.

If the template context processor was missing, {% csrf_token %} wouldn't output 
anything in templates. Then it would be impossible to submit forms, but that 
would be a bug.

The CSRF context processor even has a branch that returns NOTPROVIDED. {% 
csrf_token %} specifically tests for this case and doesn't output anything when 
it happens.

So I fail to find the security vulnerability the comment talks about. I didn't 
find the answer in:
- 
https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
- https://code.djangoproject.com/ticket/9977
- https://code.djangoproject.com/wiki/CsrfProtection

Does anyone remembers the reasoning?

Thanks,

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9EFBA6B8-F6F3-4DD4-9911-2B13906BEC2C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Some thoughts on Django Form Wizard

2014-09-20 Thread Julian Gindi 
Hey there,

I have been spending a lot of time working with FormWizard recently and had 
a few ideas on where it might be able to be improved. Here are some of my 
thoughts, let me know if these are things the community would find 
interesting.

1) More seamless navigation between steps of the for. For me, going back 
and forth seemed like a three step process: Handling the submitted data, 
updating the template context and grabbing the correct form, and finally 
redirecting the user to the intended step. I was wondering if these steps 
could be reduced and the ability to skip or navigate easily between steps 
because a little simpler. 

2) Saving partially submitted data. I know there are ways to do this 
already, but again, to me it's about baking this functionality into the 
FormWizard a bit more. I would allow users to partially submit data and 
"save for later". Once they reach the final page, all the form data would 
not submit until all fields have been filled out.

Just some thoughts. Let me know what you think.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89182909-1875-44cb-ab07-7f7625e2757d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTTP/2 and WSGI

2014-09-20 Thread Ryan Hiebert 
Being the idealist I am, I hope we can find a way to rid ourselves of the pain 
of cgi. I'd be more than willing to help, but my help would probably be more of 
a hindrance because of the limited exposure I've had with developing wsgi. 
However, I did want to register my support to those looking to change things.

Thank you for working on this.

Sent from my iPhone

> On Sep 20, 2014, at 2:34 AM, Aymeric Augustin 
>  wrote:
> 
> 2014-09-20 6:42 GMT+02:00 Russell Keith-Magee :
>> 
>> Historically, Django hasn't been deeply involved in process of developing 
>> WSGI and related standards; this is an opportunity for us to change that 
>> trend.
> 
> To me the situation is pretty clear.
> 
> Either this line will win: 
> https://mail.python.org/pipermail/web-sig/2014-September/005257.html
> 
> Then maybe there's a chance we'll end up with a gateway interface that 
> doesn't make every framework undo the transformations performed by the 
> gateway to get back to the HTTP stuff.
> 
> Or that line will: 
> https://mail.python.org/pipermail/web-sig/2014-September/005258.html.
> 
> Then we'll carry the legacy of PEP  and WSGI will remain the bastard 
> child of CGI that it is and we'll keep doing stuff like value = 
> value.encode(ISO_8859_1).decode(UTF_8) and we'll want to stab ourselves 
> whenever we look at WSGI-related code.
> 
> I'll get in touch with Graham. For the record I once started writing a PEP 
> for a better WSGI, then I read web-sig and I carefully archived my draft 
> without telling anyone.
> 
> -- 
> Aymeric.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CANE-7mXtravDT%2BLhN0-hS9h4uewSGVXqWdEuD-oz%3DLLgSV5%2B1A%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29FFE9AA-823C-4D5F-94A7-D86537157E43%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading timezone naive data into your test database with USE_TZ = True

2014-09-20 Thread Aymeric Augustin 
Hi Robert,

On 17 sept. 2014, at 01:54, Robert Rollins  wrote:

> I have a legacy database from which my Django application must migrate data 
> into a Django database. The relevant dates fields are actually TIMESTAMP 
> columns in the database, but something (perhaps Django, or python's MySQL 
> driver?) loads these columns as timezone naive datetime objects, rather than 
> integers. So I wrote my migration code under the assumption that the dates 
> coming out of the legacy database are timezone naive.

Unfortunately, you're running into a known and documented limitation of time 
zone support in Django:
https://docs.djangoproject.com/en/dev/ref/databases/#timestamp-columns

> It seems like having USE_TZ = True is forcibly making my fixture dates 
> timezone aware, which I don't want. But USE_TZ will be True during the actual 
> migration, so I can't just turn it off during the tests. So how can I load 
> timezone naive dates into my test database?


Would it be possible to:
- use USE_TZ = False during the migration process,
- convert datetimes to the proper timezone while migrating,
- then switch back to USE_TZ = True?

Based on my understanding of your situation, I believe this is the easiest path 
if you want to use the ORM.

Alternatives include:
- pull data with raw SQL queries -- cursor.execute(...) -- and insert it into 
the main database through Django,
- export data to a CSV file and re-import that.

I hope this helps,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/414F70F4-01F2-41B8-A836-42596DAAA8C3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: HTTP/2 and WSGI

2014-09-20 Thread Aymeric Augustin 
2014-09-20 6:42 GMT+02:00 Russell Keith-Magee :
>
> Historically, Django hasn't been deeply involved in process of developing
> WSGI and related standards; this is an opportunity for us to change that
> trend.
>

To me the situation is pretty clear.

Either this line will win:
https://mail.python.org/pipermail/web-sig/2014-September/005257.html

Then maybe there's a chance we'll end up with a gateway interface that
doesn't make every framework undo the transformations performed by the
gateway to get back to the HTTP stuff.

Or that line will:
https://mail.python.org/pipermail/web-sig/2014-September/005258.html.

Then we'll carry the legacy of PEP  and WSGI will remain the bastard
child of CGI that it is and we'll keep doing stuff like value = value.encode
(ISO_8859_1).decode(UTF_8) and we'll want to stab ourselves whenever we
look at WSGI-related code.

I'll get in touch with Graham. For the record I once started writing a PEP
for a better WSGI, then I read web-sig and I carefully archived my draft
without telling anyone.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mXtravDT%2BLhN0-hS9h4uewSGVXqWdEuD-oz%3DLLgSV5%2B1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.