Add option to prevent LDAP from deactivating everything on empty search

[zeripath]

It appears that some LDAPs will simply return an empty search results if there is an error during searching rather than report the error. In those circumstances Gitea would completely deactivate all LDAP users.

This is clearly not ideal - add a configuration option to LDAP configuration which will mean that by default an empty search results will not deactivate any users and instead an error will be logged. An authentication option can be turned on for those situations where this behaviour would be intended.

Fix #7949

[guillep2k]

This should require a migration step, I think. What should the migration value be? I vote for AllowDeactivateAll=false.

[zeripath]

It's actually not in the db like that. It's JSON so it will default to false already.

[codecov-io]

Codecov Report

Merging #9879 into master will decrease coverage by <.01%.
The diff coverage is 5.88%.

@@            Coverage Diff             @@
##           master    #9879      +/-   ##
==========================================
- Coverage   42.27%   42.26%   -0.01%     
==========================================
  Files         605      605              
  Lines       79253    79259       +6     
==========================================
- Hits        33501    33500       -1     
- Misses      41622    41626       +4     
- Partials     4130     4133       +3

Impacted Files	Coverage Δ
modules/repofiles/temp_repo.go	62.1% <0%> (ø)	⬆️
models/login_source.go	25.63% <7.14%> (-0.13%)	⬇️
services/pull/check.go	56.64% <0%> (-2.1%)	⬇️
models/error.go	30.76% <0%> (-0.55%)	⬇️
modules/log/event.go	65.64% <0%> (+1.02%)	⬆️
models/unit.go	39.5% <0%> (+2.46%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42fc65e...1ee28e9. Read the comment docs.

[dioss-Machiel]

Is it at all possible to get this fix into a 1.10 release?

[zeripath]

We could probably backport it to 1.11?

I think 1.10 is now security fixes only. git cherry-pick c5014a7 might work to put it on 1.10 but it will likely conflict.

[guillep2k]

We could probably backport it to 1.11?

I think 1.10 is now security fixes only. git cherry-pick c5014a7 might work to put it on 1.10 but it will likely conflict.

Sounds like we're close to 1.11, but if anybody wants port this to 1.10.4 and fix the conflicts or do it by hand, I have no problem reviewing the PR from zero.

[lunny]

@zeripath If we marked this as feature, I don't think we should send backport to v1.11. Or we may should label this as bug.

[zeripath]

@dioss-Machiel Looks like it applied cleanly to release/v1.10?

[dioss-Machiel]

I applied it manually, seems to be fine.

[zeripath]

I've marked this as a bug. I'm not sure where the bug is because LDAP shouldn't be returning an empty result without an error.