Thank you David for your suggestion.
We add our domain(Origin) to zonegroup’s endpoints and hostnames:
{
"id": "default",
"name": "default",
"api_name": "",
"is_master": "true",
"endpoints": [
"https://console.{our_domain}.ru";,
],
"hostnames": [
"https://console.{our_domain}.ru";,
],
"hostnames_s3website": [],
"master_zone": "default",
"zones": [
{
"id": "default",
"name": "default",
"endpoints": [],
"log_meta": "false",
"log_data": "false",
"bucket_index_max_shards": 0,
"read_only": "false",
"tier_type": "",
"sync_from_all": "true",
"sync_from": []
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "9c7666df-132d-4db0-988e-6b28767ff3cf"
}
But it’s not solve our problems.
In RGW logs:
2017-10-23 10:51:25.301934 7f39f2e73700 1 ====== starting new request req=0x7f39f2e6d190 =====
2017-10-23 10:51:25.301956 7f39f2e73700 2 req 22:0.000022::OPTIONS /aaa::initializing for trans_id = tx000000000000000000016-0059ed9f7d-fc80-default
2017-10-23 10:51:25.301993 7f39f2e73700 2 req 22:0.000058:s3:OPTIONS /aaa::getting op 6
2017-10-23 10:51:25.302004 7f39f2e73700 2 req 22:0.000071:s3:OPTIONS /aaa:options_cors:verifying requester
2017-10-23 10:51:25.302013 7f39f2e73700 2 req 22:0.000080:s3:OPTIONS /aaa:options_cors:normalizing buckets and tenants
2017-10-23 10:51:25.302018 7f39f2e73700 2 req 22:0.000084:s3:OPTIONS /aaa:options_cors:init permissions
2017-10-23 10:51:25.302065 7f39f2e73700 2 req 22:0.000131:s3:OPTIONS /aaa:options_cors:recalculating target
2017-10-23 10:51:25.302070 7f39f2e73700 2 req 22:0.000136:s3:OPTIONS /aaa:options_cors:reading permissions
2017-10-23 10:51:25.302075 7f39f2e73700 2 req 22:0.000141:s3:OPTIONS /aaa:options_cors:init op
2017-10-23 10:51:25.302076 7f39f2e73700 2 req 22:0.000143:s3:OPTIONS /aaa:options_cors:verifying op mask
2017-10-23 10:51:25.302078 7f39f2e73700 2 req 22:0.000144:s3:OPTIONS /aaa:options_cors:verifying op permissions
2017-10-23 10:51:25.302080 7f39f2e73700 2 req 22:0.000146:s3:OPTIONS /aaa:options_cors:verifying op params
2017-10-23 10:51:25.302081 7f39f2e73700 2 req 22:0.000148:s3:OPTIONS /aaa:options_cors:pre-executing
2017-10-23 10:51:25.302111 7f39f2e73700 2 req 22:0.000149:s3:OPTIONS /aaa:options_cors:executing
2017-10-23 10:51:25.302124 7f39f2e73700 2 No CORS configuration set yet for this bucket
2017-10-23 10:51:25.302126 7f39f2e73700 2 req 22:0.000193:s3:OPTIONS /aaa:options_cors:completing
2017-10-23 10:51:25.302191 7f39f2e73700 2 req 22:0.000258:s3:OPTIONS /aaa:options_cors:op status=-13
2017-10-23 10:51:25.302198 7f39f2e73700 2 req 22:0.000264:s3:OPTIONS /aaa:options_cors:http status=403
2017-10-23 10:51:25.302203 7f39f2e73700 1 ====== req done req=0x7f39f2e6d190 op status=-13 http_status=403 ======
2017-10-23 10:51:25.302260 7f39f2e73700 1 civetweb: 0x7f3a30c7c000: 172.20.41.101 - - [23/Oct/2017:10:51:25 +0300] "OPTIONS /aaa HTTP/1.1" 1 0 - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Firefox/56.0
OPTIONS requests failed with 403.
Robin thank you so much!
We have plans to use haproxy with Civetweb and your rules solve our problem with OPTIONS requests!
Thank you guys!
> On 22 Oct 2017, at 23:10, Robin H. Johnson <robbat2@xxxxxxxxxx> wrote:
>
> On Sun, Oct 22, 2017 at 01:31:03PM +0000, Rudenko Aleksandr wrote:
>> In past we rewrite http response header by Apache rules for our
>> web-interface and pass CORS check. But now it’s impossible to solve on
>> balancer level.
> You CAN modify the CORS responses at the load-balancer level.
>
> Find below the snippets needed to do it in HAProxy w/ Jewel-Civetweb;
> specifically, this completely overrides the CORS if the Origin matches some
> strings.
>
> We use this to override the CORS for access via our customer interface panel,
> so regardless of what CORS they set on the bucket, the panel always works.
>
> frontend ...
> # Store variable for using later in the response.
> http-request set-var(txn.origin) req.hdr(Origin)
> acl override_cors var(txn.origin) -m end -i SOMEDOMAIN
> acl override_cors var(txn.origin) -m sub -i SOMEDOMAIN
> # Export fact as a boolean
> http-request set-var(txn.override_cors) bool(true) if override_cors
> http-request set-var(txn.override_cors) bool(false) unless override_cors
>
> backend ...
> # We inject Origin headers for ..., so we must declare to the client
> # that the might be different in other requests.
> http-response add-header Vary Origin if { var(txn.origin) -m len gt 1
> # If the origin is the Panel, then override the CORS headers
> acl override_cors var(txn.override_cors),bool
> # 1. if OPTIONS: Override any 403 error to say it's ok instead
> # 403 means the OPTIONS request was being denied by the RGW as it didn't match.
> acl res_status_403 status eq 403
> http-response set-status 200 if res_status_403 override_cors METH_OPTIONS
> # 2. if OPTIONS: Valid CORS has length 0
> http-response set-header Content-Length 0 if override_cors METH_OPTIONS
> # 3. Override CORS headers
> http-response set-header Access-Control-Allow-Headers origin,\ content-length,\ content-type,\ content-md5 if override_cors
> http-response set-header Access-Control-Allow-Origin %[var(txn.origin)] if override_cors
> http-response set-header Access-Control-Allow-Methods GET,\ HEAD,\ POST,\ OPTIONS,\ PUT,\ DELETE if override_cors
> http-response set-header Access-Control-Max-Age 600 if override_cors
>
>
>>
>> What is right way?
>>
>> ---
>> Best regards,
>>
>> Aleksandr Rudenko
>>
>>
>
>> _______________________________________________
>> ceph-users mailing list
>> ceph-users@xxxxxxxxxxxxxx
>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
> E-Mail : robbat2@xxxxxxxxxx
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
