Configuring EDD

This page gives an overview of the most useful configuration options built into EDD. There are several sources of configuration available and some are described in further detail in sections below. Broadly speaking, each of the Docker containers used by EDD has its own configuration(s), as well as several configuration files for Docker itself. See comments within each file for a detailed description of some of the options.

Docker configuration files

These files configure EDD’s docker containers and enable you to launch EDD and most of its dependencies with a single command.

secrets directory

Directory stores passwords and URL’s for the various services EDD has to connect to, and makes them accessible to EDD’s Docker containers. Make sure to control access to this directory! It is meant to contain secrets for external services, and should be protected as any other password file. The .gitignore should exclude this directory.

settings directory

Directory stores Django settings value overrides. It is treated as a Python module, located at edd.settings.local. The default edd.settings attempts to from .local import *, allowing values in the module to override any setting attributes. The .gitignore should exclude this directory.

docker-compose.yml and docker-compose.override.yml

Configures EDD’s docker containers as run by Docker Compose. This is set up in a working configuration with basic default settings, but you may wish to change container definitions, etc. based on your computing needs, available resources, and deployment strategy. See the Docker-compose documentation for reference. Most local changes should go in the docker-compose.override.yml file. The override file is not included in the repository, but can be automatically generated by ./bin/dev_quickstart.sh. See the related Docker-compose extends documentation for reference.

EDD Django configuration files

Much of EDD’s functionality runs through the Django framework, and can be configured using Django’s settings mechanism. As a Django application, EDD loads its configuration with Python code. EDD’s settings are designed to load in default values, while allowing for overrides with a local settings module. An example of this file can be found at settings/example. Load the file into a container at /etc/edd/__init__.py via volumes (docker compose) or a config (docker stack) to use customized settings in the application.

Most of the available configuration parameters are defined by Django in its documentation, or by Celery in its configuration documentation. The settings for non-core Django applications used by EDD can be found with each individual project:

The defaults used by EDD are defined in the following files found under server/edd/settings:

  • base.py: defines baseline default settings that make EDD work out-of-the box.
  • celery.py: Defines EDD’s Celery-specific configuration.
  • edd.py: Defines custom settings for EDD itself
  • auth.py: Defines authentication-specific settings.

Settings unique to EDD will generally be prefixed with EDD_. Commentary for each of these, including possible values, should be included in the settings/example file. See “Custom Python Configuration” under Deployment for specific examples.

Configuring Social Logins

For a broad overview of 3rd-party or “Social” logins, refer to the django-allauth documentation. Each OAuth provider has their own unique setup and configuration process.

To add a new provider, ensure that the django-allauth provider application for that OAuth provider gets added to the INSTALLED_APPS setting, so that Django can use it. See settings/example for an example of updating the INSTALLED_APPS setting, without replacing the previous list. Include any logos in the static asset storage backend, and update the styles in EDD’s edd.branding application at ${EDD_URL}/admin/branding/branding/.

Configure a provider via the Django Admin site, by adding a new configuration or editing an existing one at ${EDD_URL}/admin/socialaccount/socialapp/. Each provider needs a “Client ID” and “Secret Key”, and individual providers may require additional details. See each provider for further details.

Using External Services

You may want to use a external services, instead of using the containers bundled in EDD’s generated docker-compose.override.yml. If so, you’ll want to follow this general outline:

  • Remove the service from docker-compose.override.yml
  • Update any connection strings to refer to the external URL