If I have LDAP configured and the LDAP server is shut down, I will not be able to log in to local accounts either.

[MaxSignal]

Steps to Reproduce

1. LDAP server has been shut down for maintenance.
2. I tried to log in with a local account that is not linked to LDAP.
3. When I try to log in with local and LDAP accounts, when I press the login button, the button stays pressed and nothing happens. Reloading the page brings it back, but when I try again, nothing happens.

Expected Behaviour

If I log in with a local account independent of LDAP, shouldn't I be able to log in independently of LDAP?

Observed Behaviour

I couldn't log in and nothing happened.

Context

For now, it's not a big problem as we just need to finish the LDAP maintenance.

Technical Info

The LDAP configuration is as follows:

EXTERNAL_AUTH=ldap
OVERLEAF_LDAP_URL=ldap://ldap.example.com:389
OVERLEAF_LDAP_SEARCH_BASE=ou=people,dc=example,dc=com
OVERLEAF_LDAP_SEARCH_FILTER=(uid={{username}})
OVERLEAF_LDAP_BIND_DN=cn=ldap_reader,dc=example,dc=com
OVERLEAF_LDAP_BIND_CREDENTIALS=GoodNewsEveryone
OVERLEAF_LDAP_EMAIL_ATT=mail
OVERLEAF_LDAP_FIRST_NAME_ATT=givenName
OVERLEAF_LDAP_LAST_NAME_ATT=sn
OVERLEAF_LDAP_SEARCH_ATTRIBUTES=["uid", "sn", "givenName", "mail"]

OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN=true

OVERLEAF_LDAP_PLACEHOLDER='Username or email address'

• URL: local private server
• Browser Name and version: safari
• Operating System and version (desktop or mobile): MacOS Sequoia(Client), Ubuntu 24.04(Server)
• Signed in as:
• Project and/or file:

Analysis

[yu-i-i]

This issue occurs because the LDAP authentication strategy is attempted first. If LDAP authentication fails, Passport proceeds to the local strategy. However, if the LDAP server is unavailable, Passport waits for OVERLEAF_LDAP_CONNECT_TIMEOUT (typically about a minute) before producing an error. By default, Passport does not proceed to the next strategy after encountering an error, but this behavior can be changed.

I see two variants to fix it:

1. Change the order of strategies: Attempt local authentication first, then LDAP.

   • Pro: Local users won't notice if the LDAP server is down.
   • Con: In systems with LDAP, most users are LDAP-based, so each login attempt will generate an authentication failure for the local strategy, cluttering logs.

2. Set handleErrorsAsFailures: true in LDAP strategy: This treats errors (like timeouts) as authentication failures instead of stopping the chain. With a reduced OVERLEAF_LDAP_CONNECT_TIMEOUT (e.g., 10000 ms), local authentication will be tried after LDAP times out.

   • Pro: Avoids misleading authentication failure logs.
   • Con: In the event of an LDAP server failure, local users will experience a delay (e.g., 10 seconds) before logging in.

I prefer the second approach since an unreachable LDAP server should be addressed promptly. This way, both LDAP and local users will notify the admin, encouraging a quick resolution. Local users can still log in despite the delay.

I'll implement the fix soon.

[MaxSignal]

I also think that the second approach is better because I also think it is rare for a local user to log in on a server where LDAP is configured.
Thank you for your quick response!

[yu-i-i]

Fixed in the last commit.