|
@@ -0,0 +1,159 @@
|
|
|
+# 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 your 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=base64:OfTFROuxY2NHE321rcwz0N4UW/SSXWEjzxOGiQD7nCY=
|
|
|
+
|
|
|
+
|
|
|
+# 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 7 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=stdout
|
|
|
+
|
|
|
+
|
|
|
+# 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
|
|
|
+
|
|
|
+
|
|
|
+# If you're looking for performance improvements, you could install memcached.
|
|
|
+
|
|
|
+CACHE_DRIVER=file
|
|
|
+SESSION_DRIVER=file
|
|
|
+FILESYSTEM_DRIVER=local
|
|
|
+
|
|
|
+
|
|
|
+#### Database config & credentials ####
|
|
|
+
|
|
|
+DB_CONNECTION=pgsql
|
|
|
+
|
|
|
+
|
|
|
+#### 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=web-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=preferred
|
|
|
+
|
|
|
+
|
|
|
+# 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
|