extern/2FAuth
1
0
Fork 0
mirror of https://github.com/Bubka/2FAuth.git synced 2025-04-01 11:26:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Fix missing auth guard in Docker setup

Browse Source
This commit is contained in:
Bubka 2022-05-10 12:52:05 +02:00
parent 5e0ea50e76
commit ca5f15d462
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.env.example
View File

@ -105,7 +105,7 @@ MAIL_FROM_ADDRESS=null
# authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will # authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents. # trust him as long as headers are presents.
AUTHENTICATION_GUARD= AUTHENTICATION_GUARD=web-guard
# Name of the HTTP headers sent by the reverse proxy that identifies the authenticated user at proxy level. # 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...) # Check your proxy documentation to find out how these headers are named (i.e 'REMOTE_USER', 'REMOTE_EMAIL', etc...)

10
Dockerfile
View File

@ -166,15 +166,15 @@ ENV \
# When using 'reverse-proxy-guard' 2FAuth only look for the dedicated headers and skip all other built-in # 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 # authentication checks. That means your proxy is fully responsible of the authentication process, 2FAuth will
# trust him as long as headers are presents. # trust him as long as headers are presents.
AUTHENTICATION_GUARD= \ AUTHENTICATION_GUARD=web-guard \
# Name of the HTTP headers sent by the reverse proxy that identifies the authenticated user at proxy level. # 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...) # 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') # (only relevant when AUTHENTICATION_GUARD is set to 'reverse-proxy-guard')
AUTH_PROXY_HEADER_FOR_USER= \ AUTH_PROXY_HEADER_FOR_USER=null \
AUTH_PROXY_HEADER_FOR_EMAIL= \ AUTH_PROXY_HEADER_FOR_EMAIL=null \
# WebAuthn settings # WebAuthn settings
# Relying Party name, aka the name of the application. If null, defaults to APP_NAME # Relying Party name, aka the name of the application. If null, defaults to APP_NAME
WEBAUTHN_NAME= \ WEBAUTHN_NAME=2FAuth \
# Relying Party ID. If null, the device will fill it internally. # 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 # See https://webauthn-doc.spomky-labs.com/pre-requisites/the-relying-party#how-to-determine-the-relying-party-id
WEBAUTHN_ID= \ WEBAUTHN_ID= \
@ -193,7 +193,7 @@ ENV \
# 'required': Will ALWAYS ask for user verification # 'required': Will ALWAYS ask for user verification
# 'preferred' (default) : Will ask for user verification IF POSSIBLE # '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) # 'discouraged' : Will NOT ask for user verification (for example, to minimize disruption to the user interaction flow)
WEBAUTHN_USER_VERIFICATION= \ WEBAUTHN_USER_VERIFICATION=preferred \
# Use this setting to declare trusted proxied. # Use this setting to declare trusted proxied.
# Supported: # Supported:
# '*': to trust any proxy # '*': to trust any proxy