Re: Template handling of undefined variables
Actually, I can imagine that the option might be worth keeping permanently.
I think both the "exception on use of undefined" and "treat undefined as
different from all other objects" would both be valid modes. Treating
undefined as None is probably only justifiable for backward compatibility,
though. I'll rework the patch to support a setting unless anyone comes up
with a better idea.
I'm not sure I like the proposal of throwing an exception on `if` but not
in other cases. It seems more consistent to just raise an exception on any
use of an undefined variable.
Tim
On Monday, 20 February 2017 11:54:37 UTC, Marc Tamlyn wrote:
>
> +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 > 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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
>>
>>
>> .
>>
>> 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/b627d2ab-da52-4cbb-b32d-e54df5fd37b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
I think any use of undefined template variables should raise an exception.
In the long run, keeping a setting to allow some other behavior seems
confusing and, considering the case of templates that might be reused in
different projects with different settings, even dangerous.
On Saturday, February 25, 2017 at 9:54:10 AM UTC-5, Tim Martin wrote:
>
> Actually, I can imagine that the option might be worth keeping
> permanently. I think both the "exception on use of undefined" and "treat
> undefined as different from all other objects" would both be valid modes.
> Treating undefined as None is probably only justifiable for backward
> compatibility, though. I'll rework the patch to support a setting unless
> anyone comes up with a better idea.
>
> I'm not sure I like the proposal of throwing an exception on `if` but not
> in other cases. It seems more consistent to just raise an exception on any
> use of an undefined variable.
>
> Tim
>
> On Monday, 20 February 2017 11:54:37 UTC, Marc Tamlyn wrote:
>>
>> +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 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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
>>>
>>>
>>> .
>>>
>>> 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/e32a0ad9-50bf-4b8c-8ac5-1cd9ce2b0eda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham wrote: > I think any use of undefined template variables should raise an exception. > In the long run, keeping a setting to allow some other behavior seems > confusing and, considering the case of templates that might be reused in > different projects with different settings, even dangerous. > I think I'm confused...Django templates have allowed use of undefined variables and documented their use as evaluating to the empty string for as long as I recall. Wouldn't a change to instead raise exceptions be a major backwards-incompatibility? https://docs.djangoproject.com/en/1.7/topics/templates/#variables said "If you use a variable that doesn’t exist, the template system will insert the value of the TEMPLATE_STRING_IF_INVALID setting, which is set to '' (the empty string) by default." https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables has refined that doc to note that the behavior is slightly different in some tags. Are we really considering changing this behavior to now raise exceptions? -- 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/CACS9rad-TtehoMxLCruRv5M8yT_GHH-nZxvBETcVaRrLfHVkUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
My proposal was only for the use of undefined variables in template tags. I
didn't realize that the behavior of undefined variables in some tags
resolving to None is documented, but I still think it's a useful change to
raise an exception instead. The philosophy that template tags shouldn't
raise exceptions is more unhelpful than helpful in my experience. I think
the change would be consistent with the deprecation that starts in Django
1.11 to change {% include %} not to silencing exceptions and render an
empty string, for example.
On Saturday, February 25, 2017 at 4:44:30 PM UTC-5, Karen Tracey wrote:
>
> On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham > wrote:
>
>> I think any use of undefined template variables should raise an
>> exception. In the long run, keeping a setting to allow some other behavior
>> seems confusing and, considering the case of templates that might be reused
>> in different projects with different settings, even dangerous.
>>
>
> I think I'm confused...Django templates have allowed use of undefined
> variables and documented their use as evaluating to the empty string for as
> long as I recall. Wouldn't a change to instead raise exceptions be a major
> backwards-incompatibility?
>
> https://docs.djangoproject.com/en/1.7/topics/templates/#variables said
> "If you use a variable that doesn’t exist, the template system will insert
> the value of the TEMPLATE_STRING_IF_INVALID setting, which is set to ''
> (the empty string) by default."
>
>
> https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables
>
> has refined that doc to note that the behavior is slightly different in
> some tags.
>
> Are we really considering changing this behavior to now raise exceptions?
>
--
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/8b260b00-7921-4977-9521-f61f073e717b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Fellow Report - Febraury 25, 2017
Triaged --- https://code.djangoproject.com/ticket/27860 - Changing a CharField to a ForeignKey crashes when migrating in PostgreSQL (accepted) https://code.djangoproject.com/ticket/27858 - Stop read-only management commands from attempting to create a django_migrations table (accepted) https://code.djangoproject.com/ticket/27864 - Limit the number of terms in an admin search (accepted) https://code.djangoproject.com/ticket/27870 - Clean up ManagementUtility.autocomplete() (fixed) https://code.djangoproject.com/ticket/27871 - Django keeps making the same migration over and over again (needsinfo) https://code.djangoproject.com/ticket/27875 - Manager inheritance documentation doesn't mention manager_inheritance_from_future (fixed) https://code.djangoproject.com/ticket/27878 - Move to Python 3 shebangs (fixed) (fixed) Authored -- https://github.com/django/django/pull/8103 - Refs #25187 -- Fixed AuthBackend.authenticate() compatibility for signatures that accept a request kwarg. https://github.com/django/django/pull/8117 - Refs #27025 -- Removed unneeded sqlite3 transaction management workaround in Python 3.6. Reviewed/committed -- https://github.com/django/django/pull/8079 - Fixed #27856 -- Improved accuracy of date subtraction on PostgreSQL. https://github.com/django/django/pull/7517 - Refs #11964, #26167 -- Made Expressions and Q objects deconstructible. https://github.com/django/django/pull/8110 - Fixed #27879 -- Fixed crash if enclosures aren't provided to Atom1Feed.add_item(). https://github.com/django/django/pull/8102 - Fixed #27874 -- Fixed URL namespace warning (urls.W005) for nested namespaces. https://github.com/django/django/pull/8101 - Fixed #27873 -- Fixed crash in setup_test_environment() if ALLOWED_HOSTS is a tuple. https://github.com/django/django/pull/8097 - Fixed #27836 -- Allowed FileSystemStorage.delete() to remove directories. https://github.com/django/django/pull/8075 - Added tests for GenericSitemap instance attributes. -- 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/77c87994-9779-4abe-8aa4-69b1606589f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
On Saturday 25 February 2017 16:28:17 Tim Graham wrote: > My proposal was only for the use of undefined variables in template > tags. I didn't realize that the behavior of undefined variables in > some tags resolving to None is documented, but I still think it's a > useful change to raise an exception instead. The philosophy that > template tags shouldn't raise exceptions is more unhelpful than > helpful in my experience. I sincerely hope that the change only affects DEBUG mode (including the include change). But once the templates are validated and working as they should, they should not generate exceptions unless Django provides a way to catch them. For example, if a service is unavailable that makes up a small part of a page, I do not want the whole page to crash or information to leak. -- Melvyn Sopacua -- 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/2409576.D1JWrnJBHJ%40devstation. For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
Tim and others,
+1 for raising an exception.
Specifically...
I agree that use of undefined variables should raise an exception.
The incompatibility with previous versions will mostly catch errors
that have been going undetected.
Personally, I find it very hard to detect such bugs when reviewing
code written by myself or other team members, especially since we
make heavy use of template inheritance, and we reuse the same
templates from multiple views. So, it's not easy to spot a case
where we forgot to pass a value to a template.
I think Django should at least offer this as an option.
--Fred
Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 2/25/17 7:28 PM, Tim Graham wrote:
My proposal was only for the use of undefined variables in template
tags. I didn't realize that the behavior of undefined variables in
some tags resolving to None is documented, but I still think it's a
useful change to raise an exception instead. The philosophy that
template tags shouldn't raise exceptions is more unhelpful than
helpful in my experience. I think the change would be consistent with
the deprecation that starts in Django 1.11 to change {% include %} not
to silencing exceptions and render an empty string, for example.
On Saturday, February 25, 2017 at 4:44:30 PM UTC-5, Karen Tracey wrote:
On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham > wrote:
I think any use of undefined template variables should raise
an exception. In the long run, keeping a setting to allow some
other behavior seems confusing and, considering the case of
templates that might be reused in different projects with
different settings, even dangerous.
I think I'm confused...Django templates have allowed use of
undefined variables and documented their use as evaluating to the
empty string for as long as I recall. Wouldn't a change to instead
raise exceptions be a major backwards-incompatibility?
https://docs.djangoproject.com/en/1.7/topics/templates/#variables
said "If you use a variable that doesn’t exist, the template
system will insert the value of the TEMPLATE_STRING_IF_INVALID
setting, which is set to '' (the empty string) by default."
https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables
has refined that doc to note that the behavior is slightly
different in some tags.
Are we really considering changing this behavior to now raise
exceptions?
--
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/8b260b00-7921-4977-9521-f61f073e717b%40googlegroups.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8ff7366a-b8ba-5ac3-566d-6e6258e4ed81%40bristle.com.
For more options, visit https://groups.google.com/d/optout.
Re: Template handling of undefined variables
On Sat, Feb 25, 2017 at 8:21 PM, Fred Stluka wrote:
> I agree that use of undefined variables should raise an exception.
> The incompatibility with previous versions will mostly catch errors
> that have been going undetected.
>
I disagree, unless you are limiting this change specifically to arguments
to non-builtin template tags. (Which I thought already raised exceptions,
so I'm still confused here as to what change is being proposed.)
Given the documented behavior of evaluating undefined variables to empty
strings its been common practice to use:
{% if var_that_may_not_exist %}
...stuff that should only show when var exists...
{% endif %}
or to include {{ var_that_may_not_exist }} somewhere in a template and rely
on it evaluating to an empty string. (admin itself was documented as not
working correctly if you set the setting to evaluate undefined to something
other than empty string).
Changing either of these now to raise exceptions would be a huge backwards
incompatibility going against previously documented behavior. Please don't
do that.
It may well be friendlier to developers (I've never been a fan of the
"templates shouldn't raise exceptions" philosophy) but the fact is for many
years now it's been perfectly acceptable to use what might be undefined
variables in templates and the behavior has been documented as to how it
will work. Changing that now to start raising exceptions would be
incredibly unfriendly to existing code that has been written to rely on it.
Karen
--
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/CACS9raeFmaZQqtH3wyT6abRsXSHFjL2%2B-VfGnjgG2-18_M%2BRsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
