The FSFE's Community Database and all its related components
Go to file
tommi 8c783ce3b8
optimized donation page photo
2023-12-07 15:10:22 +01:00
auth Add and initialise `flask-talisman` 2023-06-26 11:58:54 +02:00
back unify selector notation 2023-11-27 15:46:03 +01:00
docs Prefer == over = in selectors without wildcards 2023-02-24 17:11:17 +01:00
front optimized donation page photo 2023-12-07 15:10:22 +01:00
ldap-mock Refactor database initialisation 2021-11-17 22:53:58 +01:00
openpgp-ca Push docs to 2023-01-02 11:22:55 +01:00
.drone.yml update renovate 2023-11-05 11:54:15 +01:00
.pre-commit-config.yaml Remove `update-requirements-files` from pre-commit 2022-11-18 09:54:28 +01:00
Makefile Use "COMPOSE" variable consistently throughout the makefile 2023-01-16 16:22:11 +01:00 Add to 2023-06-26 13:09:39 +02:00
docker-compose.development.yml Update maildev/maildev Docker tag to v2.1.0 2023-07-21 00:35:32 +00:00
docker-compose.production.yml Remove linus from MAIL_DEFAULT_RECEIVERS 2023-11-28 14:59:31 +01:00
docker-compose.quality.yml Run quality checks as root when running in drone 2021-11-17 13:35:07 +01:00
docker-compose.staging.yml Change log emails (to and from) 2023-06-23 08:52:48 +02:00
renovate.json update renovate 2023-11-05 11:54:15 +01:00

FSFE Community Database

in standard-readme compliant REUSE status

Build status



The FSFE Community Database is a combined tool for donation management, administration of accounts for FSFE's services, and opt-in based distribution of information emails.

FSFE Database Authentication Server

All relevant data for these purposes is stored in a PostgreSQL database on the one hand and FSFE's LDAP server on the other hand. Access to that data is encapsulated by the FSFE Community Database Backend, which provides both a set of commandline tools for manual administration tasks, and a protected RESTful(ish) network API to be used by other components.

The FSFE Community Database Backend essentially consists of three parts:

  1. An Object-Relational Mapper (ORM) which turns database records into Python objects and adds all the methods necessary to perform the tasks the FSFE Community Database is built for. This layer is the core of the whole structure. It is built with SQLAlchemy and resides in fsfe_cd_back/data.

  2. A resource server with a REST-like API to allow data access for the other components of fsfe-cd. All its access to the actual data goes through the ORM. The resource server is implemented with Flask and can be found in fsfe_cd_back/server.

  3. A set of command line tools for manual administration tasks, most of which are only a thin wrapper around methods implemented in the ORM. They are collected in the bin directory.

FSFE Database Authentication Server

The FSFE Community Database Authentication Server is an OpenID Connect Provider running on which authenticates a user against the LDAP server and then issues an access token which provides access to the authenticated user's (and only the authenticated user's) data though fsfe-cd-back's API.

Currently, this is an incomplete implementation of the OpenID Connect standard, providing only those functions required by fsfe-cd-back and fsfe-cd-front.

Implementation is based on pyoidc with a thin Flask wrapper for the URL routing.

Authentication is possible with two distinct methods:

  1. Authentication with username and password. Instead of the username, an email address can be given, in which case the corresponding username will be looked up via fsfe-cd-back. Username and password will be verified by a direct query to the LDAP server.

  2. If only username or email address is given, but no password, then the user receives an email with a login token encapsulated in a link which will allow a one-time login. This method is not only helpful for resetting a forgotten password, it also allows users to log in who have not set a username.

FSFE Community Database Frontend

Finally, the FSFE Community Database Frontend is a web application through which the people stored in the database can manage their own data at It sends users to fsfe-cd-auth to log in and then uses the user-bound access token returned from there to access the user's data through fsfe-cd-back.

fsfe-cd-front is a web application built with Flask. It provides a number of endpoints (called "views" in Flask) of the following categories:

  1. Endpoints for interaction with the actual user: registering as a new user ( and, paying online (, logging in and out (, and viewing as well as updating the personal settings (

  2. Endpoints for handling predefined commands which can be executed by simply following a prepared link (

  3. Endpoints for the automatic registration of incoming payments through PayPal or ConCardis (



The development of the FSFE Community Database is based on docker and docker-compose. Please note that this has been more tested against a rootless Docker daemon and since we run this type of daemon in both staging and production environments, it is recommended you have the same daemon running on your local machine. Here are Docker's installation instructions. Along with a text editor, these are the only two hard dependencies you need to have installed in order to start developing.

If you want to contribute, you also need pipenv and pre-commit installed locally. After installing pre-commit, you need to run

pre-commit install

in order to set up the check to run before every commit.

Start the development containers

Once you have installed everything, run

make dev

to start all three modules, i.e. back, front and auth in unison. The corresponding directories in this repository are mounted inside these containers so you can start changing the code in one of them, and the apps will update automatically during runtime as they all run the built-in Flask debugging server. Once you're done with your changes run

make qc.all

before committing as the commands run by this rule will need to complete without errors in order to pass through our CI system.

If you want to find out what other commands are available via the Makefile, run


to display a small manual page.


Deployment is handled by Drone CI and can be configured by editing .drone.yml.


Pushing to the master branch triggers a deployment of the staging environment on cont2-noris that can be tested at The relevant Docker Comopose file is docker-compose.staging.yml


Pushing to the protected production branch triggers a deployment of the production environment on cont1-noris that can be accessed via The relevant Docker Comopose file is docker-compose.production.yml


The following secrets are managed in drone:

Name Description Requirement Component
jwt_secret Shared secret for signed JSON Web Tokens used for authentication Must match the secret with the same name for fsfe-cd-front auth
bank_user User id to log into the banking interface with aqbanking-cli Must match the user id assigned by the bank back
cmd_passphrase Passphrase to verify URL-based commands (no requirement, can be randomly generated) back
postgres_password Password for the PostgreSQL database running on Must match the password configured on the PostgreSQL server back
ldap_password Password for the LDAP server running at Must match the password configured on the LDAP server back
concardis_passphrase Passphrase to verify the ConCardis payment notifications Must match the SHA-OUT passphrase defined in the ConCardis backoffice portal back
bank_user User id to log into the banking interface with aqbanking-cli Must match the user id assigned by the bank back
freescout_api_key API Key needed for the interactions with None back
secret_key Secret key used by flask for various purposes Can be arbitrarily assigned, but should remain constant over server rebuilds front
jwt_secret Shared secret for signed JSON Web Tokens used for authentication Must match the secret with the same name for fsfe-cd-auth front
concardis_sha_passphrase Passphrase to sign the ConCardis payment parameters Must match the SHA-IN passphrase defined in the ConCardis backoffice portal front


@reinhard @max @linus


Small note: If editing the README, please conform to the standard-readme specification.


AGPL-3.0-or-later © 2021 FSFE System Hackers