rgw/swift: fix updating metadata failed for swift CORS

[Yan-waller]

I found it doesn't work when I try to update the CORS metadata
of swift buckets. as the following steps:

1. use the following command to create a swift bucket and post the CORS metadata;
   swift post swiftbkt0011 -H "X-Container-Meta-Access-Control-Allow-Origin: http://192.9.9.22" -H "X-Container-Meta-Access-Control-Request-Method: HEAD,POST,PUT,GET,OPTIONS,DELETE"

2. use the command to update the Access-Control-Allow-Origin attr;
   swift post swiftbkt0011 -H "X-Container-Meta-Access-Control-Allow-Origin: http://192.9.9.130" -H "X-Container-Meta-Access-Control-Request-Method: HEAD,POST,PUT,GET,OPTIONS,DELETE"

3. test the CORS, access my swift bucket swiftbkt0011 from the website at 192.9.9.130

then I got the following failed log message:

2016-07-09 16:49:14.070218 7f6be3fef700 15 Read RGWCORSConfiguration<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><CORSRule><AllowedMethod>GET</AllowedMethod><AllowedMethod>PUT</AllowedMethod><AllowedMethod>DELETE</AllowedMethod><AllowedMethod>HEAD</AllowedMethod><AllowedMethod>POST</AllowedMethod><AllowedMethod>COPY</AllowedMethod><AllowedOrigin>http://192.9.9.22</AllowedOrigin></CORSRule></CORSConfiguration>
2016-07-09 16:49:14.070300 7f6be3fef700 10 There is no cors rule present for http://192.9.9.130

the AllowedOrigin has not yet update(still http://192.9.9.22), so maybe we should not
use emplace which will not update the attrs if they are already present in attrs.

Signed-off-by: Yan Jun yan.jun8@zte.com.cn

[rzarzynski]

This is a bit surprising. From the code I can deduce the assumption that RGW_ATTR_CORS (and its current value from the RADOS store) shouldn't be present in RGWPutMetadataBucket::attrs at this phase. I need to debug this further.

[Yan-waller]

@rzarzynski thanks, yeh, I have tested this as the steps mentioned above and it worked as expected.

[rzarzynski]

@Yan-waller: I can't replicate the issue on my FormPost branch that bases on 99bb2f3 (quite fresh master, no changes related to CORS and metadata in general):

$ curl -i "$publicURL/cont" -X PUT -H "X-Auth-Token: $token" -H "X-Container-Meta-Access-Control-Allow-Origin: http://192.9.9.22" -H "X-Container-Meta-Access-Control-Request-Method: HEAD,POST,PUT,GET,OPTIONS,DELETE"
HTTP/1.1 201 Created
X-Trans-Id: tx000000000000000000020-0057e3e0c0-1010-default
Content-Length: 0
Accept-Ranges: bytes
Content-Type: text/plain; charset=utf-8
Date: Thu, 22 Sep 2016 13:46:40 GMT


$ curl -i "$publicURL/cont" -X POST -H "X-Auth-Token: $token" -H "X-Container-Meta-Access-Control-Allow-Origin: http://192.9.9.130" -H "X-Container-Meta-Access-Control-Request-Method: HEAD,POST,PUT,GET,OPTIONS,DELETE"
HTTP/1.1 204 No Content
X-Trans-Id: tx000000000000000000021-0057e3e0e5-1010-default
Content-Type: text/plain; charset=utf-8
Date: Thu, 22 Sep 2016 13:47:17 GMT


$ curl -i "$publicURL/cont" -X OPTIONS -H "X-Auth-Token: $token" -H "Origin: http://192.9.9.130" -H "Access-Control-Request-Method: GET"
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://192.9.9.130
Vary: Origin
Access-Control-Allow-Methods: GET
X-Trans-Id: tx000000000000000000022-0057e3e119-1010-default
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Date: Thu, 22 Sep 2016 13:48:09 GMT

Let's do the extra check with the address the bucket was created initially:

$ curl -i "$publicURL/cont" -X OPTIONS -H "X-Auth-Token: $token" -H "Origin: http://192.9.9.22" -H "Access-Control-Request-Method: GET"
HTTP/1.1 401 Unauthorized
X-Trans-Id: tx000000000000000000023-0057e3e12c-1010-default
Content-Length: 12
Accept-Ranges: bytes
Content-Type: text/plain; charset=utf-8
Date: Thu, 22 Sep 2016 13:48:28 GMT

AccessDenied

Actually it seems to work as expected. We had very similar problem in the past. It has been fixed in #9263. Are sure you tested on the patched version?

[rzarzynski]

The cleanup commit has been merged in #11292. Closing this PR as it looks that the bug is already fixed.