Update ENV vars in Docker related files

.env.example

@@ -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=
 

Dockerfile

@@ -150,6 +150,43 @@ ENV \
     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 \

docker/docker-compose.yml

@@ -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