CORS headers not returning via uWSGI
CrazySky2121 opened this issue · comments
Hello! We are using Django app with returning CORS headers.
When we testing it on local env with internal Django wSGIServer, all works fine. Required headers returned.
Example:
Server: WSGIServer/0.2 CPython/3.5.2
Access-Control-Allow-Headers: accept, accept-encoding, authorization, content-type, dnt, origin, user-agent, x-csrftoken, x-requested-with
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Expose-Headers: []
Access-Control-Allow-Credentials: True
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 86400
Content-Type: text/html; charset=utf-8
But when we using Nginx + uWSGI - CORS headers on same request not return.
Instead of required headers, we have only this:
Server: nginx/1.10.0 (Ubuntu)
Date: Wed, 07 Jun 2017 08:31:50 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
did you solve this issue?
I'm also curious. Have uwsgi fronting django and cors header is always blank
Same issue here, OpenStack started defaulting to uwsgi nowadays and it broke cors config - no header is sent. :/ Here it is behind apache2
I have just tested a simple setup with
django, django-cors-headers and uwsgi 2.0.18 and nginx.
Relevant configuration and curl command and response is as follows:
# nginx config
location / {
uwsgi_pass unix:///tmp/uwsgi.sock;
include uwsgi_params;
}
# uwsgi invocation
uwsgi -H ./venv --pp ./hello -w hello.wsgi --socket /tmp/uwsgi.sock --chmod-socket=777
# curl request
$ curl -i -XOPTIONS -H 'Access-Control-Request-Method: POST' -H Origin:example.com localhost
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 21 Jan 2020 19:06:40 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Vary: Origin
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: accept, accept-encoding, authorization, content-type, dnt, origin, user-agent, x-csrftoken, x-requested-with
Access-Control-Allow-Methods: DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Max-Age: 86400
X-Content-Type-Options: nosniff
This all seems to work fine and uwsgi doesn't eat any headers. One thing to note is that if -H 'Origin: example.com' is not provided, django-cors-headers does not produce the Access-Control headers. This might be confusing at first when testing using curl.
It's unfortunate there was no reaction on the initial request, but I'm afraid this is more of a configuration issue rather than a bug in uwsgi.
@yoctozepto - I saw the thread you started on the OpenStack mailing list [1] and the bug report [2] where you reference this issue as the reason for CORS being broken in OpenStack. Please verify that the app produces the right Access-Control-* headers. Also, is there an easy way to reproduce the issue you see?
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012127.html
[2] https://bugs.launchpad.net/devstack/+bug/1860287
Hi Arne @awelzel
OpenStack is usually PITA to deploy manually so your best bet, if you want to triage this locally, is to https://docs.openstack.org/devstack/latest/ on a destroyable VM with Ubuntu 18.04.
Let me set up some basic testing in CI to compare headers returned by mod_wsgi and uwsgi. I really trusted browser in this regard and it might be the case oslo.middleware depends on some mod_wsgi-only thingy that makes browsers happy which uwsgi does not do.
I will let ML know you are handling this so they may come up with some better testing ideas (and any oslo insight I'm missing here).
@yoctozepto - I've given the devstack a shot - CORS headers work fine. Note, I've checked out the stable/train branch instead of using master. It brought up some APIs served by uwsgi, though I'm not sure the whole thing is functional...
Changing /etc/nova/nova.conf and adding the following section and doing a systemctl restart devstack@n-api enables CORS for the /compute endpoint:
[cors]
allowed_origin = *
This is simply from here: https://docs.openstack.org/oslo.middleware/train/admin/cross-project-cors.html
Testing:
curl -i -XOPTIONS -H 'Access-Control-Request-Method: PUT' -H 'Origin: example.com' localhost/compute
HTTP/1.1 200 OK
Date: Wed, 22 Jan 2020 09:17:55 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 373
Content-Type: application/json
Vary: Origin
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 3600
Access-Control-Allow-Methods: PUT
Connection: close
{"versions": [{"status": "SUPPORTED", "up...
So this is not a uwsgi bug, but just a configuration thing.
@xrmx - mind closing this? I believe we have shown there's no issue here. Thanks!
Thanks @awelzel for digging into this
Oddly, I am not seeing correct behavior in CI. Obviously config is set right. ;-)
(grep logs for curl -i, sorry for trouble)
I will dig deeper then. :/
PS: Is not it weird you are somehow getting body in response to your OPTIONS request? (The one you put as a working example.) Could that be what is causing the ruckus?
Oddly, I am not seeing correct behavior in CI. Obviously config is set right. ;-)
(grep logs for curl -i, sorry for trouble)
I understand you want to solve the issue you are having, but IMO this is not the right place to figure out how to setup CORS on OpenStack.
That said, make sure to restart uwsgi (systemctl restart devstack@keystone.service) after changing the config file - it appears you're not doing that.
PS: Is not it weird you are somehow getting body in response to your OPTIONS request? (The one you put as a working example.) Could that be what is causing the ruckus?
Indeed. But again, it's the app/framework that is doing so and not a uwsgi issue.
make sure to restart uwsgi ... after changing the config file
You know what? The darkest place is under the candlestick.
Service start 11:18
Service config set 11:27
meh, devstack to blame
IMO this is not the right place to figure out how to setup CORS on OpenStack.
I beg to differ, you finally helped me debug this. Too much trust in basic stuff. :-)
Completely seriously now, I fell into the trap set by this report that it's uWSGI's issue and never checked devstack's internal logic (which is broken in either wsgi mode but mod_wsgi works due to more apache restarts there).
Thanks, @awelzel