Could you have a hybrid that took this:
{% json data id="initial-data" var="variable_name" %}
And did this:
<script type="application/json" id="initial-data">
{"foo": "bar"}
</script>
<script type="application/javascript">
var totally_random_uuid = document.getElementById('initial-data');
var variable_name = JSON.parse(totally_random_uuid.textContent ||
totally_random_uuid.innerText);
</script>
Maybe omitting the second script block if no var is supplied, and
generating a random UUID for the id for the data block if no id is supplied?
On Tuesday, 10 June 2014 19:31:29 UTC+2, David Evans wrote:
>
> Thanks Chris. Yes, I do share your feeling that the declare-a-global-var
> way of doing things is bit icky. My reason for wanting to support it was
> that in order to use the "proper" method you need to be able to parse JSON
> and that means that if you want to support older browsers you've now got a
> dependency on some external JSON parsing library.
>
> Also, although I called them different "modes" of operation, they're
> really just minor syntactic variants from the point of view of the template
> tag so it seemed a bit of shame to force the user down one route when the
> other could be so easily supported. I didn't want a situation where people
> ended up using another, insecure method because the official method forced
> them to do things in a way that seemed too complicated.
>
> That said, I'd be very open to just supporting the CSP-compatible method
> if that was the general view.
>
>
> On 24 May 2014 06:37, Chris Beaven <[email protected] <javascript:>>
> wrote:
>
>> I like the idea, I've been using a custom script that does the first mode
>> of this tag nearly exactly the same way (with the same security escaping).
>>
>> Not the biggest fan of the second mode of operation since like you say,
>> it's not compatible with strict CSP. Why not just encourage people to do it
>> the correct way? Having a separate mode of operation for the same tag
>> necessary, perhaps it'd be less controversial just getting the first mode
>> in?
>>
>> A related side note, it's good practice for JS templates to live within
>> script blocks too. I have {% scriptblock %}{% endscriptblock %} that is
>> sits next to {% jsonblock %} in my custom library since it uses the same
>> escaping methods.
>>
>>
>>
>> On Tuesday, May 13, 2014 10:03:43 PM UTC+12, David Evans wrote:
>>
>>> There was some discussion previously (see https://code.djangoproject.
>>> com/ticket/17419) of adding a JSON encoding filter to Django. This was
>>> rejected as being impossible (or very difficult) to do securely. However
>>> the requirement to embed JSON in an HTML page is quite a common one, and
>>> it's easy to get wrong and create XSS vulnerabilities. We should make it
>>> easy for people to do the right thing.
>>>
>>> I propose a ``json`` tag (implementation here
>>> <https://gist.github.com/evansd/41ea9dfc90d87f6afde1>) which outputs
>>> the entire script element as well as the JSON data. By enforcing the
>>> context in which in the JSON is output, it's possible to escape it securely.
>>>
>>> It would have two basic modes of operation. The first, and recommended,
>>> one would look like this:
>>>
>>> {% json data id="initial-data" %}
>>>
>>>
>>> and would produce HTML like this:
>>>
>>> <script type="application/json" id="initial-data">
>>> {"foo": "bar"}
>>> </script>
>>>
>>>
>>> The resulting data would be accessed in JavaScript like this:
>>>
>>> var el = document.getElementById('initial-data');
>>> var initialData = JSON.parse(el.textContent || el.innerText);
>>>
>>>
>>> This is compatible with a strict Content Security Policy which prohibits
>>> all in-page script execution and maintains a clean separation between
>>> passive data and executable code.
>>>
>>> The second mode of operation would look like this:
>>>
>>> {% json data var="initialData" %}
>>>
>>>
>>> and would produce HTML like this:
>>>
>>>
>>> <script type="application/javascript">
>>> var initialData = {"foo": "bar"};
>>> </script>
>>>
>>>
>>> This isn't compatible with strict CSP but it is perhaps simpler and more
>>> familiar to many developers, and not fundamentally insecure, so it should
>>> still be supported.
>>>
>>> Of course, the key issue is whether this can be done securely. In the
>>> gist below is a proposed implementation with links to the sources I've used
>>> to ensure I'm escaping things correctly:
>>> https://gist.github.com/evansd/41ea9dfc90d87f6afde1
>>>
>>> If people are happy with it then I can create a proper pull request with
>>> docs etc.
>>>
>>> Thanks,
>>>
>>> Dave
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/RNMs5YbKeRY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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/1d3f399a-dbc3-4f2f-b9e3-01c370384573%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/1d3f399a-dbc3-4f2f-b9e3-01c370384573%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
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/a46d3864-9417-4f13-8f0b-8f2f974ddb7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
