OHDSI Home | Forums | Wiki | Github

CORS Error - Atlas

I have the exact same issue, security.cors.enabled set to false, access-control-allow-origin to *, and also added a corsfilter in the tomcat web.xml such as this

<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.origins</param-name>
<param-value>*</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
1 Like

Hi @JSimmons01 - thanks for sharing these details. Looking at the screenshot and errors, the URL to your WebAPI endpoint appears incorrect. Instead of “http://localhost:8080/Webapisource/sources” it should be “http://localhost:8080/WebAPI/source/sources”. You can adjust this in ATLAS as described here.

As for the CORS errors: the CORS related settings are defined by the settings.xml file used to compile the WebAPI.war file. For reference, here is a sample settings.xml. The main properties are:

<security.origin>*</security.origin>
<security.ssl.enabled>false</security.ssl.enabled>
<security.cors.enabled>true</security.cors.enabled>

If these are set as shown above, you can attempt to disable CORS by setting <security.cors.enabled>false</security.cors.enabled>, recompile WebAPI.war using maven and redeploy to Tomcat to see if that fixes the issue.

@Diego_Bosca_Tomas - you mentioned that you set the “access-control-allow-origin to *” - do you mean the security.orgin property? Please note that if you change these settings, you’ll need to redeploy the WebAPI.war for those changes to take effect. I do not believe you’ll need to update the web.xml settings in Tomcat but just curious to know if that helped at all?

1 Like

Hey Anthony,

Thanks for your help with this!

Good spot on the URL error! I missed out the trailing /
I’ve fixed this now

I’ve rebuilt and deployed the WAR file to tomcat but unfortunately I’m still getting the same error.

Access to fetch at ‘http://localhost:8080/Webapi/source/sources’ from origin ‘http://localhost’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Anything else you can think to try? I’m not sure it’s still throwing a CORS error when it’s set to false in the settings.

(For rebuilding war file I did the following:

  1. Edited Settings.XML
  2. Ran C:\Git\OHDSI\WebAPI> mvn clean package -DskipTests -s WebAPIConfig/settings.xml -P webapi-postgresql
  3. Turned off Tomcat Service
  4. Removed the WebAPI folder & Webapi.war under C:\Tomcat\WebApps
  5. Restarted tomcat Service
  6. Deployed WAR file
    Hopefully these were the correct steps!)

access control was referring to IIS configuration.
I have redeployed the war each time I change the settings.
Adding the cors filter to tomcat (or removing it) provides the same results

To confirm that your application settings in the physical filesytem, you can check the file application.properties in the tomcat webapps folder:

D:\apache-tomcat-8.5.63\webapps\WebAPI\WEB-INF\classes

Your exact path may differ here.

Inside this file, search for cors.enabled to find the setting. and then check if it is matching what was in your configuration file.

If there is a bug with disabling cors, you may have to just set the origin value to http://localhost so you can access the service.

This is what puzzles me the most

Hey Chris,

Here’s the security block in that file

security.provider=DisabledSecurity
security.cors.enabled=false
security.token.expiration=43200
security.origin=*

So it looks like CORS is turned off but the error persists.

1 Like

Ok, so I think this is a bug in the CORS filter as it is implemented in WebAPI. I’m no expert on these matters, but after reading this article, I’m getting the impression that disabling cors should actually return an Access-Control-Allow-Origin header in the response. In webAPI, if cors is disabled, it doesn’t return any response header and therefore I believe leads to the CORS error in the browser (it needs to see the header).

My suggestion: change cors.enabled to true sot hat the hearder is retunred, but set the security.origin to * so that it will send a header with Access-Control-Allow-Origin: * in the reponse.

1 Like

Hey Chris,

Unfortunately the default for the setting.xml file is to set the security.origin to *
in C:\Git\OHDSI\WebAPI\WebAPIConfig\Settings.xml
<security.origin>*</security.origin>
<security.ssl.enabled>false</security.ssl.enabled>
<security.cors.enabled>false</security.cors.enabled>

