[api][sdk][dev][oslo] using uWSGI breaks CORS config
Radosław Piliszek
radoslaw.piliszek at gmail.com
Tue Jan 21 17:31:28 UTC 2020
Ben wrote:
> it looks like this is a uwsgi bug and not
> something we're doing wrong (other than recommending uwsgi ;-).
Precisely. Well, there is always a chance either side does something wrong
until one acknowledges doing it wrong but if django and oslo.middleware
can send CORS headers via mod_wsgi and both cannot via uWSGI, then
it's uWSGI that's more suspicious. ;-)
Sean wrote:
> is it somehting that we expect the wsgi server to add or the applciation?
> it seam like we use oslo midelware to do this dynmaically form the api code.
Wearing my web developer hat, I would say it's up to the application to do,
in general, since different resources may need different CORS headers.
In the contrived example of testing in CI, allowing anything for the
sake of easy
access, it does not really matter. :-)
Sean wrote:
> but my only interaction in the past was setting it via the apache .htaccess file.
Yeah, any decent web server allows to add/remove/override headers.
Sean wrote:
> they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
Indeed that's what the linked bug report suggests as well as random
googlable info.
I wonder why nobody from uWSGI answered the bug call. :/
-yoctozepto
wt., 21 sty 2020 o 18:15 Sean Mooney <smooney at redhat.com> napisał(a):
>
> On Tue, 2020-01-21 at 17:30 +0100, Ben Nemec wrote:
> >
> > On 1/21/20 4:55 PM, Michael McCune wrote:
> > >
> > >
> > > On Tue, Jan 21, 2020 at 5:37 AM Radosław Piliszek
> > > <radoslaw.piliszek at gmail.com <mailto:radoslaw.piliszek at gmail.com>> wrote:
> > >
> > > Hi, Michael!
> > >
> > > Thanks for your interest. I was also surprised that it does not work.
> > > It looks simple enough to not break...
> > >
> > > Since I wrote the email, I did more research on how to tackle this
> > > problem.
> > > For now I posted a bug to devstack that CORS is out of reach with pure
> > > devstack [1].
> > >
> > >
> > > that sounds like a good first step.
> > >
> > > Only keystone and placement can be configured to use mod_wsgi, others
> > > default to uwsgi (or eventlet, to be precise, but these are
> > > irrelevant).
> > > It's really either hacking browsers or hacking apache config to
> > > include relevant CORS headers.
> > >
> > >
> > > this is something that i think we need to know though, because if uWSGI
> > > has broken CORS support then we need to fix it or start advising against
> > > its usage.
> >
> > Just to clarify, based on [0] it looks like this is a uwsgi bug and not
> > something we're doing wrong (other than recommending uwsgi ;-). Is that
> > correct?
> >
> > 0: https://github.com/unbit/uwsgi/issues/1550
>
> is it somehting that we expect the wsgi server to add or the applciation?
> e.g. should the CORS headders be added by the apache/nginx/uwsgi or openstack.
>
> but my only interaction in the past was setting it via the apache .htaccess file.
> https://enable-cors.org/server_apache.html you can also do it in nginx https://enable-cors.org/server_nginx.html
>
> it seam like we use oslo midelware to do this dynmaically form the api code.
>
> https://docs.openstack.org/oslo.middleware/latest/admin/cross-project-cors.html
> so perhaps that is not executing or uswsgi si stripping the headers.
>
> they may be filtering them but i cant really find any documentaiton on uswgi and CORS configuration
>
> >
> > >
> > > peace o/
> > >
> > > [1] https://bugs.launchpad.net/devstack/+bug/1860287
> > >
> > > -yoctozepto
> > >
> > > wt., 21 sty 2020 o 10:00 Michael McCune <elmiko at redhat.com
> > > <mailto:elmiko at redhat.com>> napisał(a):
> > > >
> > > > hi Radoslaw,
> > > >
> > > > i am also curious about this because i had thought we had CORS
> > > issued solved for uWSGI in the past, i will need to look around to
> > > find the conversations i was having.
> > > >
> > > > thanks for sharing your investigation, i think this is interesting.
> > > >
> > > > peace o/
> > > >
> > > > On Fri, Jan 17, 2020 at 1:45 PM Radosław Piliszek
> > > <radoslaw.piliszek at gmail.com <mailto:radoslaw.piliszek at gmail.com>>
> > > wrote:
> > > >>
> > > >> Fellow Devs,
> > > >>
> > > >> as you might have noticed I started taking care of
> > > openstack/js-openstack-lib,
> > > >> now under the openstacksdk umbrella [1].
> > > >> First goal is to modernize the CI to use Zuul v3, current
> > > devstack and
> > > >> nodejs, still WIP [2].
> > > >>
> > > >> As part of the original suite of tests, the unit and functional
> > > tests
> > > >> are run from browsers as well as from node.
> > > >> And, as you may know, browsers care about CORS [3].
> > > >> js-openstack-lib is connecting to various OpenStack APIs (currently
> > > >> limited to keystone, glance, neutron and nova) to act on behalf
> > > of the
> > > >> user (just like openstacksdk/client does).
> > > >> oslo.middleware, as used by those APIs, provides a way to configure
> > > >> CORS by setting params in the [cors] group but uWSGI seemingly
> > > ignores
> > > >> that completely [4].
> > > >> I had to switch to mod_wsgi+apache instead of uwsgi+apache to
> > > get past
> > > >> that issue.
> > > >> I could not reproduce locally because kolla (thankfully) uses mostly
> > > >> mod_wsgi atm.
> > > >>
> > > >> The issue I see is that uWSGI is proposed as the future and mod_wsgi
> > > >> is termed deprecated.
> > > >> However, this means the future is broken w.r.t. CORS and so any
> > > modern
> > > >> web interface with it if not sitting on the exact same host and port
> > > >> (which is usually different between OpenStack APIs and any UI).
> > > >>
> > > >> [1] https://review.opendev.org/701854
> > > >> [2] https://review.opendev.org/702132
> > > >> [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
> > > >> [4] https://github.com/unbit/uwsgi/issues/1550
> > > >>
> > > >> -yoctozepto
> > > >>
> > >
> >
> >
>
More information about the openstack-discuss
mailing list