Closed battis closed 4 years ago
Oh, and... fixes #9.
Question: is this repo being actively maintained?
I'd really like to see this plugin in the standard OctoPrint plugin directory and configured to auto-update, etc. Would it be better to rename my fork and post that to the OctoPrint plugin directory?
Hello !
A big sorry for my silent... but many thanks for all your improvements ! My initial plugin was not very "standard", but I apreciate your contibutions.
I will take a look on them now
Maybe we should use this big improvements PR to embded started changes from here : https://github.com/gillg/OctoPrint-LDAP/pull/3/files#diff-4ce01db983fb434aa549b4900f3aad32R145
Thanks! I'll take a look. I'm going to be on and off the grid over the next few weeks, but will be back at work on this by January.
Hi ! Did you take some time to check my previous comments ? Have you made some tests with local and LDAP users ?
Sigh. I have not. I was all on top of this in December, but have been run ragged by classes since. I'll take a look ASAP. Sorry!
Thanks for your work @battis :)
Settings-related changes
ldap_uri
is now justuri
)auth_user
andauth_password
settings to support authenticated searches of LDAP directoryget_default_settings()
method to reflect changes described abovesearch_term_transfrom
setting allows the specification of upper or lower to force the userid to be searched within the LDAP directory consistently using the same case.LDAP-related changes
FindUser()
andCheckPassword()
methods and supporting LDAP methods to allow for optional authenticated searches of the LDAP directoryDocumentation-related changes
This has been tested against the ForumSys LDAP test server and both local file-based users and LDAP users are able to authenticate to OctoPrint with credentials checked correctly, while non-users cannot authenticate. The ForumSys LDAP test server seems to run OpenLDAP, which empirically behaves differently in some respects (noted in the README) than the Microsoft LDAP server bound to Active Directory. This may be artifacts of our local AD/LDAP configuration, but I noted them for posterity in case others also run into this.