extern/2FAuth
1
0
Fork 0
mirror of https://github.com/Bubka/2FAuth.git synced 2024-11-22 00:03:09 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update ENV vars in Docker related files

Browse Source
This commit is contained in:
Bubka 2022-03-31 09:36:12 +02:00
parent 0f5d259d02
commit 0717920dba
3 changed files with 140 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.env.example
View File

@ -101,7 +101,9 @@ MAIL_FROM_ADDRESS=null
# 'reverse-proxy-guard' : When 2FAuth is deployed behind a reverse-proxy that handle authentication
#
# WARNING
# When using 'reverse-proxy-guard' 2FAuth
# When using 'reverse-proxy-guard' 2FAuth only look for the dedicated headers and skip all other built-in
# authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents.
AUTHENTICATION_GUARD=

163
Dockerfile
View File

@ -102,69 +102,106 @@ COPY --chown=${UID}:${GID} docker/entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod 500 /usr/local/bin/entrypoint.sh
ENV \
# You can change the name of the app
APP_NAME=2FAuth \
# You can leave this on "local". If you change it to production most console commands will ask for extra confirmation.
# Never set it to "testing".
APP_ENV=local \
# Set to true if you want to see debug information in error screens.
APP_DEBUG=false \
# This should be your email address
SITE_OWNER=mail@example.com \
# The encryption key for our database and sessions. Keep this very secure.
# If you generate a new one all existing data must be considered LOST.
# Change it to a string of exactly 32 chars or use command `php artisan key:generate` to generate it
APP_KEY=SomeRandomStringOf32CharsExactly \
# This variable must match your installation's external address but keep in mind that
# it's only used on the command line as a fallback value.
APP_URL=http://localhost \
# Turn this to true if you want your app to react like a demo.
# The Demo mode reset the app content every hours and set a generic demo user.
IS_DEMO_APP=false \
# The log channel defines where your log entries go to.
# 'daily' is the default logging mode giving you 5 daily rotated log files in /storage/logs/.
# Several other options exist. You can use 'single' for one big fat error log (not recommended).
# Also available are 'syslog', 'errorlog' and 'stdout' which will log to the system itself.
LOG_CHANNEL=daily \
# Log level. You can set this from least severe to most severe:
# debug, info, notice, warning, error, critical, alert, emergency
# If you set it to debug your logs will grow large, and fast. If you set it to emergency probably
# nothing will get logged, ever.
APP_LOG_LEVEL=notice \
# Database config & credentials
# DB_CONNECTION can only be sqlite
DB_CONNECTION=sqlite \
DB_DATABASE="/srv/database/database.sqlite" \
# If you're looking for performance improvements, you could install memcached.
CACHE_DRIVER=file \
SESSION_DRIVER=file \
# Mail settings
# Refer your email provider documentation to configure your mail settings
# Set a value for every available setting to avoid issue
MAIL_DRIVER=log \
MAIL_HOST=smtp.mailtrap.io \
MAIL_PORT=2525 \
MAIL_FROM=changeme@example.com \
MAIL_USERNAME=null \
MAIL_PASSWORD=null \
MAIL_ENCRYPTION=null \
MAIL_FROM_NAME=null \
MAIL_FROM_ADDRESS=null \
# Leave the following configuration vars as is.
# Unless you like to tinker and know what you're doing.
BROADCAST_DRIVER=log \
QUEUE_DRIVER=sync \
SESSION_LIFETIME=12 \
REDIS_HOST=127.0.0.1 \
REDIS_PASSWORD=null \
REDIS_PORT=6379 \
PUSHER_APP_ID= \
PUSHER_APP_KEY= \
PUSHER_APP_SECRET= \
PUSHER_APP_CLUSTER=mt1 \
MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}" \
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}" \
MIX_ENV=local
# You can change the name of the app
APP_NAME=2FAuth \
# You can leave this on "local". If you change it to production most console commands will ask for extra confirmation.
# Never set it to "testing".
APP_ENV=local \
# Set to true if you want to see debug information in error screens.
APP_DEBUG=false \
# This should be your email address
SITE_OWNER=mail@example.com \
# The encryption key for our database and sessions. Keep this very secure.
# If you generate a new one all existing data must be considered LOST.
# Change it to a string of exactly 32 chars or use command `php artisan key:generate` to generate it
APP_KEY=SomeRandomStringOf32CharsExactly \
# This variable must match your installation's external address but keep in mind that
# it's only used on the command line as a fallback value.
APP_URL=http://localhost \
# Turn this to true if you want your app to react like a demo.
# The Demo mode reset the app content every hours and set a generic demo user.
IS_DEMO_APP=false \
# The log channel defines where your log entries go to.
# 'daily' is the default logging mode giving you 5 daily rotated log files in /storage/logs/.
# Several other options exist. You can use 'single' for one big fat error log (not recommended).
# Also available are 'syslog', 'errorlog' and 'stdout' which will log to the system itself.
LOG_CHANNEL=daily \
# Log level. You can set this from least severe to most severe:
# debug, info, notice, warning, error, critical, alert, emergency
# If you set it to debug your logs will grow large, and fast. If you set it to emergency probably
# nothing will get logged, ever.
APP_LOG_LEVEL=notice \
# Database config & credentials
# DB_CONNECTION can only be sqlite
DB_CONNECTION=sqlite \
DB_DATABASE="/srv/database/database.sqlite" \
# If you're looking for performance improvements, you could install memcached.
CACHE_DRIVER=file \
SESSION_DRIVER=file \
# Mail settings
# Refer your email provider documentation to configure your mail settings
# Set a value for every available setting to avoid issue
MAIL_DRIVER=log \
MAIL_HOST=smtp.mailtrap.io \
MAIL_PORT=2525 \
MAIL_FROM=changeme@example.com \
MAIL_USERNAME=null \
MAIL_PASSWORD=null \
MAIL_ENCRYPTION=null \
MAIL_FROM_NAME=null \
MAIL_FROM_ADDRESS=null \
# Authentication settings
# The default authentication guard
# Supported:
# 'web-guard' : The Laravel built-in auth system (default if nulled)
# 'reverse-proxy-guard' : When 2FAuth is deployed behind a reverse-proxy that handle authentication
# WARNING
# When using 'reverse-proxy-guard' 2FAuth only look for the dedicated headers and skip all other built-in
# authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents.
AUTHENTICATION_GUARD= \
# Name of the HTTP headers sent by the reverse proxy that identifies the authenticated user at proxy level.
# Check your proxy documentation to find out how these headers are named (i.e 'REMOTE_USER', 'REMOTE_EMAIL', etc...)
# (only relevant when AUTHENTICATION_GUARD is set to 'reverse-proxy-guard')
AUTH_PROXY_HEADER_FOR_USER= \
AUTH_PROXY_HEADER_FOR_EMAIL= \
# WebAuthn settings
# Relying Party name, aka the name of the application. If null, defaults to APP_NAME
WEBAUTHN_NAME= \
# Relying Party ID. If null, the device will fill it internally.
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#how-to-determine-the-relying-party-id
WEBAUTHN_ID= \
# Optional image data in BASE64 (128 bytes maximum) or an image url
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#relying-party-icon
WEBAUTHN_ICON= \
# Use this setting to control how user verification behave during the
# WebAuthn authentication flow.
#
# Most authenticators and smartphones will ask the user to actively verify
# themselves for log in. For example, through a touch plus pin code,
# password entry, or biometric recognition (e.g., presenting a fingerprint).
# The intent is to distinguish one user from any other.
#
# Supported:
# 'required': Will ALWAYS ask for user verification
# 'preferred' (default) : Will ask for user verification IF POSSIBLE
# 'discouraged' : Will NOT ask for user verification (for example, to minimize disruption to the user interaction flow)
WEBAUTHN_USER_VERIFICATION= \
# Leave the following configuration vars as is.
# Unless you like to tinker and know what you're doing.
BROADCAST_DRIVER=log \
QUEUE_DRIVER=sync \
SESSION_LIFETIME=12 \
REDIS_HOST=127.0.0.1 \
REDIS_PASSWORD=null \
REDIS_PORT=6379 \
PUSHER_APP_ID= \
PUSHER_APP_KEY= \
PUSHER_APP_SECRET= \
PUSHER_APP_CLUSTER=mt1 \
MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}" \
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}" \
MIX_ENV=local
ARG VERSION=unknown
ARG CREATED="an unknown date"

