Description
Running docker container tag v2.10.2.
Describe the bug
During initial installation, setting DISABLE_NEW_SSO_USERS to true prevents verification emails from being sent.
To Reproduce
If a user
- starts with an empty directory, having never used Linkwarden before
- builds a
.envwith these values defined as listed:
...
NEXT_PUBLIC_DISABLE_REGISTRATION=false
NEXT_PUBLIC_CREDENTIALS_ENABLED=true
DISABLE_NEW_SSO_USERS=true
NEXT_PUBLIC_EMAIL_PROVIDER=true
EMAIL_FROM=linkwarden@example.com
EMAIL_SERVER=smtp://user:password@host:port
...
- docker compose up to start the container
- attempts to sign up the first user for the first time
the user is unable to complete registration and login because no verification email is sent.
This is because no connection to the SMTP server is attempted as sniffed by tcpdump.
No log message is generated within the container indicating this failure condition.
If the user then
- changes
DISABLE_NEW_SSO_USERSfromtruetofalse - docker compose down/up restarts the container
- clicks "Resend Email" or otherwise attempts to login with the existing but unverified account
the connection to the SMTP server is attempted and an email is sent, allowing the user to verify their email address and continue setup/utilization.
I suspect this to be down to this line:
But this is just a theory.
If the user then
- changes
DISABLE_NEW_SSO_USERSfromfalsetotrue, mirroring the original configuration - docker compose down/up restarts the container
- clicks "Resend Email" or otherwise attempts to login with the existing but unverified account again
the issue does not appear - the verification email is sent and the user can click to verify, eventually successfully logging in.
Expected behavior
For first time installers, DISABLE_NEW_SSO_USERS set to true should not prevent email verifications from being sent.