Hello team,
I work with @fredericcervenansky and we have successfully deployed OHIF in hospital (except for one problem withe CORS Policy we are fixing).
Yet, we cannot acces the viewer from our local network while the port is open.
This is something that is working with the older 2.0 version (where react-viewerbase and ohif-core were still used as dependencies, or forked and used with yalc), but we merged our changes with your recent (convenient) updates and this is not working anymore. We have been through the config files (default.js, all.dev.js..) but we haven't found anything
Do you have any clues on this?
Many thanks again
@MathisGuilhin, are you using a provided recipe in the repo? If so, which one and how is it configured?
The OHIF Viewer itself is just a collection of html, css, and js "static assets". It shouldn't cause network issues. Does your local server return _anything_? What is your console's output? Are you having issues for some routes or all routes?
I am just running the server with 'yarn run dev'
Nothing prints out in console, this looks like a firewall issue :
Can you try localhost and the port? Is it running on the same machine?
When i try with localhost, this is working.
But even on the same machine with my ip, that doesn't work.
Yet, it works with the previous version
It's possible react-scripts was doing this under the hood in the previous version of our app?
https://webpack.js.org/configuration/dev-server/#devserverhost
Localhost and your local ip and port should work fine on your machine. If you're trying to access dev server hosted files from a different machine, try the above, but this is not an ideal setup for production use cases.
@dannyrb, just to be clear, for you, an ideal setup should be what?
@fredericcervenansky the webpack-dev-server is optimized for active development of the application. It uses unminimified code, does a lot of trickery to support hot reloading, and likely does not offer the same robustness/resiliency/security as a traditional production.
It's respository calls out that it should be used for development only:
Use webpack with a development server that provides live reloading. This should be used for development only.
I'm not sure it's wise for me to advise a specific production setup, as I don't know your requirements. You can see some broad recommendation in this repository's recipe collection.
We've been trying to build the app with success with yarn build.
The build is working with netlifly, but when we try to run it with xampp apache server, we get these errors :
and the screen remains black
Looks like the config file is not deployed properly. The error above shows it is returning a 404. You need the config/default.js file to be served by your web server as well. It is here: https://github.com/OHIF/Viewers/blob/master/platform/viewer/public/config/default.js
It is normally copied from public to the build folder when the build is run. Is it not in there?
I just had the same problem while trying to use this project inside docker. To fix the problem, i had to go to ./platform/viewer/.webpack/webpack.pwa.js and put this: host: '0.0.0.0', inside the devServer object. For reference, i did this cause of this comment.
I don't know if your problem is the same, but this fixed here for me...
Are you still having issues @MathisGuilhin? What does your deployed bundle look like? Your build configuration? To @swederik's point, your config says it's not being retrieved (hence the 404).
you can close the issue @dannyrb. We were able to deploy the build in a secure server (Apache or nginx, both work for us). @nogenem's solution was a good alternative before the prod deployment, just to make sure the address was reachable.
Thanks for following up @fredericcervenansky. Please don't hesitate to reach out in the future ^_^
Thanks for chiming in @nogenem! Always happy to have more helping hands.
Most helpful comment
you can close the issue @dannyrb. We were able to deploy the build in a secure server (Apache or nginx, both work for us). @nogenem's solution was a good alternative before the prod deployment, just to make sure the address was reachable.