netreconlab/parse-hipaa(新しいタブで開きます)
主要言語: JavaScript
HIPAA & GDPR compliant ready parse-server with postgres/mongo, parse-hipaa-dashboard. Compatible with ParseCareKit
- star 数
- 112
- watcher 数
- 2
- fork 数
- 45
- issue 数
- 0
- 最終更新
- 2026/10/23
主要言語: JavaScript
HIPAA & GDPR compliant ready parse-server with postgres/mongo, parse-hipaa-dashboard. Compatible with ParseCareKit
Run your own HIPAA & GDPR compliant parse-server with PostgreSQL or MongoDB. parse-hipaa also includes parse-dashboard for viewing/modifying your data in the Cloud. Since parse-hipaa is a pare-server, it can be used for iOS, Android, Flutter, and web based apps (JS, React Native, etc). API's such as GraphQL and REST are enabled by default in parse-hipaa and can be tested directly or via the "API Console" in the Parse Dashboard. See the Parse SDK documentation for details and examples of how to leverage parse-hipaa for your language(s) of interest. parse-hipaa includes the necessary database auditing and logging for HIPAA compliance.
parse-hipaa provides the following:
You will still need to setup the following on your own to be fully HIPAA & GDPR compliant:
The CareKitSample-ParseCareKit, uses parse-hipaa along with ParseCareKit.
Use at your own risk. There is not promise that this is HIPAA compliant and we are not responsible for any mishandling of your data
Parse-HIPAA is derived from the parse-server image and contains the following additional packages:
Images of parse-hipaa are automatically built for your convenience. Images can be found at the following locations:
latest - Points to the newest released version. This is smallest possible image of parse-hipaa and it does not contain parse-hipaa-dashboardx.x.x - Points to a specific released version. These version numbers match their respective parse-server released versions. This is smallest possible image of parse-hipaa and it does not contain parse-hipaa-dashboardx.x.x-dashboard - Points to a specific released version. These version numbers match their respective parse-server released versions. This version of parse-hipaa is built with parse-hipaa-dashboard and is a larger imagemain - Points to the most up-to-date code and depends on the latest release of parse-server. This version of parse-hipaa is built with parse-hipaa-dashboard. This tag can contain breaking changesx.x.x-alpha/beta - Points to most up-to-date code and depends on the respective alha/beta releases of parse-server. This version of parse-hipaa is built with parse-hipaa-dashboard. This tag can contain breaking changesAny/all of the tagged servers can be used in combination with each other to build a High Availability(HA) server-side application. For example, your HA cluster may consist of: (1) nginx reverse proxy/load balancer, (1) x.x.x-dashboard parse-hipaa server, (2) x.x.x parse-hipaa servers, and (1) Percona Monitor and Management server.
latest or x.x.x - Use one or more of these images if you plan to have multiple parse-hipaa servers working together to create HA or just need a stand-alone server. Note that if all of your parse-hipaa servers are x.x.x, you may want to add a stand-alone parse-hipaa-dashboard or parse-server-dashoard
-dashboard - Use one of these images only if you plan to have one stand-alone parse-hipaa server or you want one of your servers to also provide parse-hipaa-dashboard ability
main or x.x.x-alpha/beta - Use only as a development server for testing/debugging the latest features. It is recommended not to use these tags for deployed systemsparse-hipaa can be easily deployed or tested remote or locally.
You can use the one-button-click deployment to quickly deploy to Heroko. Note that this is non-HIPAA compliant when using Heroku's free services, so you need to view Heroku's compliance certifications, and upgrade your plans to Shield Spaces. You can view this document for detailed instructions. If you need a Parse Server Heroku deployment for non-ParseCareKit based apps, use the Heroku button on the snapcat branch instead of this one. Once you click the Heroku button do the following:
NEW_RELIC_APP_NAME to the App name in step 1PARSE_DASHBOARD_USER_ID so you can log into your Parse DashboardPARSE_DASHBOARD_USER_PASSWORD so you can log into your Parse Dashboard. You can get the hash of your desired password from bcrypt-generator.comparse-hipaa with ParseCareKit you should set PARSE_SERVER_USING_PARSECAREKIT=false under Config vars. This will ensure that ParseCareKit classes/tables are not created on the parse-hipaa serverPARSE_SERVER_MOUNT_PATH and PARSE_DASHBOARD_MOUNT_PATHSettings->Reveal Config Vars to get your PARSE_SERVER_APPLICATION_ID. Add the PARSE_SERVER_APPLICATION_ID and https://YOUR_APP_NAME.herokuapp.com/parse as applicationId and serverURL respectively to your client app to connect your parse-hipaa serverheroku.yml in your repo by changing parse/Dockerfile.heroku to parse/Dockerfile. This will build from your respective repo instead of using the pre-built docker imageparse/index.js and parse/cloud as you wish⚠️ IMPORTANT NOTE: The CloudFormation one-click deployment below requires you to generate and provide security keys during setup. See the parameter descriptions in the deployment wizard. For production/HIPAA compliance, you MUST configure HTTPS/SSL after deployment.
One-Click CloudFormation Deployment:
⚠️ IMPORTANT: This one-click deployment is for testing/development only. For production use, follow the manual deployment method below for better security and control.
Generate your security keys first (save these securely):
# Generate all 7 required keys at once echo "ParseServerApplicationId: $(openssl rand -hex 32)" echo "ParseServerPrimaryKey: $(openssl rand -hex 32)" echo "ParseServerReadOnlyPrimaryKey: $(openssl rand -hex 32)" echo "ParseServerMaintenanceKey: $(openssl rand -hex 32)" echo "ParseServerWebhookKey: $(openssl rand -hex 32)" echo "ParseServerEncryptionKey: $(openssl rand -hex 32)" echo "ParseDashboardCookieSessionSecret: $(openssl rand -hex 32)"
Then click the button to deploy:
Note: The CloudFormation template URL points to the main branch. For production deployments, download the template locally and upload it to your own S3 bucket to ensure version stability.
One-Click Deployment Instructions:
Once you click the "Launch Stack" button above:
http://YOUR_URL/parse and Parse Dashboard at http://YOUR_URL/dashboard⚠️ REQUIRED POST-DEPLOYMENT STEPS:
After the CloudFormation stack completes, you MUST configure the database connection and server URL:
# Install EB CLI if not already installed pip install awsebcli # Clone the repository if you haven't already git clone https://github.com/netreconlab/parse-hipaa.git cd parse-hipaa # Initialize EB CLI for the application created by CloudFormation # Replace YOUR_REGION with the region where you deployed the CloudFormation stack eb init -p docker parse-hipaa --region YOUR_REGION # Select the environment created by CloudFormation (default: parse-hipaa-env) # This will be prompted interactively, or you can use: eb use parse-hipaa-env # Get the RDS endpoint and application URL eb printenv | grep RDS_ eb status # Set the database URI (replace YOUR_DB_PASSWORD with the password from CloudFormation step 3) # Replace RDS_HOSTNAME with the value from the printenv output above eb setenv PARSE_SERVER_DATABASE_URI="postgres://parseuser:YOUR_DB_PASSWORD@RDS_HOSTNAME:5432/ebdb" # Set the Parse Server URL (replace YOUR_CNAME with the CNAME from 'eb status' output) eb setenv PARSE_SERVER_URL="http://YOUR_CNAME/parse"
Optional: Secure the dashboard password post-deployment
# Generate a bcrypt hash of your password HASHED_PASSWORD=$(htpasswd -bnBC 10 "" "your-password" | tr -d ':\n') # Update the environment to use the hashed password eb setenv PARSE_DASHBOARD_USER_PASSWORDS="$HASHED_PASSWORD" PARSE_DASHBOARD_USER_PASSWORD_ENCRYPTED=true
⚠️ CRITICAL SECURITY NOTES:
PARSE_DASHBOARD_ALLOW_INSECURE_HTTP=0 after SSL is configuredManual Deployment (Recommended for Production):
The manual deployment provides better security by allowing you to hash passwords and configure settings step-by-step.
Prerequisites:
apache2-utils (Debian/Ubuntu) or httpd-tools (RHEL/CentOS) for htpasswd commandDeployment Steps:
Clone the repository:
git clone https://github.com/netreconlab/parse-hipaa.git
cd parse-hipaaInitialize Elastic Beanstalk:
eb init -p docker parse-hipaa --region us-east-2
Select your desired region during initialization.
Create environment and deploy:
eb create parse-hipaa-env --database.engine postgres --database.username parseuser
You'll be prompted to enter a database password interactively (recommended for security).
Note: This step will take several minutes as AWS provisions the RDS database.
Set dashboard credentials:
# Read password securely (won't be displayed or stored in history) read -s -p "Enter dashboard password: " DASHBOARD_PASSWORD echo # Generate hashed password HASHED_PASSWORD=$(htpasswd -bnBC 10 "" "$DASHBOARD_PASSWORD" | tr -d ':\n') # Set the dashboard credentials eb setenv PARSE_DASHBOARD_USERNAMES=admin PARSE_DASHBOARD_USER_PASSWORDS="$HASHED_PASSWORD" PARSE_DASHBOARD_USER_PASSWORD_ENCRYPTED=true # Clear the variables from current session unset DASHBOARD_PASSWORD HASHED_PASSWORD
Security Note: For production environments, consider using AWS Secrets Manager. After deployment, clear your shell history: history -c && history -w
Configure database connection: After the environment is created, get the RDS endpoint and construct the database URI:
# Get RDS connection information eb printenv | grep RDS_ # Securely read the database password (won't be displayed or stored in history) read -s -p "Enter database password: " DB_PASSWORD echo # Get the RDS hostname from environment RDS_HOST=$(eb printenv | grep RDS_HOSTNAME | cut -d'=' -f2 | tr -d ' ') # Set the database URI eb setenv PARSE_SERVER_DATABASE_URI="postgres://parseuser:${DB_PASSWORD}@${RDS_HOST}:5432/ebdb" # Clear variables unset DB_PASSWORD RDS_HOST
For production environments using AWS Secrets Manager:
# Store database password in Secrets Manager aws secretsmanager create-secret \ --name parse-hipaa-db-password \ --secret-string "YOUR_DB_PASSWORD" # Modify your application to retrieve the secret at runtime # See AWS Secrets Manager documentation for integration
Set required environment variables:
# Generate security keys and save them securely # IMPORTANT: Save these values in a secure password manager or secrets store # You will need PARSE_SERVER_APPLICATION_ID for client applications PARSE_SERVER_APPLICATION_ID=$(openssl rand -hex 32) PARSE_SERVER_PRIMARY_KEY=$(openssl rand -hex 32) PARSE_SERVER_READ_ONLY_PRIMARY_KEY=$(openssl rand -hex 32) PARSE_SERVER_MAINTENANCE_KEY=$(openssl rand -hex 32) PARSE_SERVER_WEBHOOK_KEY=$(openssl rand -hex 32) PARSE_SERVER_ENCRYPTION_KEY=$(openssl rand -hex 32) PARSE_DASHBOARD_COOKIE_SESSION_SECRET=$(openssl rand -hex 32) # Display keys for you to save (COPY THESE NOW!) echo "=================================================================" echo "⚠️ SAVE THESE VALUES IN A SECURE LOCATION BEFORE CONTINUING ⚠️" echo "=================================================================" echo "PARSE_SERVER_APPLICATION_ID: $PARSE_SERVER_APPLICATION_ID" echo "PARSE_SERVER_PRIMARY_KEY: $PARSE_SERVER_PRIMARY_KEY" echo "PARSE_SERVER_READ_ONLY_PRIMARY_KEY: $PARSE_SERVER_READ_ONLY_PRIMARY_KEY" echo "PARSE_SERVER_MAINTENANCE_KEY: $PARSE_SERVER_MAINTENANCE_KEY" echo "PARSE_SERVER_WEBHOOK_KEY: $PARSE_SERVER_WEBHOOK_KEY" echo "PARSE_SERVER_ENCRYPTION_KEY: $PARSE_SERVER_ENCRYPTION_KEY" echo "PARSE_DASHBOARD_COOKIE_SESSION_SECRET: $PARSE_DASHBOARD_COOKIE_SESSION_SECRET" echo "=================================================================" echo "Press Enter after saving these values to continue..." read # Set the environment variables eb setenv \ PARSE_SERVER_APPLICATION_ID="$PARSE_SERVER_APPLICATION_ID" \ PARSE_SERVER_PRIMARY_KEY="$PARSE_SERVER_PRIMARY_KEY" \ PARSE_SERVER_READ_ONLY_PRIMARY_KEY="$PARSE_SERVER_READ_ONLY_PRIMARY_KEY" \ PARSE_SERVER_MAINTENANCE_KEY="$PARSE_SERVER_MAINTENANCE_KEY" \ PARSE_SERVER_WEBHOOK_KEY="$PARSE_SERVER_WEBHOOK_KEY" \ PARSE_SERVER_ENCRYPTION_KEY="$PARSE_SERVER_ENCRYPTION_KEY" \ PARSE_DASHBOARD_COOKIE_SESSION_SECRET="$PARSE_DASHBOARD_COOKIE_SESSION_SECRET"
Configure S3 file storage (optional but recommended for production):
RECOMMENDED: Use IAM Instance Profile (no credentials needed):
# Set only the bucket name - no AWS keys needed
eb setenv PARSE_SERVER_S3_BUCKET=your-bucket-nameThen attach an IAM instance profile with S3 permissions to your Elastic Beanstalk environment:
NOT RECOMMENDED: Using AWS Access Keys (insecure for HIPAA):
# Only use this for testing - NOT for production/HIPAA environments
eb setenv \
PARSE_SERVER_S3_BUCKET=your-bucket-name \
AWS_ACCESS_KEY_ID=your-access-key \
AWS_SECRET_ACCESS_KEY=your-secret-keyGet your application URL:
eb status
Look for the CNAME field - this is your application URL.
Set the Parse Server URL:
# For testing/development (HTTP): eb setenv PARSE_SERVER_URL=http://YOUR_CNAME/parse # For production (HTTPS - configure SSL first): eb setenv PARSE_SERVER_URL=https://YOUR_CNAME/parse
Replace YOUR_CNAME with the URL from step 8.
Access your Parse Server:
For testing/development (HTTP):
http://YOUR_CNAME/parsehttp://YOUR_CNAME/dashboard⚠️ For production (configure HTTPS first):
https://YOUR_CNAME/parsehttps://YOUR_CNAME/dashboardTo configure HTTPS/SSL:
Important Security Notes:
history -c && history -wUpdating your deployment:
git pull origin main eb deploy
Monitoring and Logs:
eb logseb logs --streamAdditional Configuration:
The deployment includes configurations in .ebextensions/ directory:
01_environment.config - Application environment variables02_database.config - RDS PostgreSQL configuration03_logs.config - CloudWatch logging configuration04_container.config - Docker container settingsYou can modify these files to customize your deployment.
By default, the docker-compose.yml uses hipaa-postgres. The docker-compose.mongo.yml uses hipaa-mongo.
To use the Postgres HIPAA compliant variant of parse-hipaa, simply type:
docker-compose up
To use the Mongo HIPAA compliant variant of parse-hipaa, simply type:
docker-compose -f docker-compose.mongo.yml up
If you would like to use a non-HIPAA compliant postgres version:
docker-compose -f docker-compose.no.hipaa.yml up
A non-HIPAA compliant mongo version isn't provided as this is the default parse-server deployment and many examples of how to set this up already exist.
parse-hipaa is made up of four (4) seperate docker images (you use 3 of them at a time) that work together as one system. It's important to set the environment variables for your parse-hipaa server.
For a complete list of enviroment variables, look at app.json.
PARSE_SERVER_APPLICATION_ID # Unique string value PARSE_SERVER_PRIMARY_KEY # Unique string value PARSE_SERVER_READ_ONLY_PRIMARY_KEY # Unique string value PARSE_SERVER_ENCRYPTION_KEY # Unique string used for encrypting files stored by parse-hipaa PARSE_SERVER_OBJECT_ID_SIZE # Integer value, parse defaults to 10, 32 is probably better for medical apps and large tables PARSE_SERVER_DATABASE_URI # URI to connect to parse-hipaa. postgres://${PG_PARSE_USER}:${PG_PARSE_PASSWORD}@db:5432/${PG_PARSE_DB} or mongodb://${MONGO_PARSE_USER}:${MONGO_PARSE_PASSWORD}@db:27017/${MONGO_PARSE_DB} PORT # Port for parse-hipaa, default is 1337 PARSE_SERVER_MOUNT_PATH: # Mounting path for parse-hipaa, default is /parse PARSE_SERVER_URL # Server URL, default is http://parse:${PORT}/parse PARSE_SERVER_PUBLIC_URL # Public Server URL, default is http://localhost:${PORT}/parse PARSE_SERVER_CLOUD # Path to cloud code, default is /parse/cloud/main.js PARSE_SERVER_MOUNT_GRAPHQL # Enable graphql, default is 'true' PARSE_SET_USER_CLP # Set the Class Level Permissios of the _User schema so only authenticated users can access, default 1 PARSE_SERVER_ALLOW_CLIENT_CLASS_CREATION # String value of 'false' or 'true'. Prohibits class creation on the client side. Classes can still be created using Parse Dashboard by `useMasterKey`, default 'false' PARSE_SERVER_ALLOW_CUSTOM_OBJECTID # Required to be true for ParseCareKit PARSE_SERVER_ENABLE_SCHEMA_HOOKS # Keeps the schema in sync across all instances PARSE_SERVER_DIRECT_ACCESS # Known to cause crashes when true on single instance of server and not behind public server PARSE_SERVER_ENABLE_PRIVATE_USERS # Set to 'true' if new users should be created without public read and write access PARSE_SERVER_USING_PARSECAREKIT # If you are not using ParseCareKit, set this to 'false', or else enable with 'true'. The default value is 'true' PARSE_VERBOSE # Enable verbose output on the server POSTGRES_PASSWORD: # Needed for wait-for-postgres.sh. Should be the same as POSTGRES_PASSWORD in netreconlab/hipaa-postgres
POSTGRES_PASSWORD # Password for postgress db cluster PG_PARSE_USER # Username for logging into PG_PARSE_DB PG_PARSE_PASSWORD # Password for logging into PG_PARSE_DB PG_PARSE_DB # Name of parse-hipaa database
# Warning, if you want to make changes to the vars below they need to be changed manually in /scripts/mongo-init.js as the env vars are not passed to the script MONGO_INITDB_ROOT_USERNAME # Username for mongo db. Username for logging into mongo db for parse-hipaa. MONGO_INITDB_ROOT_PASSWORD # Password for mongo db. Password for logging into mongo db for parse-hipaa. MONGO_INITDB_DATABASE # Name of mongo db for parse-hipaa
PARSE_DASHBOARD_TRUST_PROXY: # Set this to 1 (or anything) if the dashboard is behind a proxy. Otherwise leave empty PARSE_DASHBOARD_ALLOW_INSECURE_HTTP: # Set this to 1 (or anything) if not behind proxy and using the dashboard in docker. Note that either PARSE_DASHBOARD_ALLOW_INSECURE_HTTP or PARSE_DASHBOARD_TRUST_PROXY should be set at the same time, choose one or the other. Otherwise leave empty PARSE_DASHBOARD_COOKIE_SESSION_SECRET: # Unique string. This should be constant across all deployments on your system PARSE_DASHBOARD_MOUNT_PATH: # The default is "/dashboard". This needs to be exactly what you plan it to be behind the proxy, i.e. If you want to access cs.uky.edu/dashboard it should be "/dashboard"
PARSE_DASHBOARD_TRUST_PROXY: # Set this to 1 (or anything) if the dashboard is behind a proxy. Otherwise leave empty PARSE_DASHBOARD_ALLOW_INSECURE_HTTP: # Set this to 1 (or anything) if not behind proxy and using the dashboard in docker. Note that either PARSE_DASHBOARD_ALLOW_INSECURE_HTTP or PARSE_DASHBOARD_TRUST_PROXY should be set at the same time, choose one or the other. Otherwise leave empty PARSE_DASHBOARD_COOKIE_SESSION_SECRET: # Unique string. This should be constant across all deployments on your system MOUNT_PATH: # The default is "/dashboard". This needs to be exactly what you plan it to be behind the proxy, i.e. If you want to access cs.uky.edu/dashboard it should be "/dashboard"
docker-compose updocker-compose -f docker-compose.mongo.yml updocker-compose -f docker-compose.no.hipaa.yml upImporant Note: On the very first run, the "parse-server"(which will show up as "parse_1" in the console) will sleep and error a few times because it can't connect to postgres (the "db") container. This is suppose to happen and is due to postgres needing to configure and initialize, install the necessary extensions, and setup it's databases. Let it keep running and eventually you will see something like:
db_1 | PostgreSQL init process complete; ready for start up.
The parse-server container will automatically keep attempting to connect to the postgres container and when it's connected you will see:
parse_1 | parse-server running on port 1337. parse_1 | publicServerURL: http://localhost:1337/parse, serverURL: http://parse:1337/parse parse_1 | GraphQL API running on http://localhost:1337/parsegraphql parse_1 | info: Parse LiveQuery Server starts running
You may also see output such as the following in the console or log files:
db_1 | 2020-03-18 21:59:21.550 UTC [105] ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" db_1 | 2020-03-18 21:59:21.550 UTC [105] DETAIL: Key (typname, typnamespace)=(_SCHEMA, 2200) already exists. db_1 | 2020-03-18 21:59:21.550 UTC [105] STATEMENT: CREATE TABLE IF NOT EXISTS "_SCHEMA" ( "className" varChar(120), "schema" jsonb, "isParseClass" bool, PRIMARY KEY ("className") ) db_1 | 2020-03-18 21:59:21.550 UTC [106] ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" ...
The lines above are console output from parse because they attempt to check and configure the postgres database if necessary. They doesn't hurt or slow down your parse-hipaa server.
There are equivalent Singularity images that can be configured in a similar fashion to Docker. The singularity images are hosted on GitHub Container Registry and can be found here. An example of of how to use this image can be found in singularity-compose.yml.
Your parse-server is binded to all of your interfaces on port 1337/parse and be can be accessed as such, e.g. http://localhost:1337/parse.
The standard configuration can be modified to your liking by editing index.js. Here you can add/modify things like push notifications, password resets, adapters, etc. This file as an express app and some examples provided from parse can be found here. Note that there is no need to rebuild your image when modifying files in the "index.js" file since it is volume mounted, but you will need to restart the parse container for your changes to take effect.
Default values for environment variables: PARSE_SERVER_APPLICATION_ID and PARSE_SERVER_PRIMARY_KEY are provided in docker-compose.yml for quick local deployment. If you plan on using this image to deploy in production, you should definitely change both values. Environment variables, PARSE_SERVER_DATABASE_URI, PARSE_SERVER_URL, PORT, PARSE_SERVER_PUBLIC_URL, PARSE_SERVER_CLOUD, and PARSE_SERVER_MOUNT_GRAPHQL should not be changed unles you are confident with configuring parse-server or else you image may not work properly. In particular, changing PORT should only be done in .env and will also require you to change the port manually in the parse-dashboard-config.json for both "serverURL" and "graphQLServerURL" to have the Parse Dashboard work correctly.
If you are plan on using parse-hipaa in production. You should run the additional scripts to create the rest of the indexes for optimized queries.
I