european-dynamics-rnd / OneNet

8 stars 1 forks source link

"Data App is not accessible from the web" #18

Closed karljaats closed 10 months ago

karljaats commented 1 year ago

Hello, We are having persistent problems with getting the Data App to work correctly. Using our local UI at port 30003 when checking the Data App connection we get the "Data App is not accessible from the web" error message.

image

However the ports should be exposed and the Data App /about/version url at https://onenet-dmz.cyber.ee/middleware-data/about/version works correctly (from outside our network as well) and gives the "1.0" response.

The docker_be-dataapp-provider_1 and docker_be-dataapp-consumer_1 containers show errors that are probably to blame for this. Both show "ERROR on starting Jetty Server: Is a directory" and "Error parsing HTTP request header" logs. Any help in tracking down what the issue might be would be appreciated.

image image

HeliasEurodyn commented 1 year ago

Hello karljaats. can you try once more the "Connection Check" buttons ? The problem is fixxed now. It was a false restriction from our central registry application to access your publicly exposed url due to enhanced security measures.

karljaats commented 1 year ago

The connection check now indeed responds with a success message so that is one problem solved.

However we are still unable to provide/consume data. No message is given in the UI but the data does not get uploaded. The docker_be-dataapp-provider_1 and docker_be-dataapp-consumer_1 containers still have the previously mentioned error logs on startup (did a reinstall to make sure) and docker_be-dataapp-consumer_1 gets additional error logs when attempting to provide data:

image

pierluigi-linardi commented 1 year ago

Hello Karljaats, in the last log, i see that the data app is trying to invoke the broker url with the ip 172.17.0.1, however the machine ip is 192.168.21.23. Try changing this value in .env file --> LOCAL_IP_PROVIDER_CONTEXT_BROKER=192.168.21.23 and restart the application.

karljaats commented 1 year ago

Hello That was a good catch, but the error remained the same. image

pierluigi-linardi commented 1 year ago

Good Morning, Could you check if the fiware-orion service is up? In my case, I have this result via browser: image

karljaats commented 1 year ago

It is up. image The fiware-orion container even gets logs when I attempt to save provided data so at least something is connecting with it. image

ferdinandobosco commented 1 year ago

Hi Karl, can you try to change the dataapp and ecc in http and try it again? It seems something related to protocols connection...

If the error persists, we can arrange a technical meeting and try to fix it online.

Best, Ferdinando

karljaats commented 1 year ago

It turned out that our nginx was only redirecting https requests to the url and so http requests were not getting through. Having fixed that but leaving the urls in the connector settings as they were, we are now able to successfully provide data. However consuming data is still not working.

The "Get file from provider" button under Consume Data seems to be failing without producing any logs at all but using the "Get File" button in the form for provided data produces a MultipartMessageException in docker_be-dataapp-consumer_1: image

PS http requests to our dataapp and ecc url from outside of our network currently remain blocked, but as far as I understand that communication should always be using https anyway and using http for that doesn't seem quite right. However If I am wrong about that then we can change that as well.

ferdinandobosco commented 1 year ago

Hi Karl, did you try a clean run from the beginning (create new service, new data, new subscription etc...). If not, can you try it?

Can you please also share with us the entire logs of the containers? (both data apps, both ecc, etc..).

Thank you.

karljaats commented 1 year ago

I did a restart to the containers and then did a clean run from the beginning as suggested but it still behaved the same. Everything worked except for consuming data.

The logs for all containers: cyb_logs.zip

karljaats commented 10 months ago

The remaining issue was in our local Nginx configuration that was interfering with the communication. Seems to be working now.