#31845: CSRF check fails when browsing with FQDN with trailing dot
------------------------+--------------------------------------
     Reporter:  ippei   |                    Owner:  nobody
         Type:  Bug     |                   Status:  new
    Component:  CSRF    |                  Version:  2.2
     Severity:  Normal  |               Resolution:
     Keywords:          |             Triage Stage:  Unreviewed
    Has patch:  0       |      Needs documentation:  0
  Needs tests:  0       |  Patch needs improvement:  0
Easy pickings:  0       |                    UI/UX:  0
------------------------+--------------------------------------
Description changed by ippei:

Old description:

> CSRF check seems to fail with "Referer checking failed" when user is
> browsing with FQDN with trailing dot.
>
> At this line:
> https://github.com/django/django/blob/2.2.12/django/middleware/csrf.py#L280
> while {{{referer.netloc}}} has trailing dot, one of the {{{good_hosts}}}
> that is supposed to match comes from {{{request.get_host()}}} which
> strips the trailing dot.
> {{{is_same_domain}}} does not consider domain strings with and without
> trailing dots the same domain.
>
> We neither set CSRF_USE_SESSIONS nor CSRF_COOKIE_DOMAIN in settings.
> (Our system uses DRF, but the original error seems to come from the
> CsrfViewMiddleware implementation.)
>
> For now, we add CSRF_TRUSTED_ORIGINS our production domain with trailing
> dot to circumvent this issue.

New description:

 CSRF check seems to fail with "Referer checking failed" when user is
 browsing with FQDN with trailing dot.

 At this line:
 https://github.com/django/django/blob/2.2.12/django/middleware/csrf.py#L280
 while {{{referer.netloc}}} has trailing dot, one of the {{{good_hosts}}}
 that is supposed to match comes from {{{request.get_host()}}} which strips
 the trailing dot.
 {{{is_same_domain}}} does not consider domain strings with and without
 trailing dots the same domain.

 We neither set CSRF_USE_SESSIONS nor CSRF_COOKIE_DOMAIN in settings.
 (Our system uses DRF, but the original error seems to come from the
 CsrfViewMiddleware implementation.)

 For now, we set CSRF_TRUSTED_ORIGINS with our production domain with
 trailing dot to circumvent this issue.

--

-- 
Ticket URL: <https://code.djangoproject.com/ticket/31845#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d74296e54cb13237ba61a6842035f0b1%40djangoproject.com.

Reply via email to