On 08/27/2013 09:41 PM, Dirk Müller wrote:
Hi Tony,
disable/uninstall/neuter this "feature." Also, I cannot find any other web framework which uses this approach to fighting XSS attacks (and AFAIK the XSS problem has been mostly addressed by practically everyone in some way).
Please note that XSS and CSRF are two completely different things. I assume from your description that you're indeed talking about CSRF. There are indeed two ways to implement CSRF protection in django, using cookies or using hidden form values using POST.
And there's the X-CSRFToken HTTP header.
given that the latter is largely inconvenient, CSRF cookies is the de-facto standard used by most web frameworks.
Well, not really. It is true that people often forget to add the CSRF token to their forms when they write them by hand. That's why form generation frameworks for major web frameworks are so handy. But form values are mostly annoying with AJAX POST requests for which everybody has his personal hack [1]. BTw. it's actually the default method in both Rails and the Django communities. And surprise, surprise, even Horizon does that: % grep -r csrf_token . --exclude-dir=.venv --exclude-dir=.tox ./horizon/templates/horizon/common/_workflow.html: <form {{ workflow.attr_string|safe }} action="{{ workflow.get_absolute_url }}" {% if add_to_field %}data-add-to-field="{{ add_to_field }}"{% endif %} method="POST">{% csrf_token %} ./horizon/templates/horizon/common/_modal_form.html: <form id="{% block form_id %}{% endblock %}" autocomplete="{% block autocomplete %}{% endblock %}" class="{% block form_class %}{% endblock %}" action="{% block form_action %}{% endblock %}" method="{% block form-method %}POST{% endblock %}" {% if add_to_field %}data-add-to-field="{{ add_to_field }}"{% endif %} {% block form_attrs %}{% endblock %}>{% csrf_token %} ./horizon/templates/horizon/common/_data_table.html: {% if needs_form_wrapper %}<form action="{{ table.get_absolute_url }}" method="POST">{% csrf_token %}{% endif %}
I assume there is something wrong with the specific way the cookies are set though or of some specific incompatibility.
Well, Lynx... I guess the incompatibility is called JavaScript support. I heard "links" has it :-)
I'm not seeing this problem using other web browsers, although I'm in the process of determining if the <same> problem I ran into in Folsom using the Quickstart script still exists in Grizzly (initial appearance is the same although too early to be sure) about not setting up the keyring properly for SSL certificates. If I do determine it's the same problem, then it's almost certainly a problem with the SUSE/openSUSE build since I never saw the problem in Devstack 6 months ago and didn't see the problem on a RH which was configured with their Quickstart last night.
That might very well be the case. if you could share the details of this problem we could be looking at what our setup scripts are doing wrongly.
Thanks, Dirk
[1] https://github.com/openSUSE/open-build-service/commit/180a2d2b6e3f2ef627227e... -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)