Cross-Origin Resource Sharing (CORS) Improvements and the Errors You May Encounter

Amanda Jennewein
Amanda Jennewein
  • Updated

Author: Sara Jensen

Updated: August 2024

Audience: Everyone

Summary

Due to potential Cross-Sight Scripting (XSS)​ vulnerabilities, we released Cross-Origin Resource Sharing (CORS) improvements.

When customers using Jama Connect, Replicated—Standard (v8.14.2 -v8.79.x) set up their server access through a proxy, certain proxy configurations can cause the Jama server to return an "Invalid CORS Request" error. This problem can occur even if the proxy configuration was previously working fine with an earlier version of Jama Connect®.

Consequently, you may encounter an "Invalid CORS Request" when accessing Jama Connect, Replicated - Standard v8.14.2 - 8.79.x while self-hosting your environment. In Jama's internal architecture, the Spring library handles server requests. This library verifies if the origin header matches the Base URL set in Jama. If these don't match, the Spring library will check the origin header against everything in the list of allowlisted domains. You get a CORS error if there are no matches on the list. The nature of this check is a literal string comparison.

Important

This is important because if you enter www.<your domain>.com to allow an HTTP origin header, you will still get a CORS error because the Spring library is performing a literal comparison between:

http://www.<your domain>.com 

-- base URL
and

www.<your domain>.com 

--  In your allowlist 

and these URLs do not match in a literal string comparison 

If you are experiencing this issue, it can be corrected using the following workaround: 

Start By Adding the Proxy and Host URLs to Their CORS Domain Allowlist

  • To ensure REST is enabled in your instance, log into Jama as the root user, go to General Properties> System Properties,  and check the box next to REST.
  • Go to
 https://<your-base-url>/api-docs
  • Find the System endpoint > 
POST /system/settings/corsdomains
  • Fill out the body as follows:
{ "domains": [ "<your-proxy-url>", "<your-host-url>" ] }
  • Submit the request

If you cannot go to /api-docs, you must submit the REST call via the command line.

Before you do, please note:

  • This example is for basic authentication; otherwise, you must use our OAuth Self-Service. Please see dev.jamasoftware.com > REST API for more information. 
  • A POST to this endpoint will overwrite your current list of allowlisted domains. Ensure that *all* necessary domains are included.
curl -X POST --user sample:password --header "Accept: application/json" --header "Content-Type: application/json" -d "{ \"domains\": [ \"https://<your-base-url>\", \"http://<your-base-url>\", \"http://<your-proxy-url>\", \"https://<your-proxy-url>\" ] }" "https://<your-base-url>/rest/latest/system/settings/corsdomains"

Note on Reverse Proxy Settings

For self-hosted customers using a reverse proxy with a custom context path and a custom port, we have observed several consequences of the new security features that need to be addressed by adding extra settings. Symptoms include:

  • Search showing no results
  • The list view of subitems in components is blank 

First, please confirm that the base URL in Jama (accessible from the root menu) and the hostname in your Replicated Admin Console are the same. 

Example of an Nginx Configuration

location /contour/ {
proxy_pass http://<your local Jama IP>/contour/;
proxy_set_header host $host;
proxy_set_header x-forwarded-proto https;
proxy_redirect ~^(http?://[^:]+):\d+(?<relpath>/.+)$ https://<your-base-url>$relpath;
} 

Example Apache Configuration

<Location /contour>
ProxyPreserveHost On
RequestHeader set X-Forwarded Proto "https"
</Location>

ProxyPass http://<server-name>:<####>/contour
ProxyPassReverse http://<host-name>:<####>/contour 

A Few Other Things to Note

  • This issue has not been observed in Internet Explorer or Firefox because they do not send origin headers. Firefox will likely start sending origin headers in future releases, and issues may be experienced.
  • If you were logged in when the domains were added to the allowlist, you may encounter a CSRF Exception when logging out. We advise waiting until users are logged out before updating the allowlist. If users are logged in while the allow listing takes place, they can resolve the CSRF Exception by clearing their browser cache.

Additional Resources

 

Please feel free to leave feedback in the comments below.

 

Related to

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.