CHW user can work online but not offline (role has offline: true)

Technical Support
1

Hi everyone,

I’m having an issue with an offline CHW user: The user’s role is chw, and in app_settings.json the role is configured with "offline": true:

"roles": {
"chw": {
"name": "usertype.chw",
"offline": true
}
}

image
image928×276 9.48 KB

When the device is online, the CHW can log in and use the app normally. Once the internet connection is lost, the app no longer works for this user (they can’t continue using the app as expected for an offline user).

image
image447×177 21.5 KB

Has anyone seen this behavior before or can suggest what to check next? Thanks in advance for any guidance.

2

3

Hi @Kenyuri

Are you using unmodified CHT in this showcase? This is not expected behavior in the CHT, and I can’t think of a reason this would happen.

4

I’m currently using unmodified CHT.

5

What happens if you just open the CHT in the browser instead of the Android app using the same user?

6

I’m able to navigate the form and the pages while offline using the browser instead of the app.

7

Thanks for the update, @Kenyuri . This means that the Android Wrapper is responsible for the issue. Not sure how to assist you further.

8

When I try to reproducing your error with the unbranded APK I get an error:

  1. go online
  2. install APK
  3. launch APK and enter in your UAT URL (https://almanach-cht.uat.icrc.org), login with authenticated user, sync
  4. make sure app works
  5. go offline
  6. see what happens

On step 3 above is where I get the error: URL is not a valid CHT server instance (as well, of course, I don’t have an authenticated user, this is your system, not mine ; )

unbranded
unbranded1080×2340 51.7 KB

This may be a bit off topic, but if there’s a way to not redirect all requests to SSO (/my.policy), it would allow CHT health checks (and monitoring API access etc). Step 3 fails because we validate the CHT instance at the /setup/poll endpoint. Here’s what the call looks like when it succeeds on our demo instance:

➜  ~ curl -qs https://demo-cht.dev.medicmobile.org/setup/poll | jq
{
  "ready": true,
  "handler": "medic-api",
  "version": "0.1.0",
  "detail": "All required services are running normally"
}

And this fails for your instance:

➜  ~ curl -sI https://almanach-cht.uat.icrc.org/setup/poll        
HTTP/1.0 302 Found
Server: BigIP
Accept-CH: Sec-CH-UA-Platform-Version
Content-Length: 0
Location: /my.policy
Set-Cookie: LastMRH_Session=73f9583f;path=/;secure;HttpOnly
Set-Cookie: MRHSession=2cf429d09ca6bdd58c3e555573f9583f;path=/;secure;HttpOnly
Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;secure
Connection: close

My thinking is that maybe something to do with your SSO (Entra ID) is causing the err_internet_disconnected error you’re seeing? Hence a less aggressive redirect might help.

As well, are you able to build your APK version but point it at an instance without SSO setup? Since this is an offline error, I can’t see why SSO would come into play, but , per above, I saw an error when I tested, so I’m wondering if SSO has something to do it?

9

Hi @mrjones Thank you the insights. You are getting the error in step 3 because your app user agent has been blocked in our firewall.

I have made a call to our instance and I’m getting this:

image
image733×124 13.7 KB

I have disabled SSO in our test instance but the error still persists.

10

Thanks for the update!

On your test instance, are you able to use the unbranded APK then? Especially if SSO is off - that’d be a great test.

The goal is to try and either find the configuration that fixes your setup or a specific set of steps that can be reproduced so that we can file a ticket and try and work on it.

11

Hi, @Kenyuri ,

did you try with several devices ? did you updated the google apk ?

br

12

We tried all the suggested options, but the root cause turned out to be outside CHT itself. The issue was caused by a firewall/APM policy blocking or redirecting static assets (notably the service worker and related JS files). As a result, these resources were never cached on the device, which prevented offline mode from working.

Once we excluded the required static resources from the firewall policy and ensured they were served without redirects, offline functionality started working as expected. @mrjones @diana

2 Likes
13

@Kenyuri - wonderful! Thanks for reporting that the issue was resolved - happy to hear that you’re up and running.

1 Like