| opendevreview | Alistair Coles proposed openstack/swift master: ssync: fix decoding of ts_meta when ts_data has offset https://review.opendev.org/c/openstack/swift/+/874122 | 10:17 |
|---|---|---|
| opendevreview | Alistair Coles proposed openstack/swift master: ssync: Round-trip offsets in meta/ctype Timestamps https://review.opendev.org/c/openstack/swift/+/874184 | 10:19 |
| opendevreview | OpenStack Release Bot proposed openstack/python-swiftclient stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/python-swiftclient/+/875088 | 15:08 |
| opendevreview | OpenStack Release Bot proposed openstack/python-swiftclient stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/python-swiftclient/+/875089 | 15:08 |
| opendevreview | OpenStack Release Bot proposed openstack/python-swiftclient master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/python-swiftclient/+/875090 | 15:08 |
| opendevreview | Alistair Coles proposed openstack/swift master: sharder: show path and db file in info and debug logs https://review.opendev.org/c/openstack/swift/+/875220 | 16:23 |
| opendevreview | Alistair Coles proposed openstack/swift master: sharder: show path and db file in warning and error logs https://review.opendev.org/c/openstack/swift/+/875221 | 16:23 |
| opendevreview | Tim Burke proposed openstack/swift master: Add test_account_acls option to func tests https://review.opendev.org/c/openstack/swift/+/875252 | 19:20 |
| opendevreview | Clay Gerrard proposed openstack/swift master: ssync: fix decoding of ts_meta when ts_data has offset https://review.opendev.org/c/openstack/swift/+/874122 | 19:31 |
| opendevreview | Tim Burke proposed openstack/swift master: Skip S3 versioning test when versioning is not enabled https://review.opendev.org/c/openstack/swift/+/875254 | 19:48 |
| jbryce | hi folks! are these CORS docs still accurate or is there a different CORS method for swift now? https://docs.openstack.org/swift/latest/cors.html | 20:34 |
| timburke | jbryce, yes, those should still be accurate -- having any issues with CORS? | 20:41 |
| jbryce | yes. added X-Container-Meta-Access-Control-Allow-Origin: * on a container. added cors_allow_origin = * and strict_cors_mode = False and cors_preflight_allow_origin = * to proxy-server.conf and getting CORS errors in browser still. a direct request against the API doesn't include Access-Control-Allow-Origin in response headers | 20:46 |
| timburke | when you make the direct request, does it include the `Origin` header? does the browser's dev tools/console say much about what happened? | 20:47 |
| timburke | if container acls require a referer to access data, that would need to be included in the direct request, too | 20:51 |
| jbryce | the browser error is "Access to XMLHttpRequest at '{containerUrl}' from origin 'http://127.0.0.1:5173' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource." | 20:56 |
| timburke | sometimes you can still get the response code from the dev tools (though it won't be accessible to js running on the page) -- if you can find it, was it a 2xx, or some kind of error? | 20:57 |
| jbryce | 401 | 20:58 |
| jbryce | if i add an Origin header to the curl requests that work, they also get a 401 response code | 20:58 |
| jbryce | i'll keep poking around and pop back in if i can't figure it out. wanted to just do a headcheck on the docs. thanks! | 21:00 |
| opendevreview | Tim Burke proposed openstack/swift master: encryption: Expose decrypted metadata via CORS https://review.opendev.org/c/openstack/swift/+/712237 | 21:24 |
| jbryce | update: i did get the Access-Control-Allow-Origin response header back from the swift proxy on my direct curl request with an Origin request header. the browser however continues to fail because it is removing the x-auth-token for the "preflight" CORS request where it sends an OPTIONS request to the proxy | 21:34 |
| jbryce | it includes Access-Control-Request-Headers: x-auth-token as a header in the OPTIONS request but not the actual token. trying to figure out why the preflight is dropping it when the js GET includes it | 21:35 |
| timburke | that's the spec, i'm afraid. the preflight was coming back 401, too, was it? | 21:36 |
| timburke | the only place we should flip an OPTIONS request to a 401 is https://github.com/openstack/swift/blob/master/swift/proxy/controllers/base.py#L2270 ... but we already know container meta says to allow * ... | 21:39 |
| jbryce | yeah i'm seeing that now. yes the preflight is coming back 401. checking the auth middleware now to see if we've modified something | 21:39 |
| timburke | 💡 i should add "CORS preflights" to https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L452-L455 | 21:40 |
| jbryce | thanks for talking this through. i was having trouble following the full flow | 21:40 |
| timburke | happy to help! it definitely took a lot of staring for me to follow what happens with CORS... on the plus side, though, i got https://github.com/openstack/swift/tree/master/test/cors out of it :-) | 21:42 |
| timburke | i'd definitely check whether you've got delay_auth_decision as true or false (guessing it's safe to assume you're using keystone's authtoken) | 21:43 |
| jbryce | not keystone. separate external auth backend implemented in a similar way though | 21:47 |
| jbryce | have got all of that working now for containers (and associated objects). what's the thinking on limiting CORS requests there vs the account level? context is i'm helping someone create a simple js app to browse a swift backend, so listing containers with an account GET is the top level of the app | 23:02 |
| timburke | 🎉 | 23:03 |
| timburke | mostly just that the assets to offer up to some external app would typically be objects, rather than account or container listings -- i'm not opposed in principle to allowing CORS requests at the account level | 23:07 |
| jbryce | would you prefer to see something like that implemented as a metadata control on the account like the container (e.g. x-account-meta-access-control-allow-origin) or as a proxy server conf (i.e. more global for all accounts) | 23:11 |
| timburke | i could see benefits for either. i expect a public provider (OVH, say) would hesitate to turn it on globally, since it would shift some security expectations, so i suppose i'd have a bit of a preference for per-account settings | 23:42 |
| timburke | would probably want to store it in sysmeta, too -- the fact that container CORS access is defined in user meta is mostly an accident of history, as i recall | 23:43 |
| jbryce | ok will look at that | 23:58 |
| jbryce | thanks again! | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!