Re: load template tag library
On Nov 17, 12:05 am, Luke Plant wrote:
> From my perspective, putting the template tag libraries in the view is
> absolutely the wrong thing to do, for a number of reasons:
>
> 1) If I'm reading a template and come across a template tag I don't
> understand, I have to go and find the view it is called from to work out
> what template tag library it might be from. The information is much
> better off in the template.
I agree, hadn't given much thought to readability
> 2) A single template might be used by multiple views. If views are
> responsible for setting the libraries available, they now have duplicate
> content.
I agree that we should avoid code duplication. But I think that that
doesn't have to be the reason to load template tag libraries from the
templates. It could make sense to turn the (html-) template into a
python object in one place (maybe /templates.py), and use this
python object in your views. Then the libraries could be set in this
file (/templates.py).
> 3) If it was done this way, then the available libraries would have to
> be inherited by included templates, and templates that are 'extended
> from'. This makes things even worse for chasing down which template tag
> libraries are in use, especially as a single template can be included
> from multiple places. If you add in the fact that a tag from custom
> template tag library can shadow a builtin, and the deliberate mechanism
> we have for choosing a new version ({% load url from future %}), things
> are getting pretty diabolical.
Agreed
> Template tags essentially form part of the syntax of the template, and
> putting that information outside the template really doesn't make sense.
I don't really see this point. Along this line of thinking you could
also say that defining template tags should be done inside of
templates. Before you know you have recreated PHP ;-).
> As for the need to limit which libraries are allowed for a template, my
> solution would be to do this:
>
> {% load foo bar baz %} {# No others allowed for this template #}
>
> Front-end developers are on the same team. If they refuse to follow
> instructions like that, you should sack them.
I'm not in the position to, so that's not really an option ;-).
> You shouldn't be using the template system in situations where you have
> people who are not trusted, because it simply does not have the security
> necessary for it to be made available to potentially malicious users. It
> was never designed with that in mind, and would probably have dozens of
> major security flaws if you use it in that way. (The protection that
> exists against use of unsafe methods being called is protection against
> *accidental* use of those methods, not against malicious users).
>
> So, if this feature request (restricting the available template tag
> libraries) is part of a security feature, I'm -1 on it, because it
> implies an existing level of security in the template system that
> doesn't exist. To put it another way, if your use case is "allow end
> users to use the template system safely", this feature wouldn't come
> close to doing that. If your use case is "stop front-end developers
> deliberately doing naughty things", I'd say the solution can't be a
> technical one.
OK
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: load template tag library
On Nov 17, 8:02 am, Stephen Burrows wrote: > I second what Luke and Russ have already said. > > If what you're interested in is a way to securely allow users to enter > template code into the database, you can just write a custom field > that validates its input for security problems. > > Here's a third-party implementation of a validator for such a > field:https://github.com/ithinksw/philo/blob/master/philo/validators.py#L106 > > This particular implementation: > > - lets you explicitly allow particular tags (in which case all other > tags are disallowed for the field) > - lets you explicitly disallow particular tags (in which case all > other tags are allowed for the field) > - disallows the load, extends, include, and debug template tags by > default, but lets the backend developer specify the field as > "insecure" if they want to. > > My point being - if what you want is to let people specify template > code in database fields, there are ways to make it secure without > rewriting the template engine. Interesting link! Thanks. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
models.IPAddressField not saved as NULL
I have a model field: models.IPAddressField(verbose_name="access IP address", blank=True, null=True) that I attempt to save through a ModelForm. Despite the settings above, instead of NULL, Django tries to save the empty field (mapped to Postgres' inet type) as an empty string E'' , which is inappropriate for that type. I *could* probably change the model type to CharField and override the ModelForm widget as IPAddressField to get form-level validation, and so the DB syntax error goes away, but isn't that a bug? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: models.IPAddressField not saved as NULL
On Thu, Nov 17, 2011 at 5:13 AM, rihad wrote: > I *could* probably change the model type > to CharField and override the ModelForm widget as IPAddressField to > get form-level validation, and so the DB syntax error goes away, but > isn't that a bug? > > Yes, an old bug: https://code.djangoproject.com/ticket/5622 Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: models.IPAddressField not saved as NULL
On Nov 17, 5:14 pm, Karen Tracey wrote: > > Yes, an old bug:https://code.djangoproject.com/ticket/5622 https://code.djangoproject.com/attachment/ticket/5622/empty-ip-2.diff Probably this simple fix breaks some core design principle badly, and that's why 17 months haven't been enough time to get it right? Come on, this one can't be that harder than implementing multi-key PKs? :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: models.IPAddressField not saved as NULL
2011/11/17 rihad > Probably this simple fix breaks some core design principle badly, and > that's why 17 months haven't been enough time to get it right? Come > on, this one can't be that harder than implementing multi-key PKs? :) Just read the comments and you'll see why the patch wasn't committed: https://code.djangoproject.com/ticket/5622#comment:33 Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: models.IPAddressField not saved as NULL
So is there any suggested workaround if one wishes to keep type inet at the PostgreSQL level? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
get_traceback_html vulnerable to infinite loop if called twice
Hi all, I would like to know if the behavior I am seeing is to be expected, or should be reported as a bug. I made a modification to the crash log middleware http://code.google.com/p/django-crashlog/ to get it to save the lovely html error report that is available when settings.DEBUG == True. Sometimes, if settings.DEBUG is set to true and an exception happens my debug server process goes into a loop until memory is exhausted and it crashes. I have debugged the problem to the piece of code that loops-till-dead. My modified crashlog code collects the html traceback and persists it as expected, then the exception processing continues, eventually bubbling up to the point where the debug view is processed. In the get_traceback_html method of the ExceptionReporter class in django/views/debug.py the following lines are the location of the (presumably) infinite loop that occurs when the method is called for the second time for the same exception stack: frames = self.get_traceback_frames() for i, frame in enumerate(frames): if 'vars' in frame: frame['vars'] = [(k, force_escape(pprint(v))) for k, v in frame['vars']] frames[i] = frame I can and will eliminate the problem by omitting the debug html call if settings.DEBUG is true, but I would like to know, am I breaking some design constraint by causing this to be called twice, or should I report it as a bug? Thanks, dlp -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: load template tag library
On Nov 16, 12:40 pm, ptone wrote:
> On Nov 16, 1:12 am, Roald wrote:
> > Can anybody explain why template tag libraries are loaded from
> > *inside* a template? The more I work with them, the more I get the
> > feeling that specifying which template tags are available in a
> > template should be specified in the view-code (or more general: the
> > thing that loads/renders the template).
>
> Such as a TemplateEngine...?
>
> This seems a good candidate feature
> for:https://code.djangoproject.com/ticket/17093
I fully agree with Luke, Stephen, and Russell that {% load %} tags in
the template are how templatetags should be loaded and made available
for use in that template, simply for reasons of clarity and
explicitness.
I do, however, think that the tight coupling we currently have between
INSTALLED_APPS and "what templatetag libraries are available for
load", while a reasonable default for an integrated framework, is an
unfortunate restriction on use of the template system, which I hope
can be lifted by #17093.
And I also don't agree that efforts to use the template language in a
"sandboxed" way are doomed to failure: if you can instantiate a
template instance with an explicitly-limited set of templatetag
libraries (which #17093 would allow), and you can control exactly what
data is put into the template context, I think you _can_ make
templates safe for untrusted use. Obviously it requires care.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: models.IPAddressField not saved as NULL
On Nov 17, 7:16 pm, rihad wrote: > So is there any suggested workaround if one wishes to keep type inet > at the PostgreSQL level? BTW: changing the field type to GenericIPAddress worked flawlessly. Wow. "manage.py sqlall" revealed that it's still Postgres inet type behind the scenes. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: load template tag library
On 17/11/11 18:36, Carl Meyer wrote:
> I do, however, think that the tight coupling we currently have between
> INSTALLED_APPS and "what templatetag libraries are available for
> load", while a reasonable default for an integrated framework, is an
> unfortunate restriction on use of the template system, which I hope
> can be lifted by #17093.
Agreed.
> And I also don't agree that efforts to use the template language in a
> "sandboxed" way are doomed to failure: if you can instantiate a
> template instance with an explicitly-limited set of templatetag
> libraries (which #17093 would allow), and you can control exactly what
> data is put into the template context, I think you _can_ make
> templates safe for untrusted use. Obviously it requires care.
It's pretty easy to produce a DOS attack using only builtin template
tags and filters, and a completely empty context e.g.:
{% for a in "xxx"|make_list %}
{% for a in "xxx"|make_list %}
{# etc #}
{% endfor %}
{% endfor %}
I'm sure there must be other ways to do this, and there may well be
different other types of flaws. I guess it depends on what you mean by
'safe', but we certainly haven't built the template system with this in
mind.
Luke
--
The probability of someone watching you is proportional to the
stupidity of your action.
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: load template tag library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2011 02:51 PM, Luke Plant wrote:
> It's pretty easy to produce a DOS attack using only builtin template
> tags and filters, and a completely empty context e.g.:
>
> {% for a in "xxx"|make_list %}
> {% for a in "xxx"|make_list %}
> {# etc #}
> {% endfor %}
> {% endfor %}
>
> I'm sure there must be other ways to do this, and there may well be
> different other types of flaws. I guess it depends on what you mean by
> 'safe', but we certainly haven't built the template system with this in
> mind.
Yes, good point. I'd expect there are a number of ways to do something
along these lines; you'd have to render the template in a thread with a
short timeout or something.
I personally wouldn't try to use the template language with truly
untrusted input; I might (and have) with
potentially-incompetent-trusted-user input.
I guess my real point is just that I think the core request, to be able
to lock down what template tag libraries can be loaded in a template, is
a reasonable one, and "just document the restriction!" is not sufficient
reason to reject it.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FhHUACgkQ8W4rlRKtE2exUQCgiQIioRlS6gaX8gLbGvtJVEbD
ilcAoIGM4PbeegMwPZE5jnWT7CQyORtb
=iGOW
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Deploy Django to hostmonster
Hello, I'm new in Django. I had write my own website by Django but I got problems in deploying it to hostmonster. The detail of my problem is: http://stackoverflow.com/questions/8156173/django-cant-run-in-hostmonster Please help me to point out what wrong. Many thanks tbson -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deploy Django to hostmonster
On Thu, Nov 17, 2011 at 9:41 PM, Tran Bac Son wrote: > Hello, > I'm new in Django. I had write my own website by Django but I got problems > in deploying it to hostmonster. > The detail of my problem is: > http://stackoverflow.com/questions/8156173/django-cant-run-in-hostmonster > Please help me to point out what wrong. > > Many thanks > > tbson > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > Hi, This mailing list is for discussing the development of Django itself, not developing with Django, for that you should use the django-users mailing list. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
