You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This topic has grown out of the SORMAS-DEMIS-adapter ticket #37 , but it has become so big that it's worth a dedicated ticket. Also it involves a design decision relevant for the whole SORMAS project.
For the SORMAS-DEMIS-adapter, a more stable way to create pdf documents from html is required. The best way to go here probably is to use a headless browser for html rendering. Browser seem to be far more forgiving and stable than libraries like openhtmltopdf, which is currently used.
According to @MartinWahnschaffe, SORMAS will in the foreseeable future also require pdf conversion for generating reports. Thus, a shared solution is preferred.
Feature Description
Include a docker container to this project running a headless chromium browser. This shall be used as a relatively stable and secure way to convert html to pdf. There may be additional use cases in the future.
Requirements:
The container should just be able to in a local network. It must not have internet access.
The container should not induce a high server load.
The container should be publicly available, so it can be used by developers and users everywhere.
The container should not persist sensitive or personal information.
The container should not introduce an unappropriate amount of attack vectors.
Possible Alternatives
An interesting option may be https://hub.docker.com/r/browserless/chrome. Note that Chrome is used here instead of chromium. Advantageous is that it supports playwright, which should facilitate usage from within java code. With 100M+ downloads, the docker image seems to be widely used. According to the licensing statement here, it should be free to use under GPL3. Please note that the chrome browser can run in a container with almost all ports blocked and not internet access. Like that, no data will be transmitted to google or any third party.
Another option might be to run the chromium browser in the sormas-application container (into which the SORMAS-DEMIS-adapter is also deployed). This would introduce a larger piece of software into the container. Not just chromium, but additional dependencies as well. May be a bad idea from the security point of view.
Additional Information
As a whole new software is intended to be used for processing private data, this issue is most probably relevant for the SORMAS data protection regulation and data security.
The text was updated successfully, but these errors were encountered:
Situation Description
This topic has grown out of the SORMAS-DEMIS-adapter ticket #37 , but it has become so big that it's worth a dedicated ticket. Also it involves a design decision relevant for the whole SORMAS project.
For the SORMAS-DEMIS-adapter, a more stable way to create pdf documents from html is required. The best way to go here probably is to use a headless browser for html rendering. Browser seem to be far more forgiving and stable than libraries like openhtmltopdf, which is currently used.
According to @MartinWahnschaffe, SORMAS will in the foreseeable future also require pdf conversion for generating reports. Thus, a shared solution is preferred.
Feature Description
Include a docker container to this project running a headless chromium browser. This shall be used as a relatively stable and secure way to convert html to pdf. There may be additional use cases in the future.
Requirements:
Possible Alternatives
An interesting option may be https://hub.docker.com/r/browserless/chrome. Note that Chrome is used here instead of chromium. Advantageous is that it supports playwright, which should facilitate usage from within java code. With 100M+ downloads, the docker image seems to be widely used. According to the licensing statement here, it should be free to use under GPL3. Please note that the chrome browser can run in a container with almost all ports blocked and not internet access. Like that, no data will be transmitted to google or any third party.
Another option might be to run the chromium browser in the sormas-application container (into which the SORMAS-DEMIS-adapter is also deployed). This would introduce a larger piece of software into the container. Not just chromium, but additional dependencies as well. May be a bad idea from the security point of view.
Additional Information
As a whole new software is intended to be used for processing private data, this issue is most probably relevant for the SORMAS data protection regulation and data security.
The text was updated successfully, but these errors were encountered: