Web interface for https://github.com/dife-bioinformatics/metaKEGG
Authors: Justus Täger DZD, Tim Bleimehl DZD
- MetaKeggWeb
- Install and Run
- Configuration
- Notes on running in production
- Data Security and Privacy Protection Design
Important
This project is intended to run in a Linux/Unix environment. It should also be able to run in a MS Windows environment but was not tested yet. There may be are still bugs regarding Path resolutions on MS Windows.
docker pull dzdde/metakeggweb
docker run -p 8282:8282 dzdde/metakeggweb
visit http://localhost:8282 to use the MetaKegg WebClient
visit http://localhost:8282/docs to see the OpenAPI Rest Specification
requirements
gitfor downloading the projectdockerFor building and running the project
git clone git@github.com:DZD-eV-Diabetes-Research/meta-kegg-web-wrapper.git
cd meta-kegg-web-wrapper
docker build . -t metakeggweb
docker run -p 8282:8282 metakeggweb
visit http://localhost:8282 to use the MetaKegg WebClient
visit http://localhost:8282/docs to see the OpenAPI Rest Specification
requirements
gitfor downloading the projectpython>= v.3.11 for building and running the serverbunfor building the Webclient
git clone git@github.com:DZD-eV-Diabetes-Research/meta-kegg-web-wrapper.git
cd meta-kegg-web-wrapper
python -m pip install -r ./backend/requirements.txt -U
There are some mandatory config setting we need to set.
create a .env file at backend/mekeweserver/.env
Write this content into the file backend/mekeweserver/.env
SERVER_HOSTNAME=localhost
Download and install depencencies for client
(cd frontend && bun install)
Build static pages for the client
(cd frontend && bunx nuxi generate)
Finally we can start the MetaKegg Webserver with:
python backend/mekeweserver/main.py
visit http://localhost:8282 to use the MetaKegg WebClient
visit http://localhost:8282/docs to see the OpenAPI Rest Specification
MetaKegg has a range of configuration variables. Most are set to sane default values.
Have a look at config.template.yaml to see a template with all possible configuration parameters.
You can set any configuration variable via env vars. This is convenient via Docker
For example lets define the log level in our instance.
docker run -p 8282:8282 -e LOG_LEVEL=INFO metakeggweb
If you want to MetaKeggWeb to use a custamized config yaml file, set the environment variabel MEKEWESERVER_YAML_CONFIG_FILE with a path pointing to your yaml.
Lets create a config yaml first
/tmp/config.yaml
LOG_LEVEL: INFO
PIPELINE_RUNS_CACHE_DIR: /tmp/mekewe_cacheNow we want to set MEKEWESERVER_YAML_CONFIG_FILE to point to our yaml file
On MS Windows:
set MEKEWESERVER_YAML_CONFIG_FILE="C:\tmp\config.yaml"
On *nix:
export MEKEWESERVER_YAML_CONFIG_FILE="/tmp/config.yaml"
If we now start our webserver with
python backend/mekeweserver/main.py
Our config.yaml will be taken into account.
With docker we only need to mount our config.yaml into the config directory.
docker run -p 8282:8282 -v /tmp/config.yaml:/config/config.yaml metakeggweb
MetaKeggWeb uses a Redis server for interprocess communication.
If no Redis server is provided, the Webserver will run an instance of fakeredis.
This is fine for running a local demo.
For a productive instance you should attach a real Redis instance to the server.
Have a look at our docker-compose.yaml reference file to see how to do it.
MetaKegg Webwrapper implements several security measures to protect potentially sensitive bioinformatics data uploaded by users.
Each pipeline definition is protected by a cryptographically secure UUID4 identifier. These 128-bit random identifiers make unauthorized access through enumeration computationally infeasible. Without the complete pipeline URL, users cannot discover or access pipeline configurations or results.
Uploaded input files cannot be downloaded from the system, even if the pipeline URL is exposed. Only the aggregated result files generated by the metaKEGG analysis are available for download. This prevents scenarios where sensitive raw sequencing data or metadata could be extracted by unauthorized parties.
Users have full control over their data lifecycle through two mechanisms:
- Manual deletion: Users can delete any pipeline with all associated files at any time through the web interface, providing immediate data removal when needed.
- Automatic expiration: All pipeline definitions, uploaded files, intermediate results, and metadata are automatically deleted after the retention period specified by
PIPELINE_RESULT_DELETED_AFTER_MIN. This time-limited retention reduces the window of opportunity for unauthorized access and ensures compliance with data minimization principles.
Administrators should configure the automatic retention period based on their security requirements, while users retain the ability to delete data earlier if desired.
The complete source code is publicly available for review by security researchers, data protection officers, and end users before deployment or data upload. This enables independent security audits and allows organizations to verify security claims.
MetaKegg Webwrapper must be deployed behind an SSL/TLS-secured reverse proxy to encrypt all data in transit. Production deployments should use certificates from a trusted certificate authority and enforce HTTPS.
All storage volumes containing pipeline data, uploaded files, and results should be encrypted at rest using appropriate disk encryption, cloud provider encryption services, or filesystem-level encryption.
Production deployments using a dedicated Redis instance should bind Redis to localhost or internal networks only, enable authentication, and consider using TLS for network communication.
When deploying via Docker, follow standard container security practices including running as non-root users, using read-only mounts where appropriate, and regularly updating base images.
Users should be aware of the following limitations:
-
Pipeline URLs are bearer tokens: Anyone with access to a pipeline URL can access that pipeline's results. Treat URLs as secrets and transmit only through secure channels.
-
No user authentication: The system does not implement per-user authentication. All security relies on keeping pipeline URLs confidential.
-
Metadata exposure: Pipeline metadata such as creation timestamps and file names are accessible to anyone with the pipeline URL. Avoid including sensitive information in filenames.
For organizations with strict security requirements, consider deploying a dedicated instance rather than sharing infrastructure.
When processing data subject to regulatory requirements (GDPR, HIPAA, institutional guidelines), administrators must ensure that retention periods, data processing agreements, and access controls comply with applicable regulations. The combination of manual deletion capability and automatic data expiration supports data minimization principles and enables users to exercise control over their data. Retention periods must be configured appropriately for the specific jurisdiction and use case.