Update README

Dockerfile

@@ -1,5 +1,10 @@
 FROM openjdk:21-slim
 
+VOLUME /var/flightlog/database/
+
+ENV FLIGHTLOG_DB_DIRECTORY=/var/flightlog/database
+ENV FLIGHTLOG_AUTHENTICATION_TYPE=fixed
+
 COPY target/flightlog.jar /var/flightlog/app/flightlog.jar
 
 CMD ["java", "-jar", "/var/flightlog/app/flightlog.jar"]

README.md

@@ -41,15 +41,15 @@ An embedded H2 database file will be stored at `~/.flightlog/`. Both the databas
 
 ## Docker container
 
-### Fetch from GitHub package registry
+### Fetch from Docker Hub
 
-An alternative do running the WAR file directly is to create a Docker container that wraps the complete application.
+An alternative do running the JAR file directly is to create a Docker container that wraps the complete application.
 
-Releases are automatically pushed to DockerHub packages so all you need to do is to run the Docker image.
+Releases are automatically pushed to Docker Hub so all you need to do is to run the Docker image.
 
-    $ docker run -p 8080:8080 perdian/flightlog:1.0.0
+    $ docker run -p 8080:8080 perdian/flightlog:latest
 
-Replace the `1.0.0` version with the latest release which can be found at https://github.com/perdian/flightlog/releases.
+Replace `latest` version with the latest release which can be found at https://github.com/perdian/flightlog/releases.
 
 The application will be available on the machine on which you're executing the container at:
 
@@ -78,121 +78,59 @@ The application will be available on the machine on which you're executing the c
 
 # Configuration
 
-The complete configuration can be done using environment variables so whether you're launching the application directly from the WAR file or via a Docker container the same set of environment variables is used.
+The complete configuration can be done through environment variables so whether you're launching the application directly from the JAR file or via a Docker container the same set of environment variables is used.
 
 ## Database
 
 By default an embedded H2 database is used but any database supported by Hibernate can be configured. The JDBC drivers for PostgreSQL and MySQL are already bundled within the standard Spring Boot application and Docker image.
 
 | Environment variable | Default value | Comment |
 | -------------------- | ------------- | ------- |
-| `FLIGHTLOG_DB_URL` | `jdbc:h2:/var/flightlog/database/flightlog` | The complete JDBC URL of the database |
+| `FLIGHTLOG_DB_URL` | `jdbc:h2:${FLIGHTLOG_DB_DIRECTORY:~/.flightlog/}/flightlogdb` | The complete JDBC URL of the database |
 | `FLIGHTLOG_DB_DRIVER_CLASS_NAME` | `org.h2.Driver` | The JDBC driver class name. The class must be accessible on the classpath. |
 | `FLIGHTLOG_DB_USERNAME` | `sa` | The JDBC username |
 | `FLIGHTLOG_DB_PASSWORD` | | The JDBC password |
-| `FLIGHTLOG_DB_HIBERNATE_DIALECT` | `org.hibernate.dialect.H2Dialect` | The Hibernate dialect class (must correspond to the selected JDBC driver class) |
+| `FLIGHTLOG_DB_DIRECTORY`| `~/.flightlog/` for the JAR distribution, `/var/flightlog/database/` for the Docker distribution | The directory where the embedded H2 database is located. Will only be used if `FLIGHTLOG_DB_URL` is not overwritten. |
 
 ## Authentication
 
 The application ships with a few options of authentication providers available.
 
