fastenhealth / fasten-onprem

Fasten is an open-source, self-hosted, personal/family electronic medical record aggregator, designed to integrate with 100,000's of insurances/hospitals/clinics
GNU General Public License v3.0
1.58k stars 83 forks source link

are all the tiles listed in "add source" actually supposed to work? #14

Open bdruth opened 1 year ago

bdruth commented 1 year ago

Just trying to get started ... clicking "Anthem" tile redirects me to auth'ing Anthem ... but if I try another tile, it just stares back at me ... no action, plenty of errors in the console. e.g. hitting the SSM Health tile doesn't do anything.

Super happy that you're getting this off the ground - lemme know what else would be helpful.

AnalogJ commented 1 year ago

Hey @bdruth

Hm. I just clicked the SSM tile and loaded the login page successfully (I don't have an account, so I couldn't confirm the connection worked).

Screen Shot 2022-12-23 at 5 28 44 PM

Did you finish the Anthem login and get redirected back to the app? or did you hit back/reload the sources page? If you finish logging into a provider and get redirected, Fasten will begin downloading data from your provider, which may take a few minutes. I wonder if that's causing issues/blocking you from connecting another source.

I'll have to do some investigation.

bdruth commented 1 year ago

I reset my install after I saw an error with Anthem, but even then it didn't work to click SSM. Tried Chrome and Safari both. Weird. I'll give it another go.

bdruth commented 1 year ago

Still not working for me this morning (didn't have a chance to look again last night, sorry) - here's what I see in the console on a refresh of that view

image

then when I click the SSM tile, I get this:

image

Edit: I'm running this in Docker on my Synology NAS via docker-compose, pretty simple config:

version: "3"

services:
  fasten:
    image: ghcr.io/fastenhealth/fasten-onprem:main
    container_name: fasten
    restart: always
    ports:
      - "9191:8080"

Edit: same error in Chrome -

image
bdruth commented 1 year ago

Follow-up - I've got the app running locally, but there's not the same tiles presented (much fewer) - if I were wanting to try to debug what's going on locally, without the source minified, how can I get the config loaded that provides the SSM tile?

AnalogJ commented 1 year ago

Hey @bdruth

Sorry I should document the local development environment a bit better. Fasten can run in 2 modes: sandbox or production. In sandbox mode, it can only communicate with test servers (full of synthetic health data). Here's how you run Fasten in production mode:

# In terminal https://github.com/fastenhealth/fasten-onprem/issues/1, run the following
cd frontend 
npm run dist -- -c prod

# In terminal https://github.com/fastenhealth/fasten-onprem/issues/2, run the following
go mod vendor
go run backend/cmd/fasten/fasten.go start --config ./config.dev.yaml --debug

The only difference from the CONTRIBUTING.md instructions is the npm run dist -- -c prod line.

bdruth commented 1 year ago

Cool - that did the trick :) Unfortunately (or fortunately?) ... running in this mode, the SSM tile works fine and connects ... so, hrmpf ... not sure why it's not happy running from the docker image. I'll see if I can dig some more.

AnalogJ commented 1 year ago

@bdruth are you still running into issues with Fasten connecting to SSM?

Any other feedback you'd like to share?

bdruth commented 1 year ago

I haven't dug more into why the Docker deployment isn't working. Running locally with 'prod', it works, but not in my Docker deployment env.

snagles commented 1 year ago

I encountered the same issue using my local server using the IP without https. I did a bit of digging and this seems to be due to 192.168.x.x being listed as an insecure context . I expect other insecure contexts would have the same issue. As a workaround I found the relevant chrome option in chrome to trust it manually using the flag chrome://flags/#unsafely-treat-insecure-origin-as-secure.

I added my IP used for the server in the box (http://192.168.{YOUR_RANGE}.{YOUR_RANGE}:{YOUR_PORT}), enabled, and relaunched and it worked.

AnalogJ commented 1 year ago

commenting with the discussion @snagles and I had on Discord.

off the top of my head, I cant think of any explicit usage of browser crypto in Fasten, and if there are, we should be able to do most of it server-side. if I had to guess, its one of these two lines https://github.com/fastenhealth/fasten-onprem/blob/main/frontend/src/app/services/lighthouse.service.ts#L68-L69

which reference functionality in the @panva/oauth4webapi library. Might be a good idea to check their issue tracker, and see if there's a known workaround for this error when using their library

@snagles went on to find the following reference to window.crypto.subtle - https://github.com/panva/oauth4webapi/blob/4ec6714b435f01f3efa000c1173da66f5ad8991a/src/index.ts#L825

While there is a workaround for now, longer term we'll want to detect errors in the calculatePKCECodeChallenge method, and see if we can fallback to a non-native crypto library (maybe).

Another alternative may be to throw a big warning on that page, stating that non-localhost/non-https domains will fail with an this error.

chansters commented 1 year ago

I encountered the same issue using my local server using the IP without https. I did a bit of digging and this seems to be due to 192.168.x.x being listed as an insecure context . I expect other insecure contexts would have the same issue. As a workaround I found the relevant chrome option in chrome to trust it manually using the flag chrome://flags/#unsafely-treat-insecure-origin-as-secure.

I added my IP used for the server in the box (http://192.168.{YOUR_RANGE}.{YOUR_RANGE}:{YOUR_PORT}), enabled, and relaunched and it worked.

I had the same issue and the Chrome workaround worked for me as well. Is there an equivalent setting for Safari?

cfu288 commented 1 year ago

Because this is a pain point, it might be worth including a docker compose file in the REAME that helps set up fasten with local SSL via mkcert so people getting started with fasten won't run into this problem. I haven't tested this specifically with fasten, but something like below might help newcomers just trying to get started on their local machine:

version: '3.9'

services:
  nginx:
    image: nginx:latest
    ports:
      - 443:443
    volumes:
      - ./nginx/certs/:/etc/nginx/ssl
      - ./nginx/conf/nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app
  app:
    image: ghcr.io/fastenhealth/fasten-onprem:main 
    ... rest here ...

You can generate the local certs by running this via the cli:

mkcert -key-file nginx/certs/ssl.key -cert-file nginx/certs/ssl.crt fasten.local

and update your /etc/hosts with the following:

127.0.0.1   fasten.local

There might be a way to do this with fewer steps.

AnalogJ commented 1 year ago

Let me see if I can replicate this issue locally, and find a better workaround. if I can't, we'll probably need to use @cfu288 's workaround, but that's pretty high-friction, and not an ideal user experience :(

AnalogJ commented 1 year ago

hey all, I just merged a fix for this issue to main. Please try pulling the latest docker image and testing it out.

docker pull ghcr.io/fastenhealth/fasten-onprem:main 
joshtrichards commented 1 year ago

Encountered this issue in both sandbox and main mode in the current image(s). The workaround noted in https://github.com/fastenhealth/fasten-onprem/issues/14#issuecomment-1418259341 seems promising as it makes more of the sources work.

AnalogJ commented 1 year ago

Hm. I'm still not able to reproduce this locally.

adding the following link which may help me get user-feedback about this error