Web Service integration - CORS
Hi, We're currently trialling the software and have got a basic post integration working fine on the network via tools like Insomnia to post JSON, but when using an ajax post from say Chrome, we get CORS errors as the 'server' doesn't respond to OPTIONS requests.
Unfortunately our ERP system is cloud based in the US, our IIS servers are located in Europe and our factories in China (where we don't have access to enable port forwading so the servers can not talking directly to a printer/print server)
We wanted our employees to be able to print via a browser with data from our ERP/Intranets hosted off site, so a simple web page with ajax post seemed the way to go (unless we go down the route of trigger files) but as above, Chrome reports CORS/access-control-allow-origin errors when posting the data to the print/sever/integration server
I think you maybe better raising this with the Seagull Tech Support rather than post the query on here.
★ BarTender Hero ★
Have you tried setting the CORS header in Integration Builder? You can set this in the "Response" section of your integration:
If you're sending a GET, HEAD, or POST request, you may also be able to prevent the CORS preflight it by changing the content-type of your request to one of these:
There's more information about what causes this and modern CORS behavior here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.0
If you set the content-type to application/x-www-form-urlencoded, this will disable your browser from making the OPTIONS pre-flight requests since it is not required for this format. Normally, however you would need to encode your payload into the CURL. I tried that and found the bartender service would not accept the payload in that format. I then tried sending the payload as a JSON body and it worked fine. No comments regarding HTML5 compliance, but it works.0
Still not really a solution. With the latest version of Integration Builder CORS is still not supported properly. The product needs to be able to respond to OPTIONS requests with the access-control-allow-origin header, as the original poster on this thread correctly states. Right now the only way to support this properly is to put nginx or another proxy in front of it. You also should really support HTTPS. All HTTPS sites (aka ALL modern web sites) making web integration calls from the browser are going to give errors.0
Bumping this one, in case there's some new development (that I can't see).0