Jira Access-Control-Allow-Origin has duplicated entries

Hello all,
We are currently trying to deliver a feature to our clients, we have been using an Iframe on the JIRA cloud version by using the Javascripts provided by Atlassian to handle CORS.
While reading the docs for JIRA server we found out that our customers have the ability to allow certain domains within the white list plugin of JIRA to authorize CORS.
Anyway this seems to be not working as expected, the server response headers are malformed and this raises an error on the browser and prevent the iframe from doing xhr requests to the api.
Technical details and example :
Given our iframe make a request to http//jira_server_domain/rest/api/2/project/APP with the following code

var url = "http//jira.dev:2990/rest/api/2/project/APP"
$.ajax({
        xhrFields: {
            withCredentials: true
        },
        type: 'GET',
        headers: {
            'Content-Type' : 'application/json'
        },
        url: url,
        success: function(data, textStatus, request){
            alert( "It works :D" );
        },
        error: function (request, textStatus, errorThrown) {
            alert( "ERROR :-(");
        }
    });

The actual and normal behavior is that the browser will make an OPTIONS pre-flight request to find out if it is allowed to make the request or not. and the JIRA server will respond with the something like the following:

Note: output of curl but the same on the browser !

OPTIONS /jira/rest/api/2/project/APP HTTP/1.1
> Host: jira.dev:2990
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: authorization
> Origin: http://local.dev
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< X-AREQUESTID: 997x28877x1
< X-ASEN: SEN
< Set-Cookie: JSESSIONID=<cookie>; Path=/jira/; HttpOnly
< X-Seraph-LoginReason: OK
< Set-Cookie: atlassian.xsrf.token=<token>|lin; Path=/jira
< X-ASESSIONID: 1q3y36e
< X-AUSERNAME: admin
< Access-Control-Allow-Origin: http://local.dev
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: Content-Type
< Access-Control-Allow-Methods: OPTIONS
< Content-Type: text/html;charset=UTF-8

As we can see the Access-Control-Allow-Origin has the right value

but as soon as the browser execute the GET, the response headers will be like the following

> GET /jira/rest/api/2/project/APP HTTP/1.1
> Host: jira.dev:2990
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: authorization
> Origin: http://local.dev
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< X-AREQUESTID: 998x28880x1
< X-ASEN: SEN
< Set-Cookie: JSESSIONID=<cookie>; Path=/jira/; HttpOnly
< X-Seraph-LoginReason: OK
< Set-Cookie: atlassian.xsrf.token=<token>|lin; Path=/jira
< X-ASESSIONID: berseu
< X-AUSERNAME: admin
< Access-Control-Allow-Origin: http://local.dev
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: Content-Type
< Cache-Control: no-cache, no-store, no-transform
< Access-Control-Allow-Origin: http://local.dev
< Access-Control-Allow-Credentials: true
< Access-Control-Expose-Headers: Origin
< X-Content-Type-Options: nosniff
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked

As you can see there is a duplicated headers : Access-Control-Allow-Origin and Access-Control-Allow-Credentials but the first is the one who actually prevent the browser from passing the result to the Iframe.
This is very important for us as we would like to have almost the same code for Server and Cloud.

Here is a link for the bug https://ecosystem.atlassian.net/browse/REST-329 and that seems to be marked as resolved but we have not managed to make it works even on the latest JIRA version.

Any help will be appreciated.

Thanks and forgive me for my bad English.

2 Likes