Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So I wrote this a couple of months back, but didn't do a pull request because it felt like a bit of an ugly hack.
Well, it's still an ugly hack, but since I saw another request for LDAP support in #84, I figured I might as well make it a little more public. I wish I could spend more time cleaning this up, but unfortunately I really am lacking the time, so no hard feelings if you don't want to merge/support this. It works well enough for our needs right now so it's hard to justify spending any more work time on this.
Part of the changes were to the authentication and storage auth flow. I moved authentication/authorization related things out of lib/config and into lib/auth, lib/auth-local, and lib/auth-ldap. Most of the authorization functions are now in lib/access-control-list, which is used by lib/authenticated-user.
The recent addition of htpasswd support does conflict a little as it will create a user even if it fails to login to the LDAP server if both ldap and local backends are enabled and users_file is set. I moved the htpasswd related functions into auth-local, although now that I think about it, auth-htpasswd might have been better.