CORS Policy for OLConnect Server 2021.1

[robyger]

I have a simple dashboard which is served by the the workflow HTTP Server Input using this url:
http://localhost:8080/printmanager

Now within my Connect web template, I need to log into the Connect Server via an ajax call using:
http://localhost:9340/rest/serverengine/authentication/login

This used to work fine in Connect v2020.1.

We have now upgraded to Connect v2021.1 and we are getting the following error in the browser which indicates that Objectif Lune have changed the CORS policy in the latest version of the Connect Server:

Access to XMLHttpRequest at ‘http://localhost:9340/rest/serverengine/authentication/login’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.
Access to XMLHttpRequest at ‘http://localhost:9340/rest/serverengine/entity/find’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.

The Network.XHR tab shows:
/login:

/find:

Does the new version expect specific headers in the ajax request?

How can I resolve this problem?

[Phil]

You’ve just stumbled onto an issue we weren’t aware of. After some analysis, we believe the issue appeared when we upgraded the Connect Server’s Web Server component in version 2020.2. It is surprising that you are the first user to report it, but then again there are probably very few users who actually allow a web page to access the REST API directly.

The issue occurs because of a specific browser behavior: prior to issuing POST/GET commands, most modern browsers issue an OPTIONS command to determine if the Server does indeed support the upcoming POST/GET (or other) commands. If the response to the OPTIONS command is anything but 200 Ok, the browser assumes that the Server doesn’t support it and returns an error. For some reason, our updated Web Server component returns a 405 Method not allowed message, even though it does support the OPTIONS method.

I have already created a ticket in our system to have the R&D take a look at this ASAP (internal reference: SHARED-82532).

In the meantime, there are 2 workarounds, though admittedly, neither is completely satisfactory:

1. Disable your browser’s CORS checking (not recommended)
2. Have the web page point to a Workflow process (through the NodeJS Server Input task) instead of the Connect REST server, and have that process issue the rest call to the Connect REST server. This is the recommended option, as it also allows you to better control who can access the REST server.

Sorry about this, we will investigate the issue.

[robyger]

@Phil, thank you for your feedback. I spent a couple days since Monday investigating the issue thinking a front end code change had occurred whilst upgrading to the latest version.

I ran other tests which do not access the “Connect REST API” but instead simply issue an ajax request back to the Workflow NodeJS Server Input just to load some static JSON file containing simple settins which we use to initalise our front end app.

We have mounted a point (/_ires) in NodeJS Server Input 2 which points to :
C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\HTTPResources\Settings
and the surveymodel.json file has been added to the folder

The following code to load the json file fails in the same way as described earlier

$.getJSON(“http://localhost:9090/_ires/surveymodel.json”, function(surveyJSON){
alert(JSON.stringify(surveyJSON));
}).fail(function(jqxhr, textStatus, error){
var err = textStatus + ", " + error;
console.log( "Request Failed: " + err );
alert(“Cannot display the application content. Contact the site administrator”);
})

I did not need to send my Connect template to Workflow, just clicking on the Preview HTML button from within Connect Designer to view it in the default browser.

But running this same url directly from a web browser outside a Connect template displays the json fine:
http://localhost:9090/_ires/surveymodel.json

So I am worried with regards to the extent of the issue and whether it affects any ajax\rest calls that issued from whithin a Connect template.

We do use a lot of ajax calls inside the app and they query the Connect REST API, the Workflow served resources (as described above) and up to 4 third party REST Servers.

Now changing the code as you can imagine cannot be done in the short term as there are strict and bureaucratic procedure in place.

We did skip v2020.2 for other blocking issues which were tested to have been resolved in 2021.1 and now in 2020.1 we are again faced with this other problem.

Since you have identified the source of the issue, is there any chance a patch addressing this specifc issue can be released before your general release in the autumn?

[Phil]

As long as the web page that contains the REST calls is being served from the same server (and the same port), then you won’t run into CORS issues. The Preview HTML button in Designer fetches the page from a random port that is different from the one used by Workflow, hence the CORS issue.

But if your Web page is generated through a Connect template and you access it through a Workflow process (e.g. http://localhost/getPage), then inside your template your REST calls could simply be made relative to the template (e.g. /workflowAPI/something). Because the REST call is relative, no CORS issue occurs.

You then need a single process (workflowAPI, in the example above) that uses the rest of the URL to make REST calls to the Connect Server. This is actually the recommended way of accessing your REST server because it centralizes all the URL processing on Workflow (similar to using proxies like NGINX or stand-alone NodeJS). It also allows you to better control who can access the server since you can force the NodeJS Input task to require a login.

I do realize, however, that this could require significant changes to the way your templates and your Workflow processes interact. Still, I would encourage you to implement such an architecture, at least for all your future projects.

As for releasing a patch version of the software, Objectif Lune tends to shy away from those as much as possible because our user base doesn’t much appreciate having to install multiple updates in close succession, especially if it patches issues that only impact few customers. That said, we do from time to time release patch versions when we determine that the danger (or the inconvenience) caused by the issue outweighs the potential inconvenience of having to install yet another version of the software.

I will discuss this with our Product Management group. No promises, however.

[robyger]

Thank you @Phil,

I understand what you are saying but this poses a huge inconvenience for us and I am sure other customers will discover these changes in time.

So in short, you are saying that all REST Calls now need to be served by the Workflow which will pass the response to the Connect Server even though some of our templates do not to use the Workflow, but make significant uses of the Connect REST API with third party automation tools and web servers? We haven’t tested those yet in the lastest reslease but I am guessing that they will no longer work.

I am sure Objectif Lune can find a way to maintain the current functionalities whilst blocking COORS. I am up for adding changes and proxies in the existing code rather than overhauling the current architecture of the various solutions we have implemented over the years in our clients base. That will be a lot of work for which we don’t have the resources.

For now we are reverting to using 2020.1 until we know more from Objectif Lune.

Thank you for your help on this.

[TDGreer]

I encountered similar issues with the HTTP Service in 2021.1. I found that I could replace the HTTPService.exe with the version from 2021.1, without rolling back the entire install.