Duplicate "Access-Control-Allow-Origin" header values on GET/POST responses breaks browsers


When using an ajax request to a JIRA REST API resource, with javascript hosted in an application foo.example.com linked to JIRA, and inbound connections are allowed for this applink through the whitelist, the request still fails to be delivered to javascript.

The initial OPTIONS response has a "Access-Control-Allow-Origin" header with a value of "foo.example.com", which is correct. The subsequent GET or POST response has a "Access-Control-Allow-Origin" header with a value of "foo.example.com, foo.example.com", which is then rejected by Firefox and Chrome. This means the GET or POST is actually succeeding, but the browser prevents the javascript in the browser from seeing the result.



Testing Notes

Add notes...


David Black
September 24, 2015, 4:13 AM

I am closing this issue as has now been resolved.

Richard Atkins
June 12, 2015, 1:45 AM

Looks like the Whitelist plugin com.atlassian.plugins.cors.CorsFilter is conflicting with the com.atlassian.plugins.rest.common.security.jersey.CorsResourceFilter. It seems wrong for the whitelist to attach a header without checking if the CorsAllowed annotation is present (which it is in no position to check, since it's a servlet filter and cannot tell what jackson resource will eventually be called), and it's equally wrong for the Atlassian REST code to ignore the whitelist configuration.





Richard Atkins