Summary of Change

This PR adds support for environment variables in config.yaml. This implementation allows environment variables to be specified with${ENV_VAR}, whereENV_VAR is the name of the variable to use.

Implementation Details

• The environment variable substitution is implemented by loading the config as a string, preprocessing that string, and then passing that preprocessed string into the Jackson ObjectMapper
• The environment variable name can include any character except} or linebreak, since the allowed characters for environment variables likely vary by OS
• The environment variable name can optionally have whitespace on either side, since the value is trimmed before use
• The environment variablevalue has no restrictions and can contain any character including colons and linebreaks, so it can even contain multiple config keys & values
• Each line of the config is only processed once, so environment variables cannot reference other environment variables
  • For example, if the config contains${ENV_VAR_A} and the value ofENV_VAR_A is${ENV_VAR_B}, this will not output the value ofENV_VAR_B, but will instead output the string${ENV_VAR_B}
• AQuitProgramException is thrown if an environment variable in the config is not defined
  • It might be desired to instead just ignore the line that contains the nonexistent environment variable, falling back to the default, but this might be confusing in production environments
• If an environment variable replacement is not desired, the sequence can be preceded by a\
  • \${ENV_VAR} would output the string${ENV_VAR}, not the value of the environment variableENV_VAR

Additional Proposed Features

• I have considered adding support for a default value if an environment variable is not defined
  • ${ENV_VAR, 0} would try to getENV_VAR and would output0 if not defined
  • I could use a non-comma separator if desired (|,:, something else?)
  • This might be considered a more extensible replacement for the current Dockerfile environment variable config values (see Docker MySQLimplementation andREADME)
  • For example, the config valuehost could default to${SUPERTOKENS_HOST, 0.0.0.0}
• I have also considered support for loading from a file, but this is probably beyond the scope of this feature
  • This could be implemented with syntax similar to this:${file: ../db_config.yaml}

Examples

# Simple examplecore_config_version:0host:${SUPERTOKENS_HOST}port:${SUPERTOKENS_PORT}base_path:${ SUPERTOKENS_BASE_PATH }# With optional whitespace${SUPERTOKENS_DB_CONFIG}# This could expand to a multiline string that contains multiple config values

# Proposed feature examplescore_config_version:0host:${SUPERTOKENS_HOST, 0.0.0.0}# With defaultport:${SUPERTOKENS_PORT, "3567"}# With default in quotes${file:../db_config.yaml}# Load from file with relative path${file:/etc/supertokens_config.yaml}# Load from file with absolute path${file:C:\Program Files\supertokens\config.yaml}# Load from Windows-style path

Related Issues

(no related issues)

Test Plan

I have looked into ways of mocking environment variables. Java does not allow directly mocking calls toSystem.getenv(), so I could either extract that call into a mockable class, or we could consider using processes instead of threads for testing. Environment variables are immutable for the current process (including threads), but they could be modified when launching a subprocess (seeProcessBuilder.environment()).

Documentation changes

If implemented, the configuration file should probably get its own page in the documentation to explain the various usages of this syntax.Let me know where this page should go, or if it should be added to an already existing page. I can submit a PR once the implementation of this feature is finalized.

Checklist for important updates

• Changelog has been updated
  • If there are any db schema changes, mention those changes clearly
• coreDriverInterfaceSupported.json file has been updated (if needed)
• pluginInterfaceSupported.json file has been updated (if needed)
• Changes to the version if needed
  • Inbuild.gradle
• Had installed and ran the pre-commit hook
• If there are new dependencies that have been added inbuild.gradle, please make sure to add them inimplementationDependencies.json.
• Issue this PR against the latest non released version branch.
  • To know which one it is, run find the latest released tag (git tag) in the formatvX.Y.Z, and then find the latest branch (git branch --all) whoseX.Y is greater than the latest released tag.
  • If no such branch exists, then create one from the latest released branch.

Remaining TODOs for this PR

• Alter implementation to ignore${} in comments (comments could easily be stripped before preprocessing)
• Make sure no other code directly reads the config file other thanCoreConfig.java