Re: malicious requests?
Thanks Alasdair, that's really useful. I'm using v1.6.X in production, which makes sense based on your email. Alex. On 22/12/14 13:58, Alasdair Nicol wrote: > Hi Alex, > > There is no security implication adding 'example.com.' (with trailing > dot) to your ALLOWED_HOSTS setting. There is some more information in > the ALLOWED_HOSTS setting docs. > > From https://docs.djangoproject.com/en/1.7/ref/settings/#allowed-hosts > >> In previous [<= 1.6.X] versions of Django, if you wanted to also >> allow the fully qualified domain name (FQDN), which some browsers >> can send inthe Host header, you had to explicitly add another >> ALLOWED_HOSTS entry that included a trailing period. > >> In Django 1.7, the trailing dot is stripped when performing host >> validation, thus an entry with a trailing dot isn’t required. > > cheers, > Alasdair > > > > On 22/12/14 12:05, Alex Haylock wrote: >> Thanks Markus. >> >> So, as per the RFC, are 'example.com' and 'example.com.' considered to >> be the same domain, or two separate domains? >> >> Are there any security implications if I add 'example.com.' to >> ALLOWED_HOSTS to cater for these requests? >> >> Thanks, >> >> Alex. >> >> On 22/12/14 11:52, Markus Holtermann wrote: >>> Hey Alex, >>> >>> a trailing . in the host header is valid per RFC 3986: >>> http://tools.ietf.org/html/rfc3986#section-3.2.2: >>> >>> The rightmost domain label of a fully qualified domain name in DNS >>> may be followed by a single "." >>> >>> >>> /Markus >>> >>> On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote: >>> >>> Are there any known attack vectors that involve appending a period/ >>> full-stop to a sites domain name? >>> >>> My Django application throws a handful of errors in production >>> every >>> day: >>> >>> ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may >>> need to >>> add >>> u'www.example.com <http://www.example.com>.' to ALLOWED_HOSTS. >>> >>> (note the trailing period) >>> >>> Is this malicious behaviour, or just users mistyping the URL? >>> >>> Also, browsers are clearly treating the final '.' as part of the >>> path >>> (as these requests are reaching my application), but Django is >>> treating >>> the '.' as part of the hostname. Which is right? >>> >>> -- >>> Regards, >>> >>> >>> Alex >>> >> > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54982E97.3040803%40mykolab.com. For more options, visit https://groups.google.com/d/optout.
Re: malicious requests?
Thanks Markus. So, as per the RFC, are 'example.com' and 'example.com.' considered to be the same domain, or two separate domains? Are there any security implications if I add 'example.com.' to ALLOWED_HOSTS to cater for these requests? Thanks, Alex. On 22/12/14 11:52, Markus Holtermann wrote: > Hey Alex, > > a trailing . in the host header is valid per RFC 3986: > http://tools.ietf.org/html/rfc3986#section-3.2.2: > > The rightmost domain label of a fully qualified domain name in DNS > may be followed by a single "." > > > /Markus > > On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote: > > Are there any known attack vectors that involve appending a period/ > full-stop to a sites domain name? > > My Django application throws a handful of errors in production every > day: > > ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to > add > u'www.example.com <http://www.example.com>.' to ALLOWED_HOSTS. > > (note the trailing period) > > Is this malicious behaviour, or just users mistyping the URL? > > Also, browsers are clearly treating the final '.' as part of the path > (as these requests are reaching my application), but Django is treating > the '.' as part of the hostname. Which is right? > > -- > Regards, > > > Alex > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/549808F9.4010607%40mykolab.com. For more options, visit https://groups.google.com/d/optout.
malicious requests?
Are there any known attack vectors that involve appending a period/ full-stop to a sites domain name? My Django application throws a handful of errors in production every day: ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add u'www.example.com.' to ALLOWED_HOSTS. (note the trailing period) Is this malicious behaviour, or just users mistyping the URL? Also, browsers are clearly treating the final '.' as part of the path (as these requests are reaching my application), but Django is treating the '.' as part of the hostname. Which is right? -- Regards, Alex -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/549803CE.7060208%40mykolab.com. For more options, visit https://groups.google.com/d/optout.
Re: ModelAdmin with inlines: How to learn if/what has changed before the models are saved?
On 18/12/14 17:19, Carsten Fuchs wrote: > I would like to find out if anything has changed in the parent > model or the related (inline) models, and depending on the result, > update one of the parent model's fields before it is saved. > > Can you please tell me how can this be achieved? Take a look at the Django signal dispatcher: https://docs.djangoproject.com/en/dev/topics/signals/ Specifically, the 'update_fields' argument passed to the 'pre_save' signal should provide what you need: https://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.pre_save Regards, Alex. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5495EE89.6040504%40mykolab.com. For more options, visit https://groups.google.com/d/optout.
