Failure to login after database initialization: no error shown at frontend

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

Screen Recording 2024-10-07 at 16.53.33

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

cc @ibacher @dkayiwa @michaelbontyes @pirupius @dkigen @slubwama

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.

thank you @ibacher better video is here

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).

1 Like

thank you @ibacher The HAR archive can be downloaded from here

Also, Ian, the openmrs instance can be found here in case you are interested in interacting with it.

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.

4 Likes

Thank you so much @ibacher for that explanation :pray:. 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?

1 Like

I will keep you posted about how we solve this.

1 Like

:face_with_spiral_eyes: Actually, are you using 2.7.0-SNAPSHOT? It looks like we did something similar here and that may be the root cause of the issue?

4 Likes

He could probably be using 2.6.8 Resolve 3.3.2 (#4718) · openmrs/openmrs-core@66f8617 · GitHub

It looks like a revert is the right thing we should do.

4 Likes

@dkayiwa is there a version without that change we can rollback as a temporary solution?

2.6.7 won’t have the change.

We changed the war file to that of 2.6.7 inside docker and this solve it. Thank you @ibacher @dkayiwa

OpenMRS ReffApp’s build seams to specify 2.6.7 as the OMRS platform version, why is it that the server actually starts on 2.6.8 (the latest release) when using the qa tag for openmrs docker images and distro-emr-configuration: 3.2.0-SNAPSHOT?

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.

2 Likes

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.

1 Like

We wanted the bumps of the docker images to be automatic.

Currently, we don’t offer any tags that can be guaranteed to be safe for that use.

thank you @ibacher