I am running a custom docker setup of the ReffApp where I pull down artifacts and deploy on an actual server. You can download the artifact here
The openmrs container seams not able to connect to the successfully created database causing Authentication errors and inability to login. Legacy keeps reloading while O3 hangs on select location. See the log
What could be causing this?
… in addition, this is only failing in cloud and works locally. I’ve tested on an Mac and Ubuntu local machines
That video is too small to be remotely helpful in helping you. Could you post a higher-resolution version or a HAR file from the web session or something? At a guess, something about you’re cloud setup is off, i.e., it results in OpenMRS making cross-domain requests or other things we don’t support OOTB.
Are you able to provide a HAR archive of the requests made running through the video? To do that, just run through the flow with the network tab open and in the settings section there should be a “Save as HAR Archive” or “Save All as HAR Archive” or similar (this archive is just a series of binaries documents that replicate most of the data from your network tab).
Thanks for the responsiveness. So the issue here is simple, but solving it may not be. Basically, in your application, the Set-Cookie header always gets returned with Secure, which indicates the cookie should only be used on HTTPS connections. Since the server is not running on HTTPS, the cookies are unusable and you effectively cannot authenticate with the app (in my browser, I see messages like “Cookie “JSESSIONID” has been rejected because a non-HTTPS cookie can’t be set as “secure”.”).
Now, the issue here is that no where in the default OpenMRS stack do we set that parameter for you. We do set the HttpOnly flag and there is code in the Gateway that, if uncommented and served via HTTPS, would automatically set this flag, but this line is commented out and remains so in both Ozone and your configuration, AFAICT.
This means that the “Secure” flag is likely being set by some part of your cloud stack, but that’s about as far as I can guess. BTW, if you can figure out what it is, please respond here as it’s likely helpful for others down the line.
Thank you so much @ibacher for that explanation . I have landed on something we tried with @isears in 2021.
Do you think setting the cookie property with a spring request Filter is a realistic solution since we have a custom module?
Can the backend build procedure pull the required openmrs version if i specify it inside the distro.properties file like version=2.6.7? If yes, how can i supply this file to the build?
Theoretically, but if you’re using Ozone, that has it’s own mechanisms for specifying the version of OpenMRS you rely on. 3.2.0-SNAPSHOT is not something that’s intended to be used in production, nor are the qa tagged images.
how about dev3 tagged images? Would they be good for a production server? We are running the same tag for both the frontend and the backend images, hence we want to run the latest frontend docker image since we point our frontend core version to latest.
We used '"coreVersion": "latest" with an old docker image tag and faced some weird bugs in the O3 frontend.
We tag each released version (including RCs) with a tag of the version number. Those would the the versions we recommend for production use.
The qa tag really means “intended to be deployed to test3”; dev3 means “intended to deploy to dev3”. Basically, the upshot is that those tags are intended for those environments.