-By default no authentication is required, which means without any additional configuration the application works in a single user mode: All flights are implicitly linked to a single user.
-
-If you want to enable authentication for the system you'll have to set the `FLIGHTLOG_AUTHENTICATION_REQUIRED` environment variable to `true` and configure additional environment variables that specify the authentication provider.
-
-### Local database authentication
-
-Using the internal database is the easiest option and is automatically selected if the `FLIGHTLOG_AUTHENTICATION_REQUIRED` environment variable has been set to `true`.
-
-For each login the application will look for an entry within the `user` table that has `internaldatabase` as value of the `authentication_source`, a `username` column value equal to the value entered in the login form and a `password` column value equal to the SHA-256 hash (hex encoded) of the password entered in the login form.
-
-If you want to disable the local authentication (because you want to only use other authentication methods) then you'll need to disable it by setting the `FLIGHTLOG_AUTHENTICATION_LOCAL_ENABLED` environment variable to `false`.
-
-### LDAP authentication
-
-Using an LDAP backend requires some additional environment variables to be set:
-
-    FLIGHTLOG_AUTHENTICATION_LDAP_ENABLED="true"
-    FLIGHTLOG_AUTHENTICATION_LDAP_URL="ldap://127.0.0.1"
-    FLIGHTLOG_AUTHENTICATION_LDAP_BASE_DN="dc=example,dc=com"
-    FLIGHTLOG_AUTHENTICATION_LDAP_USER_DN="ou=users"
-    FLIGHTLOG_AUTHENTICATION_LDAP_BIND_DN="cn=x,dc=example,dc=com"
-    FLIGHTLOG_AUTHENTICATION_LDAP_BIND_PASSWORD="yourbindpassword"
-    FLIGHTLOG_AUTHENTICATION_LDAP_USERNAME_FIELD="uid"
-
-The login will be made against the LDAP backend configured. After that a dummy user will be inserted into the local database with the `authentication_source` column set to `ldap` and the `username` column set to the username used during the login. The `password` column will remain `null`.
-
-If both the local database authentication and the LDAP authentication have been activated the application will first check if a local user is found, and if that's the case will use the local user. Only if no local user is found will the application look for a user in the specified LDAP system.
+By default no authentication is required, which means without any additional configuration the application works in a single user mode: All flights are implicitly linked to a single user named `example@example.com`.
 
 ## OAuth2 authentication
 
 Flightlog supports OAuth2 authentication via the following providers:
 
 * Google
 
-To enable the OAuth authentication you have to set the `FLIGHTLOG_AUTHENTICATION_OAUTH2_ENABLED` environment variable to `true`
+To enable the OAuth authentication you have to set the `FLIGHTLOG_AUTHENTICATION_TYPE` environment variable to `oauth2`
+
+For each login the application will perform an OAuth2 authentication. After the successful authentication an entry within the `flightuser_user` will be made, populated with the values retrieved from the OAuth2 provider.
+
+The following environment variables have to be set to the OAuth2 credentials retrieved from the Google Cloud console:
 
-For each login the application will perform an OAuth2 authentication. After the successful authentication an entry within the `user` table that has `internaldatabase` will be made, populated with the values retrieved from the OAuth2 provider.
+* `FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_ID`
+* `FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_SECRET`
 
-Note that in the default setup if the user authenticated via OAuth2 is *not* existing in the local database yet, then the authentication will fail. This is a conscious choice to prohibit someone spamming the system and creating entries in the database by simply performing multiple OAuth2 authentications.
+## Whitelisting users
+
+By default no new users can be registered in a flightlog applcation. This is a conscious choice to prohibit someone spamming the system and creating entries in the database by simply performing multiple OAuth2 authentications.
 
 There are two ways to allow an authentication from a new OAuth2 account:
 
 ### Disabling registration blocker
 
-By setting the environment variable `FLIGHTLOG_AUTHENTICATION_REGISTRATION_RESTRICTED` to `false` will bypass the check for existence and will create a new entry in the local database for every new account authenticated via OAuth2.
+By setting the environment variable `FLIGHTLOG_REGISTRATION_ALLOW_BY_DEFAULT` to `true` will bypass the check for existence and will create a new entry in the local database for every new account authenticated via OAuth2.
 
 ### Adding the email address to the whitelist
 
 When a new OAuth2 account is found the system will check the internal *whitelist* whether the email address of the new user is found in the whitelist. If that's the case then the new user will be added into the database and the authentication will succeed.
 
-There are two places where the whitelisted email address are stored:
-
-One option is to use the database table `registrationwhitelist` which simply contains an `email` column for the email to be whitelisted. To add members to the whitelist you can perform the following simple SQL statement against the local database:
-
-    INSERT INTO registrationwhitelist (email) VALUES ('theaddress@example.com');
+To place one (or more) user(s) on the whitelist add the email addresses to the environment variable `FLIGHTLOG_REGISTRATION_EMAIL_ADDRESSES_ALLOWLIST` (separate multiple addresses by comma).
 
 A second option (which is mainly designed for a personal installation without any open registration) is to add the whitelisted email addresses directly as environment variable `FLIGHTLOG_AUTHENTICATION_REGISTRATION_EMAIL_WHITELIST`:
 
