instance delete fails with: 403 Forbidden - CSRF verification failed

[Andrew Lenards]

Behavior is that an instance deletion from /project/instances is failing.

The error returned is: 403 Forbidden - CSRF verification failed

This was noted in #openstack-horizon by zigo on 2017-05-12.

OpenStack Release was stated to be Newton, on Debian.

Below are the steps to reproduce from the original bug report.

The information is pulled from (replicated) Debian bugs:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862387

----

Instance delete fails when I access:

  http://os-ctrl/horizon/project/instances/

and select "Delete Instance" from the list of actions with
the error:

  Forbidden (403)
  CSRF verification failed. Request aborted.

  Help
  Reason given for failure:
    CSRF token missing or incorrect.

while I see the csrftoken being sent in the request:

  csrftoken: tMhcr99nId798AXdULs8dUjuEHemALp0ONGCa4Y8ahpIuckFFqxexCuD13uR5ATy

Apache error.log just reports the same thing:

  Forbidden (CSRF token missing or incorrect.): /horizon/project/instances/, referer: http://os-ctrl/horizon/project/instances/

Deleting the instance works if I enter the instance first:

  http://os-ctrl/horizon/project/instances/6a167f8a-f0c6-440a-a1c1-c0063058d5c4/

and than select "Delete Instance" from the list of actions.

The same issue exists when deleting volumes from:

  http://os-ctrl/horizon/project/volumes/

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openstack-dashboard depends on:
ii adduser 3.115
ii libjs-jquery 3.1.1-2
ii libjs-jquery-cookie 11-3
ii python-django-horizon 3:10.0.1-1
pn python:any <none>

openstack-dashboard recommends no packages.

Versions of packages openstack-dashboard suggests:
ii memcached 1.4.33-1
ii openstack-dashboard-apache 3:10.0.1-1

-- no debconf information

[Andrew Lenards (lenards)]

Adding some context to this from the IRC channel ...

The version of Django is 1.10.

Some things to consider here is that this is Newton because of the installation coming from the Debian package universe.

Debian Stretch (version codename) was frozen prior to the Ocata release.

There is a request for Netwon to support Django 1.10 because of the situation noted here.

This is a summary of a conversation in IRC between zigo and robcresswall.

[Rob Cresswell (robcresswell-deactivatedaccount)]

This exists on master. It's due to Django 1.10, and something strange with the BatchActions (and the DeleteActions, which inherit from it)

[Rob Cresswell (robcresswell-deactivatedaccount)]

Okay, more info: I think this is due to our usage of render_to_response() all over the place instead of render(); I think the request value not being available is causing the CSRF token to be missing from the tables inline form. If you look at https://github.com/openstack/horizon/blob/2925562c1a3f0a9b3e2d55833691a7b0ad10eb2a/horizon/templates/horizon/common/_data_table.html#L4, csrf_token is specified, but when you actually inspect the code, it isn't there. I *think* the updated CSRF handling in Django 1.10 has exposed this.

[Rob Cresswell (robcresswell-deactivatedaccount)]

Fixed by https://review.openstack.org/#/c/476147/