OEMR v 8.0.0 Patient Portal and Security Question

Security
,
1

I am not a programmer, so bear with me. I have been doing my best to figure something out. I am running OpenEMR v 8.0.0 on a docker instance on Windows 11 (Docker Desktop), WSL2, Ubuntu 22.04. The docker instance is running OEMR 8.0.0, MariaDB 10.6 (the only image I could get to work with v 8.0.0), and Nginx as a reverse proxy. I have been trying to get the patient portal set up. With a simple configuration file, everything functions as intended. I am able to access the OEMR main system at domain.com and the patient portal at domain.com/portal/, both on the LAN and the WAN.

Originally, I was trying to just use the portal on the LAN at the office with a self-signed certificate, but I could not get my iPad to connect due to certificate issues. So, I obtained a url and obtained SSL certs from Let’s Encrypt. Since I now have a CA cert, I figured I’d open the portal to the WAN for patient convenience. One of the things I have been trying to accomplish is to hide the url for the main system and only expose the /portal/. I have gotten fairly close. My current configuration allows my LAN to access main system with full formatting and portal with the formatting stripped out. On the WAN side, I have succeeded in blocking access to the main system and allowing access to the patient portal with formatting stripped out (just like LAN). The login page consists of username and password fields, and I am still able to log into my test patient account, but there is only script and the functions don’t work.

So, my questions are these. Maybe, I’m overcomplicating this. Is it necessary for OpenEMR to expose the main url (domain.com) for system access in order to have proper functioning of the patient portal (domain.com/portal/)? (i.e. In order for the patient portal to operate correctly, the main system must be exposed to the WAN). If not, is there a way to correct my setup to get WAN and LAN patient portal back to proper formatting while keeping the main system blocked from the WAN?

Any help would be appreciated. I am able to upload examples of my compose file and nginx configuration if that would help. I can also go into detail about the different configurations I have tried, which were unsuccessful.

2

Yes, the patient portal needs several URL paths beyond /portal/ to work. That’s why you’re seeing broken styling and non-functional scripts. The portal loads CSS, JavaScript, and other assets from paths outside /portal/.

I haven’t tested this exact setup, but in theory, you don’t need to expose the full main application — you just need to allow a few additional URL paths through your nginx reverse proxy.

The patient portal loads CSS, JavaScript, and other assets from paths outside /portal/:

  • /public/assets/ — jQuery, Bootstrap, FontAwesome, DataTables, etc.
  • /public/themes/ — Theme stylesheets
  • /library/js/ — JavaScript utilities (date pickers, dialogs, localization)
  • /interface/ — Some dialog utilities and form rendering
  • /ccdaservice/ — Clinical document viewing/download

When your nginx config blocks everything except /portal/, those assets can’t load — which is exactly what “formatting stripped out” and “functions don’t work” describes.

In theory, something like this should work:

# Allow patient portal
location /portal/ {
    proxy_pass http://openemr_backend;
    # ... your proxy settings
}

# Allow portal asset dependencies
location /public/assets/ {
    proxy_pass http://openemr_backend;
}

location /public/themes/ {
    proxy_pass http://openemr_backend;
}

location /library/js/ {
    proxy_pass http://openemr_backend;
}

location /interface/main/tabs/js/ {
    proxy_pass http://openemr_backend;
}

location /ccdaservice/ {
    proxy_pass http://openemr_backend;
}

# Block everything else from WAN
location / {
    # restrict to LAN only
    allow 192.168.0.0/16;
    allow 10.0.0.0/8;
    deny all;
}

This should keep the main application blocked from WAN while giving the portal the assets it needs to render and function properly.

2 Likes
3

Thank you! I will add this to the config and let you know how it turns out.

4

Thanks, Michael! I had to add a few more assets, but it appears the portal is working well, and I have been able to block access to the main system. I have been testing it for a couple of weeks. If anyone is interesting in seeing the assets I included in the portal.conf in nginx, just let me know.

1 Like