-### Detailed configuration: Google
-
-To activate authentication via Google you'll have to provide your Google client id and client secret as additional environment variables:
-
-    FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_ID="12345"
-    FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_SECRET="67890"
-
-For detailed information of how to create the credentials see https://developers.google.com/identity/protocols/OAuth2.
-
-### All authentication related environment variables:
-
-| Environment variable | Default value | Comment |
-| -------------------- | ------------- | ------- |
-| `FLIGHTLOG_AUTHENTICATION_REQUIRED` | `false` | Whether or not to require a user to be authenticated to access the application |
-| `FLIGHTLOG_AUTHENTICATION_LOCAL_ENABLED` | `true` | Whether or not to include looking up the user from the internal database |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_ENABLED` | `false` | | Whether or not to include looking up the user from LDAP |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_BASE_DN` | | |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_URL` | | |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_USER_DN` | `ou=users` | |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_BIND_DN` | | |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_BIND_PASSWORD` | | |
-| `FLIGHTLOG_AUTHENTICATION_LDAP_USERNAME_FIELD` | `uid` | |
-| `FLIGHTLOG_AUTHENTICATION_OAUTH2_ENABLED` | `false`| Whether or not to allow OAuth2 for authenticating users |
-| `FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_ID` | | |
-| `FLIGHTLOG_AUTHENTICATION_OAUTH2_GOOGLE_CLIENT_SECRET` | | |
-| `FLIGHTLOG_AUTHENTICATION_REGISTRATION_RESTRICTED` | `true` | Whether or not to restrict the creation of new accounts |
-| `FLIGHTLOG_AUTHENTICATION_REGISTRATION_EMAIL_WHITELIST` | | Comma separated list of email addresses which are allowed to create new accounts. Only valid if `FLIGHTLOG_AUTHENTICATION_REGISTRATION_RESTRICTED` is set to `true` |
-
-## Automatic backup
-
-Flightlog can automatically create a backup archive of the complete data (users including their logged flights). To enable the backup two environment variables need to be configured:
-
-| Environment variable | Comment | Example |
-| -------------------- | ------- | ------- |
-| `FLIGHTLOG_BACKUP_CRON` | The CRON string specifying when the backup should take place | `0 0 5 * * 1` |
-| `FLIGHTLOG_BACKUP_TARGET` | The target to which the backup should be written | `file:/var/flightlog/backup/` |
-
-The backup archives themselves adhere to the naming convention `flightlog-backup-<date>.xml` where `<date>` will be replaced with the date on which the backup is being performed.
-
 ## Other environment variables
 
 | Environment variable | Default value | Comment |

src/main/resources/application.yml

@@ -1,6 +1,6 @@
 spring:
   datasource:
-    url: ${FLIGHTLOG_DB_URL:jdbc:h2:~/.flightlog/database}
+    url: ${FLIGHTLOG_DB_URL:jdbc:h2:${FLIGHTLOG_DB_DIRECTORY:~/.flightlog/}/flightlogdb}
     driver-class-name: ${FLIGHTLOG_DB_DRIVER_CLASS_NAME:org.h2.Driver}
     username: ${FLIGHTLOG_DB_USERNAME:sa}
     password: ${FLIGHTLOG_DB_PASSWORD:}
@@ -41,7 +41,7 @@ flightlog:
     type: ${FLIGHTLOG_AUTHENTICATION_TYPE:fixed}
   registration:
     emailAddressesAllowlist: ${FLIGHTLOG_REGISTRATION_EMAIL_ADDRESSES_ALLOWLIST:}
-    allowByDefault: false
+    allowByDefault: ${FLIGHTLOG_REGISTRATION_ALLOW_BY_DEFAULT:false}
   backup:
     cron: ${FLIGHTLOG_BACKUP_CRON:}
     target: ${FLIGHTLOG_BACKUP_TARGET:}