Werner Noske · Jun 14, 2021

RestAPI Cors Problem

I'm building a Flutter app for smartphones and with same code a Flutter web app.

Both are using IRIS with a RestAPI.

As described in your documentation

I added

  • "x-ISC_DispatchParent":"solidara.CorsDispatch"

in the Info block of the Swagger definition and added

  • Parameter HandleCorsRequest = 1;

in the spec file after generating the RestAPI.

I also copied the example dispatch class to

  • Class solidara.CorsDispatch

With the Android app on my smartphone the OnHandleCorsRequest() is called although the cors data are not set by the request and handling a cors request is not needed. I can see this by setting a global in this method showing the %request.CgiEnvs sent by the app. The data access from the app to IRIS is working as expected.

But in Flutter Web I always get the Cors Error:

and the OnHandleCorsRequest() is not called at all by IRIS!

Any idea, what's going wrong here?

Product version: IRIS 2020.4
0 299
Discussion (3)1
Log in or sign up to continue

Hello Werner.

I had the same problem and I solved it adding this to the answer:

Do %response.SetHeader("Access-Control-Allow-Origin","*")


Where did you set that?

It seems to be not the same problem as yours. In my case may be it is not an IRIS specific problem at all. As I do not reach the cors dispatch method and the method in the impl file, It looked like the preflight request is already blocked by the Apache2 webserver on my system.

So I tried to add the following lines to the .htaccess file of meanwhile:

Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"

This should enable Cors in the Apache2 webserver.

I also did service apache2 restart.

But this did not solve the problem too. I still getting the same error message for the preflight request.

One way to be sure that the request is or is not reaching IRIS is to go into the IRIS Web Gateway on the web server and use the trace utility to see if the request is coming in and what it looks like.  Turn on the trace, make a request and then come back and turn off the trace.  Also the default on the Web Gateway server definition is the use gzip compression which will make the body unreadable.  You can temporarily turn this off while you do this test.  

Hopefully you are doing this in a development environment so this will have no impact on production.

UPDATE:  One other thing is to check the audit logs for an security issues that you may hit.  This does not sound like the issue for you, but its worth checking.