+1 to not having to add (and then remove later) a {% load %} tag to every
template - that was seriously dull with the URL change.
Marc
On 20 February 2017 at 11:42, Luke Plant <l.plant...@cantab.net> wrote:
> On 19/02/17 12:55, Adam Johnson wrote:
>
> +1 for more obvious errors, silently changing the behaviour could indeed
> lead to unconsidered security holes like
>
> {% if user is None %}
> non-sensitive information
> {% else %}
> sensitive information
> {% endif %}
>
> ...which doesn't seem like an unrealistic template snippet. We all know
> variables can go missing in refactorings.
>
> Another option, perhaps not feasible to implement, would be deprecating
> the old behaviour, similar to the previous change in url with something
> like:
>
> {% load undefined_vars from future %}
>
>
> I agree there are a lot of potential security/correctness issues with
> this, it is potentially quite a big change (though very helpful IMO).
>
> A different approach to introducing it might be a setting, possibly an
> option to the Django template engine instead - https://docs.djangoproject.
> com/en/1.10/ref/settings/#std:setting-TEMPLATES-OPTIONS . I think this
> would be more appropriate for something that is more of a global behaviour
> issue, more practical than having to add hundreds of 'load from future'
> tags, plus it would then parallel other similar settings like
> 'string_if_invalid'. In the next version of Django the option would default
> to False (i.e. old behaviour), but raise a deprecation warning, in future
> versions it would simply be True, and raise an error if someone tries to
> pass False (but allow True, for the sake of apps that are spanning multiple
> Django versions).
>
> This would allow people to test their site with the new mechanism and have
> time to fix issues, which can be especially important for 3rd party Django
> apps.
>
> Ideally there would be some way to instrument code and see if the output
> would be different with the new behaviour, but I can't think of an easy way
> to do this.
>
> Luke
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/496fa4a8-b902-657a-92c2-9766bfff8a26%40cantab.net
> <https://groups.google.com/d/msgid/django-developers/496fa4a8-b902-657a-92c2-9766bfff8a26%40cantab.net?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 (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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1GmpDk8ByyEW2tjpstV9OpfPNokfGKNgufEmDWFhi27hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