37
docker/docker-compose.yml
View File

@ -54,6 +54,43 @@ services:
- MAIL_ENCRYPTION=null
- MAIL_FROM_NAME=null
- MAIL_FROM_ADDRESS=null
# Authentication settings
# The default authentication guard
# Supported:
# 'web-guard' : The Laravel built-in auth system (default if nulled)
# 'reverse-proxy-guard' : When 2FAuth is deployed behind a reverse-proxy that handle authentication
# WARNING
# When using 'reverse-proxy-guard' 2FAuth only look for the dedicated headers and skip all other built-in
# authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents.
- AUTHENTICATION_GUARD=
# Name of the HTTP headers sent by the reverse proxy that identifies the authenticated user at proxy level.
# Check your proxy documentation to find out how these headers are named (i.e 'REMOTE_USER', 'REMOTE_EMAIL', etc...)
# (only relevant when AUTHENTICATION_GUARD is set to 'reverse-proxy-guard')
- AUTH_PROXY_HEADER_FOR_USER=
- AUTH_PROXY_HEADER_FOR_EMAIL=
# WebAuthn settings
# Relying Party name, aka the name of the application. If null, defaults to APP_NAME
- WEBAUTHN_NAME=
# Relying Party ID. If null, the device will fill it internally.
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#how-to-determine-the-relying-party-id
- WEBAUTHN_ID=
# Optional image data in BASE64 (128 bytes maximum) or an image url
# See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#relying-party-icon
- WEBAUTHN_ICON=
# Use this setting to control how user verification behave during the
# WebAuthn authentication flow.
#
# Most authenticators and smartphones will ask the user to actively verify
# themselves for log in. For example, through a touch plus pin code,
# password entry, or biometric recognition (e.g., presenting a fingerprint).
# The intent is to distinguish one user from any other.
#
# Supported:
# 'required': Will ALWAYS ask for user verification
# 'preferred' (default) : Will ask for user verification IF POSSIBLE
# 'discouraged' : Will NOT ask for user verification (for example, to minimize disruption to the user interaction flow)
- WEBAUTHN_USER_VERIFICATION=
# Leave the following configuration vars as is.
# Unless you like to tinker and know what you're doing.
- BROADCAST_DRIVER=log