I can see this applying in the Tomcat STDout log:
2021-05-26 10:45:43.525 INFO localhost-startStop-1 org.springframework.boot.web.servlet.FilterRegistrationBean - - Mapping filter: ‘corsFilter’ to: [/*]

I’ll keep hunting for a solution on my side and update this post if i find anything! Thanks for your help on this.

Thanks, John

Can you set security.cors.enabled to true and try again?

Hey Chris,

I can try that but I think this will just put me back to the same settings from my default settings.xml

From sample_settings.xml
<security.origin>*</security.origin>
<security.ssl.enabled>false</security.ssl.enabled>
<security.cors.enabled>true</security.cors.enabled>

I don’t have any better idea’s so I’ll give it a try anyway!

This might not be related but under C:\Tomcat\webapps\WebAPI\META-INF\maven\org.ohdsi\WebAPI
and C:\Git\OHDSI\WebAPI I can see a POM.XML file that has the following:

<security.origin>http://localhost</security.origin>
and
<security.cors.enabled>true</security.cors.enabled>

I’m a cloud infrastructure engineer by trade so i’m not entirely sure what this POM file does but thought it was worth flagging.

Pom.xml is a build file for building Java projects (Maven Java projects). The pom.xml has some defaults, which you can override using a custom settings.xml. These settings translate into the application.properties files which is what the application actually reads.

You’re right, this will set you back to the original defaults, but I don’t think you can physically turn off CORS in webAPI (because that’s something that’s enforced at the browser level) so I think the best you can do is leave it enabled (make sure cors.enabled is true in your settings.xml) and set the origin to * so that it won’t restrict anything.

Hi Chris,

Thanks for the info about the Pom.XML that makes sense and we’ve confirmed via the application.properties file that this isn’t interfering.

I have also tried running chrome without security (which allegedly bypasses CORS) but the error comes back with a 404 on the resources instead of the normal CORS error
“Failed to load resource: the server responded with a status of 404 ()”
So that didn’t help much!

I’ve also tested what happens if i run Atlas without the WebAPI installed to tomcat which interestingly still shows the CORS error.

I’m set back to the default Settings.xml now with Cors enabled.
I’ll continue trying to troubleshoot on this end and I’ll keep this post updated. If you think of anything else to try please let me know!

Thanks, John

Enabling CORS and leaving it to * actually told me that I had declared cors twice. I removed it from Tomcat configuration and now ATLAS works. Thanks for the advice!

Hey Diego,

Just out of interest - where did you remove CORS from the tomcat config? Just from web.xml?

Also how did you see that cors was declared twice?

Thanks, John

Yeah, just removed the filter from tomcat web.xml
The error was showing in the browser console (F12), and said that the Access-Control-Allow-Origin header was being sent twice with same value *
I assumed that tomcat one was not needed anymore and just removed it (and it worked)

Hi, two questions on this:
1: What version of Tomcat had that CORS filter pre-defined?
2: If you left the default configuration in Tomcat and set the cors.enabled == false in the WebAPI config, did it not work? The reason I would expect it to work is that if Tomcat is going to set the header due to the configuration in tomcat web.xml, and when cors.enabed == false in webapi means webAPI won’t set any of the CORS headers in the response, I was expecting that it would at least have the necessary headers set from tomcat web.xml so it would have worked. So, I’m glad you had it working, but the software engineer in me just wanted to explore the reason why telling webapi to not send CORS headers (with cors.enabled = false) didn’t work in that case.
.

It wasn’t predefined, I added the tomcat filter trying to solve the CORS problem. (I was using tomcat 8.5)
With cors.enabled=false and defining the filter in tomcat it did not work (gave CORS error discussed yesterday). However enabling it on webAPI did cause an error saying that there were 2 headers with * so I think something strange is happening there.

Hey All,

Got to the bottom of this one!

for anyone else who hits CORS issues similar to this thread:
in C:\Git\OHDSI\Atlas\js\config-local.js
I had the following in the URL field:
url: ‘http://localhost:8080/Webapi/
This is case sensitive and needs to be
url: ‘http://localhost:8080/WebAPI/

Thanks for your help on this everyone! Sorry it turned out to be a simple issue.

Thanks, John

1 Like

The Same Origin Policy (SOP) is the policy browsers implement to prevent vulnerabilities via Cross Site Scripting (XSS). In other words, the browser would not allow any site to make a request to any other site. It would prevent different origins from interacting with each other through such requests, like AJAX. This policy exists because it is too easy to inject a link to a javascript file that is on a different domain. This is a security risk - you really only want code that comes from the site you are on to execute and not just any code that is out there.

The Cross Origin Resource Sharing (CORS) is one of the few techniques for relaxing the SOP. Because SOP is “on” by default, setting CORS at the server-side will allow a request to be sent to the server via an XMLHttpRequest even if the request was sent from a different domain. This becomes useful if your server was intended to serve requests from other domains (e.g. if you are providing an API).

  • JSON with Padding is just a way to circumvent same-origin policy, when CORS is not an option. This is risky and a bad practice. Avoid using this.

  • If you want to bypass that restriction when fetching the contents with fetch API or XMLHttpRequest in javascript, you can use a proxy server so that it sets the header Access-Control-Allow-Origin to *.

  • If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

  • Access-Control-Allow-Origin: http://localhost:9999

t